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).