[alsa-devel] ASoC: about the array to cache registers

Takashi Iwai tiwai at suse.de
Fri Jul 24 11:43:22 CEST 2009


At Fri, 24 Jul 2009 10:18:13 +0100,
Mark Brown wrote:
> 
> On Fri, Jul 24, 2009 at 04:06:43PM +0900, Joonyoung Shim wrote:
> 
> > Many ASoC codec drivers have an array to cache registers.
> > The array is not used any longer after memcpy to codec->reg_cache.
> > I think that memcpy is unnecessary, and it a waste of the memory.
> 
> > How about continue using the array instead of memcpy?
> 
> There's two reasons we keep the data around at the minute.  One is that
> in future we'd like to be able to have more than one CODEC, including
> more tha one of the same type.  Obviously there's some devices are more
> likely to be used in such a configuration than others but you do see
> some unusual hardware designs.
> 
> The other is that the default values can be used to reduce the amount of
> data that needs to be written back to the CODEC to restore the registers
> at resume time by only writing non-default values.  This can speed up
> resume, especially on larger devices and where the control bus is
> contended, but it's not been widely implemented.

One more thing.  In theory, the driver can be bound/unbound without
reloading.  When unbound, the static array remains as changed.
Now when you binding again, this changed array is used as the initial
state, thus it puts the driver into a wrong start up.

> For the devices that don't do the resume operation we should at least
> mark the arrays as __devinitdata so they can be discarded.

For const data, __devinitconst should be used instead in general.
At least, there were problems regarding with const and __devinitdata
on some archs like ia64.  I guess most architectures for ASoC are
likely OK with __devinitdata, though :)


Takashi


More information about the Alsa-devel mailing list