Re: asoc: problem with snd_soc_dai_set_fmt()

[Timur Tabi <timur@freescale.com>]

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.

-- 
Timur Tabi
Linux kernel developer at Freescale