[alsa-devel] [PATCH 5/7] ASoC: TWL4030: Helper to check chip default registers
peter.ujfalusi at nokia.com
Wed May 26 08:00:35 CEST 2010
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?
More information about the Alsa-devel