Re: [RFC PATCH] Add combined clock support to Atmel SoC audio

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Wed, Nov 24, 2010 at 05:02:55PM +1300, Ryan Mallon wrote:

> Okay, regular spin_lock should be okay right?

I guess, though something like a mutex would seem more normal.

> > Is this done by the driver normally, or is it done by the machine
> > normally?  If it's normally done by the machine perhaps it should be
> > moved into the driver in all cases.

> Essentially this code is overriding the settings in the hw_params switch
> statement for the combined clocks case. This will need to be overridden
> each time hw_params is called. Doing it here seems logical since
> atmel_ssc_dai:hw_params does the original setting. It keeps the machine
> drivers simpler too.

That's my point - if the machine drivers normally need to do this
(sam9g20ek certainly needed to configure the pinmux) then we should just
be doing this all the time.

> >> +		if (dir == 1) {
> >> +			/*
> >> +			 * Set the TX clock period to the RX clock period
> >> +			 * FIXME - Is this okay if we are already doing TX?
> >> +			 */
> >> +			tcmr &= 0x00ffffff;
> >> +			tcmr |= rcmr & 0xff000000;

> > Should probably enforce a constraint to stop users doing something that
> > forces the change?

> Okay. Could you point me at an example for this please.

symmetric_rates probably covers it.