[alsa-devel] [PATCH v6] ASoC: add RT286 CODEC driver
Mark Brown
broonie at kernel.org
Mon May 12 22:29:18 CEST 2014
On Thu, May 08, 2014 at 10:57:44AM +0200, Lars-Peter Clausen wrote:
> There is still structure, the mapping function does not have to understand
> each register it only has to understand each verb and the driver uses maybe
> 6-7 different verbs, so it is not that bad. The code would basically look
> like this:
> write_reg(addr, val)
> {
> verb = EXTRACT_VERB(addr);
> nid = EXTRACT_NID(addr);
> pid = EXTRACT_PID(addr);
>
> switch (verb) {
> case VERB1:
> return write_verb1(nid, pid, val):
> case VERB2:
> return write_verb2(nid, pid, val):
> ....
> }
> }
> Where pid is verb specific additional addressing information that is used in
> the verbs payload.
Yeah, it's not exactly a model of niceness though. It's looking an
awful lot like we didn't manage to abstract things properly and setting
off alarm bells as a result.
> >So how does HDA handle this? We can obviously keep recording settings
> >in the same way as we do for virtual enums, writing them out shouldn't
> >be so hard. The cache code isn't going to buy us much if we have to
> >write things out control by control anyway, it essentially just boils
> >down to a fancy list walk.
> It's not just the DAPM stuff, but also the normal controls, for which we do
> not have per control caching.
That seems like a simple matter of programming to resolve.
> >If you really want to reuse regmap having a write only regmap internal
> >to the driver (not presented to ASoC) which just remembers the last
> >value written to every NID/VID combination might work and at least
> >avoids the ugly bits with trying to convince ASoC there are registers
> >since you don't need to worry about reading the data back and can just
> >pretend that read values match written values since we never look at
> >them except to write them back out.
> Yes kind of.
Kind of? It solves the cache sync case and if it's write only then we
won't need to go to the register map for reads anyway (outside of
interrupt handling and so on).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140512/57e2ec22/attachment.sig>
More information about the Alsa-devel
mailing list