From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] ASoC: core: cache index fix
Date: Wed, 3 Aug 2011 01:05:39 +0900 [thread overview]
Message-ID: <20110802160538.GG25884@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <65EE16ACC360FA4D99C96DC085B3F7721F427D@039-SN1MPN1-002.039d.mgd.msft.net>
On Tue, Aug 02, 2011 at 09:41:22AM +0000, Dong Aisheng-B29396 wrote:
> > No, I think we should hide these decisions completely within the cache
> > code.
> Yes, but the issue is that hw_read will check if reg is in cache array
> And checking like " if (reg >= codec->driver->reg_cache_size ||" is wrong
> when the step is not 1 that will cause registers with their index are greater
> than cache index will not be able to fetch data from cache.
This is in no way inconsistent with what I'm saying above.
> > A
> > register map with step size greater than one should never have more than
> > one register in a block anyway with the current code so the step size
> > should never be perceptible.
> The question is that rbtree uses reg index to index as follows:
The rbtree should only see registers meaning registers.
> if (rbnode) {
> snd_soc_rbtree_get_base_top_reg(rbnode, &base_reg, &top_reg);
> if (reg >= base_reg && reg <= top_reg) {
> reg_tmp = reg - base_reg;
> *value = snd_soc_rbtree_get_register(rbnode, reg_tmp);
> return 0;
> }
> }
> So the block may be reg0, reg2, reg4.....
> And the block is flat, the value is get/set by rbnode->block[reg_tmp]:
> I understand right, there may be hole in the block, right?
No. The rbtree is dealing with registers only. The rbtree has no idea
about steps, and nor should it.
> > It occurs to me that what we want to do here may be to make a new
> > register cache type for step sizes then hide all the complexity for these
> > devices in there. That keeps everything together and ensures that newer
> > devices don't pay a complexity cost.
> If we add new cache type, does it have any big difference with FLAT?
> Maybe if we can fix the cache step issue, the FLAT cache can be reuse.
Step size and if you want to keep the defaults also compressed then the
defaults size.
next prev parent reply other threads:[~2011-08-02 16:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-01 11:38 [PATCH 1/1] ASoC: core: cache index fix Dong Aisheng
2011-08-01 11:51 ` Mark Brown
2011-08-02 8:03 ` Dong Aisheng-B29396
2011-08-02 8:38 ` Mark Brown
2011-08-02 9:41 ` Dong Aisheng-B29396
2011-08-02 10:34 ` [alsa-devel] " Takashi Iwai
2011-08-02 10:55 ` Dong Aisheng-B29396
2011-08-02 11:09 ` Takashi Iwai
2011-08-02 11:15 ` Dong Aisheng-B29396
2011-08-02 12:10 ` Takashi Iwai
2011-08-02 12:29 ` Dong Aisheng-B29396
2011-08-02 12:52 ` Takashi Iwai
2011-08-02 15:48 ` Mark Brown
2011-08-02 16:13 ` Takashi Iwai
2011-08-02 16:40 ` Mark Brown
2011-08-02 18:06 ` Takashi Iwai
2011-08-03 5:23 ` Mark Brown
2011-08-03 6:20 ` Takashi Iwai
2011-08-03 9:00 ` Mark Brown
2011-08-03 7:03 ` Dong Aisheng-B29396
2011-08-03 7:39 ` Dong Aisheng-B29396
2011-08-03 9:31 ` Mark Brown
2011-08-03 11:11 ` Dong Aisheng-B29396
2011-08-02 12:58 ` Mark Brown
2011-08-02 13:17 ` Dong Aisheng-B29396
2011-08-02 15:27 ` Mark Brown
2011-08-02 16:05 ` Mark Brown [this message]
2011-08-02 9:51 ` Wolfram Sang
2011-08-02 10:38 ` [alsa-devel] " Takashi Iwai
2011-08-02 15:29 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110802160538.GG25884@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).