From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: snd soc spi read/write Date: Thu, 11 Aug 2011 14:32:53 +0900 Message-ID: <20110811053246.GA16655@opensource.wolfsonmicro.com> References: <20110810145549.GA5724@opensource.wolfsonmicro.com> <20110810150316.GF5724@opensource.wolfsonmicro.com> <20110810153457.GG5724@opensource.wolfsonmicro.com> <4E42F89A.2020008@metafoo.de> <20110811003311.GA10574@opensource.wolfsonmicro.com> <4E433569.7000702@metafoo.de> <20110811024638.GA14592@opensource.wolfsonmicro.com> <4E4347DA.5000800@metafoo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from opensource2.wolfsonmicro.com (opensource.wolfsonmicro.com [80.75.67.52]) by alsa0.perex.cz (Postfix) with ESMTP id D8271243C7 for ; Thu, 11 Aug 2011 07:33:09 +0200 (CEST) Content-Disposition: inline In-Reply-To: <4E4347DA.5000800@metafoo.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Lars-Peter Clausen Cc: Takashi Iwai , uclinux-dist-devel@blackfin.uclinux.org, Scott Jiang , alsa-devel@alsa-project.org, dp@opensource.wolfsonmicro.com List-Id: alsa-devel@alsa-project.org 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.