[alsa-devel] Ordering in soc_pcm_hw_params()

[jonsmirl at gmail.com]

On Mon, Aug 11, 2014 at 1:11 PM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Aug 11, 2014 at 12:09:43PM -0400, jonsmirl at gmail.com wrote:
>> On Mon, Aug 11, 2014 at 11:33 AM, Mark Brown <broonie at kernel.org> wrote:
>
>> > No, the machine driver runs first so it can do any coordination needed
>> > between the other devices.  Attempting to fiddle about with the ordering
>> > is never going to be robust, someone else will always want a different
>> > ordering at some point.
>
>> I don't see how to fix this without making a machine driver that
>> simply tells the cpu-dai to change the MCLK output from 22.5Mhz to
>> 24.5Mhz earlier in the hw_params chain. But that's putting a generic
>> piece of code into the machine driver.
>
> That's absolutely fine, the clocking arrangements and sequencing
> requirements for achieving it are in general going to depend on the
> machine.  The machine may have requirements which mean that it doesn't
> want to use a clock configuration it's physically possible for it to
> generate, or it may want to do more extensive reparenting depending on
> use case.
>
> For things like this it is generally good practice for the machine
> driver to disable all clocks (set their rates to zero) when disabling if
> it wants to support reconfiguration.
>
>> Shouldn't codec always be the last in the chain? What would be a case
>> where you don't want it at the end of the chain?
>
> How are you deciding what the ordering for "the chain" should be in the
> first place?  It seems like you're just assuming that it's what you want
> to set for your system which in turn appears to be derived from what
> you're using as clock master, it's very common for the CODEC to be the
> clock master in a system.
>
> One could equally argue here that the master shouldn't allow itself to
> have the clock rate reprogrammed when it has something deriving a clock
> from it (after all if that thing is running it might be disrupted).

Also, I do have to do a codec_set_sysclk when I change it to notify
the sgtl5000 codec that it has been changed.

The TI codecs are nicer in this regard. They have an external crystal
and can then autolock onto whatever combo of MCLK/SCLK/LRCLK is being
sent to them.  My board with the TI codec aren't ready yet so I'm
playing around trying to get this sgtl5000 working. AKAIK Wolfson
still doesn't have anything comparable to the TAS5716.  We run two 20W
channels through it and then an external 40W FET for the sub.




-- 
Jon Smirl
jonsmirl at gmail.com