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

We probably need something like EPROBE_DEFER that is used in the
driver subsystem to allow that various pieces to so this out.

-- 
Jon Smirl
jonsmirl at gmail.com