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