Re: ASoC: hook for codec control updates and clock controls

[Mark Brown <broonie@sirena.org.uk>]

On Mon, Dec 08, 2008 at 01:04:50AM +0100, Daniel Mack wrote:
> On Sun, Dec 07, 2008 at 07:02:40PM +0000, Mark Brown wrote:

> > The clocking is the responsibility of the board driver - often the
> > clocks are disabled while the link is inctive but this up to the board
> > driver (and ultimately the hardware design).

> That makes sense. However, there is this special case I'm facing here -
> the codec's volume settings are updated and the board driver doesn't
> notice that, so it can't react and switch on the clock for some time.

The normal thing would be to never turn off the master clock.  This is a
very common setup - many systems will have a dedicated crystal for the
codec which can never be disabled.  Do you actually need to turn off the
clock (and are you sure that the codec is happy about that)?

> The idea is to provide a way for codecs to signal the need for the
> master clock (or whatever clock) to be applied externally. And it's
> actually not important what it takes to actually do that - a generic way
> the board support code can use would be good.

This would need to at least specify the clock that needs to be turned
on and how many cycles it needs to be turned on for.  I'm having a hard
time getting enthusiastic about that, it seems like too much software
especially since we can't use the clock API for any of this due to the
inconsistent implementations.

In what circumstances does the codec need the clock?  What are the
negative consequences of it not being enabled?  If it only needs the
clock when bypass paths are active then we should just fix the bias
level control to set bias on when only analogue paths are active (this
ought to be done anyway) and the machine driver can use the bias level
callback to enable the clocks.  If it needs it at other times are you
sure that the device is supposed to tolerate being used with the MCLK
removed?