Re: [PATCH 5/7] ASoC: TWL4030: Helper to check chip default registers

[Peter Ujfalusi <peter.ujfalusi@nokia.com>]

Hi,

You and Mark has a valid point...

On Tuesday 25 May 2010 16:09:56 ext Liam Girdwood wrote:
> On Tue, 2010-05-25 at 15:20 +0300, Peter Ujfalusi wrote:
> > > Is this purely for information/debug purposes ?
> > 
> > Yes, the driver support twl4030, twl5030, twl5031, tps*something* chips.
> > If someone, who have access to those chips, and in doubt, can check it.
> 
> So it's more a debug aid.

I'll change the dev_info to dev_dbg to reflect that correctly.

> 
> > > Why do we need to check default vales at init(). Is there another
> > > driver changing the audio codec registers ?
> > 
> > This driver is going to change it.
> > It is also possible that the bootloader changed them (startup tone?).
> 
> Yeah, that's what I thought. In the past I've always forced the CODEC
> registers to their default values during probe(). Very handy if the
> driver is a module and you are recovering from a buggy state.

Yeah, during development this is really handy.

> 
> > So it is not really bulletproof, but at least it helped me to find out
> > the the ARXR2_APGA_CTL register does not have the reset value, which it
> > supposed to have.
> > 
> > Well, I can remove it, but I thought that it is a nice touch ;)
> 
> It's nice ;) But maybe we should reset the default values at probe() to
> be sure.

I did run some tests.
The codec registers are in reset state whenever the device boots (either power 
on, or reboot). In our setup the codec is built in the kernel.
I have measured the time needed to execute the twl4030_init_chip with and 
without rewriting the codec registers (71 register writes):
No reset_registers: ~51ms
reset registers:    ~71ms

I need to optimize for module loading time, and ~20ms extra is quite big.

Can we make a compromise?
I propose to have twl4030_setup_data.reset_registers, if it is set by the 
machine driver, than we are going to reset the registers, if it is not set, than 
we skip the restore part (not writing the 71 registers).
So during development, or if one have the codec as module, the machine can set 
this, so the registers will be restored, but if the testing shows that there is 
no need to do that, than we can speed up the module probe.

What do you think?

> 
> Thanks
> 
> Liam
> 

-- 
Péter