[alsa-devel] [PATCH 1/2] ASoC: soc-cache: Use reg_def_copy instead of reg_cache_default
broonie at opensource.wolfsonmicro.com
Thu Jan 6 22:20:48 CET 2011
On Thu, Jan 06, 2011 at 10:26:43AM -0600, Timur Tabi wrote:
> Mark Brown wrote:
> > In cases like this (although not I suspect this particular one) the
> > answer is often that there was't any particular consideration for
> > whatever unusual case you're looking at.
> Ah, but I don't think my case is "unusual". Frankly, I think it's unusual to
> hard-code default register values into a driver. I just don't see how you can
*sigh* If you look at other ASoC drivers you'll see that providing
register defaults is very much idiomatic.
> guarantee that the values will be correct for all supported revisions of the chip.
We've been doing this for rather a long time; many devices don't support
readback at all so there's not even any option for them. There's some
fairly simple things you can do if there are issues, like write out the
new default values explicitly (which will be a noop on new silicon).
There's fairly strong pressures on chip vendors to avoid anything that
causes issues here. Consider what a chip vendor has to do to introduce
an incompatible register change in production hardware: they need to
notify all their customers and they need to make sure that their
customers are happy and don't get upset about having to update their
software (perhaps they don't like the new default). If the customers
aren't happy then worst case you end up having to keep both old and new
silicon in production.
> On the CS4270, for instance, one register contains the chip revision number.
> There's no way I can know which revision will be used on any given board.
So that register should be marked as volatile, the register default
value will be ignored and the cache will never be used for that register.
More information about the Alsa-devel