From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Timur Tabi <timur@freescale.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"patches@opensource.wolfsonmicro.com"
<patches@opensource.wolfsonmicro.com>,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 1/2] ASoC: soc-cache: Use reg_def_copy instead of reg_cache_default
Date: Thu, 6 Jan 2011 21:20:48 +0000 [thread overview]
Message-ID: <20110106212047.GF8018@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4D25ED43.9010701@freescale.com>
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.
next prev parent reply other threads:[~2011-01-06 21:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-02 16:11 [PATCH 0/2] ASoC: Override codec compress_type from the machine driver Dimitris Papastamos
2010-12-02 16:11 ` [PATCH 1/2] ASoC: soc-cache: Use reg_def_copy instead of reg_cache_default Dimitris Papastamos
2011-01-05 21:04 ` Timur Tabi
2011-01-05 23:03 ` Mark Brown
2011-01-05 23:08 ` Timur Tabi
2011-01-05 23:29 ` Mark Brown
2011-01-05 23:51 ` Mark Brown
2011-01-06 0:15 ` Tabi Timur-B04825
2011-01-06 0:34 ` Mark Brown
2011-01-06 16:26 ` Timur Tabi
2011-01-06 21:20 ` Mark Brown [this message]
2011-01-06 16:53 ` Dimitris Papastamos
2011-01-06 17:01 ` Timur Tabi
2010-12-02 16:11 ` [PATCH 2/2] ASoC: soc-core: Allow machine drivers to override compress_type Dimitris Papastamos
2010-12-03 16:14 ` [PATCH 0/2] ASoC: Override codec compress_type from the machine driver Liam Girdwood
2010-12-03 16:41 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110106212047.GF8018@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=lrg@slimlogic.co.uk \
--cc=patches@opensource.wolfsonmicro.com \
--cc=timur@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).