On Thu, Apr 29, 2010 at 5:18 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Apr 29, 2010 at 04:22:17PM -0500, Timur Tabi wrote:
Let's say the DAI driver has not defined a .set_fmt() function. This means that if the fabric driver does this:
*machine*
Grr... I've been calling it the fabric driver for a long time, and I know I didn't make up that term.
Right, but really this is the case - the driver has completely ignored what the machine driver was trying to do.
But there are several functions like that, such as the _pll function. What if the CPU driver really doesn't care what the frequency is or the PLL or whatever? Do I need to define stub functions for all of these?
It may be that the default behaviour is what was asked for, but it may also be that you've asked for I2S format and got DSP format or something similiarly incompatible.
But if the CPU driver does not define a function to check for that, isn't that the same thing as saying, "I really don't care -- I'll support whatever you want"?
Due to the above issue I don't think this is a good idea - we really ought to let the machine driver know if the request it made was ignored in case it is trying to set up something that can't be supported.
IMHO, ignored != not supported.
For instance, it's possible for a CPU driver initially to support only some configurations, so the set_fmt function would be necessary. Later, the CPU driver could be updated to support all possible configurations, and it could know that via some other mechanism (like the device tree), and so it would be redundant if it let the machine driver know what that configuration is.
This is what I'm doing to my SSI driver. Now that it probes the SSI nodes directly, it doesn't need the machine driver to tell it what the capabilities are.
Another short term option would be to change the error code to be something a bit more distinctive than -EINVAL.
That would help.
The current expectation is that the machine driver knows what the hardware is capable of
But not necessarily at compile time! I was hoping to use this as a mechanism for determining the capabilities at run time.