[alsa-devel] asoc: problem with snd_soc_dai_set_fmt()

[Mark Brown]

On Thu, Apr 29, 2010 at 06:30:19PM -0500, Timur Tabi wrote:
> On Thu, Apr 29, 2010 at 5:18 PM, Mark Brown
> > On Thu, Apr 29, 2010 at 04:22:17PM -0500, Timur Tabi wrote:

> >> 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.

You may have missed some of my more subtle hints previously :)

> > 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?

The driver should expose whatever functionality the hardware has.  If
your CPU driver doesn't have any PLLs/FLLs that can be usefully
configured by the user using set_pll() then it shouldn't implement a
set_pll() function.  If it does have such hardware then it should
implement set_pll() so users can configure them, unless it's always
possible for the driver to do the configuration autonomously for all
situations in which case it should just do that.

> >  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"?

Not at all.  It'll mean that either the device is fixed function or
configurability has not yet been implemented.  The set_fmt() call is how
the driver finds out what the bus is doing (and many of the formats are
indistinguishable from each other without semantic information so
looking at the wire isn't going to help).

> > 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.

No, it really does mean that it's ignoring what it's being told to do.

It may be that the configuration that was requested just happens to be
what the hardware is set up to do but there's no way for the core to
tell that, all it knows is that it didn't have a mechanism to pass on
the configuration to the driver.

> 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.

If the machine driver is relying on the configuration having been done
by some other part of the system then it shouldn't be trying to
explicitly set the format in the first place.  If it doesn't care if the
configuration it requested was actually implemented then it should just
ignore the return value.

> 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.

Well, if your machine driver knows that the device tree will configure
everything it needs then it shouldn't be trying to set the format in the
first place, just as if it knows that the hardware is fixed function.
In your case presumably the machine driver is finding the configuration
it is trying to apply from the device tree so you should just make it
handle missing information.

> > 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.

As I said in my previous message if you want to query the capabilities
of the CODEC you'd need to add a method for the CODEC to report
capabilities.

As has been repeatedly discussed there is a strong expectation that the
machine driver knows the details of the hardware it's gluing together
since this is the basic function of the driver.  Your desire to write a
generic machine driver which will work with a very wide range of boards
is not something that the existing code makes any effort to support.