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.