[alsa-devel] snd soc spi read/write

Mark Brown broonie at opensource.wolfsonmicro.com
Thu Aug 11 07:32:53 CEST 2011

On Thu, Aug 11, 2011 at 05:09:14AM +0200, Lars-Peter Clausen wrote:
> On 08/11/2011 04:46 AM, Mark Brown wrote:

> > None of the current ASoC code will coalesce register writes at all, and
> > in the case where you're doing writes to registers that aren't actually
> > adjacent it's going to be marginal if it's better to transmit the
> > intervening register or transmit another register address.  That only
> > really makes a difference during cache sync anyway.

> I was think more in terms of in memory consumption and lookup time of the cache
> compared to a flat cache. If you have two blocks which have a gap of one
> register between them and that register gets inserted into the cache, ideally
> those two blocks would be merged, which doesn't seem to be the case currently.
> So instead of one rbnode with a block covering the whole register space you'll
> end up with a lot of smaller rbnodes.

My guess is that it's probably not worth worrying about, especially for
performance where you mostly just need to be better than physical I/O.
For small register maps the memory overhead is similarly probably not
worth worrying about, and obviously there's also LZO.

> > Yes, as I said in one of the earlier messages in this thread.  It seems
> > like a good combination of being writable/legible and compact.

> Hm, ok I'll give it a try. Though I'm not sure yet how to efficiently implement
> the default register lookup when syncing the cache.

The caches can just unpack into their data, we need to take a copy
anyway to allow the caches to be marked as __initdata and then the data
will end up stored in a format that matches the method we're using to
store the data.

Dimitris had done an initial version of the move of the cache over,
though I didn't review it properly yet and he's on holiday now.  I might
repost it, there were a few issues but it's at least 90% of the way
there IIRC from the time I had to look at it.

More information about the Alsa-devel mailing list