From: Lars-Peter Clausen <lars@metafoo.de>
To: Mark Brown <broonie@kernel.org>
Cc: Oder Chiou <oder_chiou@realtek.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
Bard Liao <bardliao@realtek.com>,
Gustaw Lewandowski <gustaw.lewandowski@intel.com>,
Flove <flove@realtek.com>
Subject: Re: [PATCH v6] ASoC: add RT286 CODEC driver
Date: Wed, 07 May 2014 20:21:02 +0200 [thread overview]
Message-ID: <536A798E.6010408@metafoo.de> (raw)
In-Reply-To: <20140507180705.GJ22111@sirena.org.uk>
On 05/07/2014 08:07 PM, Mark Brown wrote:
> On Wed, May 07, 2014 at 07:46:09PM +0200, Lars-Peter Clausen wrote:
>
>> I don't think virtual controls are the right approach here. Virtual controls
>> are for controls where the state is completely in software, but here the
>> state is still in hardware. It's just that there is no uniform hardware map.
>> But there is still some structure. So you'd have controls with custom put
>> and get handlers and for DAPM widgets use the event handler.
>
> What you just described is what I'd consider a virtual control - I don't
> consider the fact that the put callbacks end up writing to the hardware
> particularly substantial, as far as the framework is concerned some
> driver specific thing goes off and does something but it could be
> setting a variable just as well as writing to hardware.
Ok, but we have controls that have virtual in their name, so I think it
should be made clear that you are not talking about those.
>
>> But I still think that the best and easiest solution is to have custom
>> regmap read/write function that do the translation of logical registers to
>> physical read/write operations.
>
> That's the first time this idea has been mentioned that I recall. I
> have to say I'm really not keen on pushing non-physical registers
> through regmap, all the drivers that have done that previously have
> ended up causing problems though if the registers were *all* fake then
> there would be less issue (most of the issues have been due to having
> extra registers that don't really exist). It does still feel like it's
> a layering problem though.
I think the drivers you are thinking of are those which had physical
register which were backed by hardware and virtual register which were
backed by software. For the later we introduced the virtual controls, so
that such hacks are no longer necessary in driver. But in the case of the
RT286 all the register all still backed by hardware except that the way they
are accessed is not very uniform (different types of registers use a
different message format, there is a asymmetry between reading and writing
the same data). In a sense this is similar to devices which have registers
with different sizes, we also support these with custom regmap callbacks.
- Lars
next prev parent reply other threads:[~2014-05-07 18:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 5:59 [PATCH v6] ASoC: add RT286 CODEC driver bardliao
2014-04-15 12:04 ` Mark Brown
2014-04-16 13:26 ` Bard Liao
2014-04-16 21:11 ` Mark Brown
2014-04-17 5:39 ` Bard Liao
2014-04-18 10:37 ` Mark Brown
2014-05-06 12:04 ` Bard Liao
2014-05-07 17:21 ` Mark Brown
2014-05-07 17:46 ` Lars-Peter Clausen
2014-05-07 18:07 ` Mark Brown
2014-05-07 18:21 ` Lars-Peter Clausen [this message]
2014-05-07 19:49 ` Mark Brown
2014-05-08 7:05 ` Lars-Peter Clausen
2014-05-08 8:00 ` Mark Brown
2014-05-08 8:57 ` Lars-Peter Clausen
2014-05-12 11:08 ` Bard Liao
2014-05-12 14:51 ` Lars-Peter Clausen
2014-05-12 20:29 ` Mark Brown
2014-06-04 12:08 ` Bard Liao
2014-06-04 12:37 ` 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=536A798E.6010408@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=bardliao@realtek.com \
--cc=broonie@kernel.org \
--cc=flove@realtek.com \
--cc=gustaw.lewandowski@intel.com \
--cc=lgirdwood@gmail.com \
--cc=oder_chiou@realtek.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