Re: snd soc spi read/write

[Lars-Peter Clausen <lars@metafoo.de>]

On 08/10/2011 05:34 PM, Mark Brown wrote:
> On Wed, Aug 10, 2011 at 05:15:21PM +0200, Takashi Iwai wrote:
>> Mark Brown wrote:
> 
>>> The idea is that the CODEC drivers will end up using regmap directly
>>> once it gets cache support migrated over to it.  There's nothing ALSA
>>> specific about the cache support.  Though right just not bothering to
>>> cache this device (it has readback support after all) is probably good
>>> enough.
> 
>> OK, I like the idea, but it sounds a bit like a long way to go.
>> I guess the cache-in-regmap won't be merged in 3.1 cycle?
> 
> Well, regmap is only in 3.2.
> 
>> Basically I don't care too much about this, but the fact we leave this
>> being broken over two release cycles doesn't appear nice, especially
>> when there is a quick-n-easy fix...
> 
> I don't see a problem with the idea of just making the registers
> volatile.  There's no real need to cache the registers on a small SPI
> device with readback support, the caches mainly benefit I2C (which is
> much slower) and devices with no readback support with some other
> benefits for larger devices.
> 

The problem is that there is no read-back support out of the box. Readback
requires setting the read bit in the registers address. Since this is not the
upper-most bit, the default regmap spi read wont work.

And if we have to add our own read function we could as very well add our own
write function which simply reinstates the old caching behavior.

In my opinion it would be nice if we could add a register cache base address,
which specifies the offset at which the cache-able registers start. For example
I have a codec driver in the queue where all non-volatile registers at 0x8000
and I don't really want to add 16k of zeros to the driver for the default
register cache.

- Lars