[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