[alsa-devel] Ordering in soc_pcm_hw_params()

[Mark Brown]

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140811/83c2e473/attachment.sig>