linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [alsa-devel] [PATCH] ASoC: Add new TI TLV320AIC3204 CODEC driver
Date: Sat, 19 Jun 2010 02:25:09 +0100	[thread overview]
Message-ID: <20100619012509.GD2463@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20100618224313.GC30868@www.longlandclan.yi.org>

On Sat, Jun 19, 2010 at 08:43:14AM +1000, Stuart Longland wrote:

> I'll think about this over the next few days... but I'm thinking the
> basic structure of such a register cache would possibly take the form of
> something like this:
> 
> struct soc_reg_cache_pg {
> 	/* Page index; for single-page registers, this would be zero */
> 	int index;
> 	/* Number of registers cached */
> 	int size;
> 	/* Register offset cached */
> 	int offset;
> 	/* Pointer to register flags */
> 	const int *flags_data[];
> 	/* Pointer to default values */
> 	const int *default_data[];

This should probably be either unsigned or void (the latter allowing for
pluggable register sizes - otherwise you might burn as much data as you
save from the sparseness on chips that have small registers).

> ... then you'd use several of these in an array... one for each block of
> registers in a page.  If your device uses sparse registers, you can use
> the next_block pointer to point to the next such struct that has the
> next bank of registers, to save you scanning through *every* struct.

This is going to be painful to write out when writing the data table -
if it's useful to do it'd be better to do it at runtime, but I think
rather than handling pages it would be at least as easy to munge the
page number into the register number like everyone does at the minute
and then just optimise plain register lookups in a sparse map.  That way
way sparse chips of all kinds get the benefit.

> The register cache could be an array of pointers, size equal to the
> total number of pages, if a page is not used; it is set to NULL.  If a
> page is sparse, the other blocks would be accessed using the next_block
> pointer.

Like I say, I think optimising for page based access is not the most
general approach - it'd be better to optimise sparse register maps in
general and then map page based register maps onto this.

  reply	other threads:[~2010-06-19  1:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-18  3:57 [PATCH] ASoC: Add new TI TLV320AIC3204 CODEC driver Stuart Longland
2010-06-18 11:01 ` Liam Girdwood
2010-06-18 11:33   ` Stuart Longland
2010-06-18 15:53     ` Mark Brown
2010-06-18 22:43       ` [alsa-devel] " Stuart Longland
2010-06-19  1:25         ` Mark Brown [this message]
2010-06-18 22:24 ` Stuart Longland
2010-06-19  1:12   ` Mark Brown
2010-06-19  9:49     ` [alsa-devel] " Stuart Longland
2010-06-19 10:57       ` Mark Brown
2010-06-21 23:43     ` Stuart Longland
2010-06-22 10:15       ` 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=20100619012509.GD2463@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).