Re: regcache_sync() errors for read-only registers cache

[Takashi Iwai <tiwai@suse.de>]

At Tue, 3 Mar 2015 20:04:26 +0000,
Mark Brown wrote:
> 
> On Tue, Mar 03, 2015 at 04:33:21PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > Why should adding something to the defaults hurt performance (it should
> > > just be a one time cost to insert the default which we've got a
> > > reasonable chance of making back later)?  I guess if there's a lot of
> > > these registers it'll add up but they're pretty rare, usually it's a few
> > > ID and revision registers and anything else is volatile so wouldn't get
> > > cached at all.
> 
> > I caught this bug because of the currently developed HD-audio regmap
> > support that has lots of read-only stuff (mostly for parameters, dozen
> > of such per each widget node).  Registers range of 32bit wide and
> > there are no static default values that can be stored in a flat
> > table.  Nasty, eh?  I'll be glad if any better workaround is present
> > in regmap.
> 
> Well, if they're quick to read marking them as volatile to avoid the
> cache would be the obvious thing, or not caring about writeability.

Reading is much slower than writing due to sync.

> You can also specify num_reg_defaults_raw with no defaults table and
> it'll read the hardware in one fell swoop, though that would need some
> improvement for sparse registers and probably won't do the right thing
> for the other registers either (it's a bit specialist for PMICs).

For HD-audio, we can't read the whole verbs beforehand because we
don't know exactly which verbs will be used until the whole parsing is
done and the state changes.  So, the best option is just caching the
read-only parameters.

> > I can resend the patch if you prefer, of course, if the original patch
> > is OK.  Just let me know.
> 
> Yes, please resend - I'd guess you want to fix the block case too?

OK, will resend later together with the block raw fix.


Takashi