[alsa-devel] [RFC PATCH] Add combined clock support to Atmel SoC audio
Mark Brown
broonie at opensource.wolfsonmicro.com
Wed Nov 24 13:58:41 CET 2010
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.
More information about the Alsa-devel
mailing list