[alsa-devel] [PATCH] ASoC: Codec driver for Texas Instruments tlv320dac33 codec

[Peter Ujfalusi]

On Tuesday 13 October 2009 12:26:22 ext Mark Brown wrote:
 
> I mean the pattern of suppressing I2C writes while the chip is powered
> down rather than the

I guess I have some good way of handling this (thanks to Eero for the idea)

> 
> > I'm not sure how to make sure that we can access to the chip, and at the
> > same time do not use extensive mutex lock/unlock for the I2C accesses.
> > Ideas?
> 
> Perhaps just call the mutex something more descriptive like chip_power
> or something might be enough make it clear what it's protecting?

Now that the mutex handling is cleaner in the chip power sense, I'll use the 
same mutex to protect the state as well (when the dac33 is in nSample mode).
It fits there nicely as well.

> > Hmm, yes you are right, it is kind of a mess...
> > I can think of the following:
> > dac33_set_power -> dac33_hard_reset
> > dac33_soft_power -> dac33_soft_reset
> >
> > In dac33_set_bias_level only toggle the dac33_soft_reset.
> > In dac33_soc_suspend/dac33_soc_resume I can use the dac33_hard_reset with
> > register restore.
> >
> > Does it makes it a bit cleaner?
> 
> I think so - it'd probably also help if the cache restore were merged
> into one of the functions too.  I'd be inclined to keep _power too.

You mean something like this:
dac33_set_power -> dac33_hard_power
dac33_soft_power -> dac33_soft_power

Or keeping the old names, but make the use of these more consequent?

 
> OK.  I'd expect that at some point people will want to control things
> like the digital routing.

I think, I will have the controls implemented before anyone would realize that 
they need control for those ;)
But it will be done in the future since it needs lot's of tries to get things 
sorted out.

-- 
Péter