alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
	Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 4/4] ASoC: soc-cache: Add support for LZO based register caching
Date: Fri, 22 Oct 2010 09:18:51 -0700	[thread overview]
Message-ID: <20101022161850.GF16521@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1287757702-9573-5-git-send-email-dp@opensource.wolfsonmicro.com>

On Fri, Oct 22, 2010 at 03:28:22PM +0100, Dimitris Papastamos wrote:

> This patch adds support for LZO compression when storing the register
> cache.  The initial register defaults cache is marked as __devinitconst
> and the only change required for a driver to use LZO compression is

This looks good, though the changelog could use a bit more discussion as
to the tradeoffs involved - clearly we're trading CPU consumption for
memory consumption here, but things like numbers about the sorts of
compression you can get and the amount of CPU time burned relative to
the actual I/O operations would help people understand when and how to
use this.

Actually, now that I think about it debug data either via debugfs or via
dev_dbg() showing the before and after memory sizes would be very useful
for people trying to decide if their register map compresses down well
enough to really benefit from compression.

It looks like this patch also needs to add selects for LZO_COMPRESS and
LZO_DECOMPRESS to Kconfig, otherwise we'll fail to build if nothing else
has enabled them.

> to set the compress_type member in codec->driver to
> SND_SOC_LZO_COMPRESSION.

It would be good if machine drivers were able to override this, 

> +static int snd_soc_compress_cache_block(struct snd_soc_codec *codec,
> +					struct snd_soc_lzo_ctx *lzo_ctx)
> +{

This is all rather assuming that LZO is the only compression method we
can use?  It doesn't really matter, though, as this is all internal to
the cache code so we can deal with adding new compression types as and
when we want them.

  reply	other threads:[~2010-10-22 16:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22 14:28 [PATCH 0/4] ASoC: Implement new caching API Dimitris Papastamos
2010-10-22 14:28 ` [PATCH 1/4] ASoC: soc.h: Add new caching API prototypes and hooks Dimitris Papastamos
2010-10-22 15:44   ` Mark Brown
2010-10-22 14:28 ` [PATCH 2/4] ASoC: soc-cache: Add support for standard register caching Dimitris Papastamos
2010-10-22 16:03   ` Mark Brown
2010-10-23 18:24     ` Dimitris Papastamos
2010-10-24 13:18       ` Timur Tabi
2010-10-24 21:35         ` Mark Brown
2010-10-25  8:09           ` Dimitris Papastamos
2010-10-22 14:28 ` [PATCH 3/4] ASoC: soc-core: Adapt soc-core to fit the new caching API Dimitris Papastamos
2010-10-22 14:28 ` [PATCH 4/4] ASoC: soc-cache: Add support for LZO based register caching Dimitris Papastamos
2010-10-22 16:18   ` Mark Brown [this message]
2010-10-23 18:28     ` Dimitris Papastamos
2010-10-25 18:13       ` 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=20101022161850.GF16521@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=dp@opensource.wolfsonmicro.com \
    --cc=lrg@slimlogic.co.uk \
    --cc=patches@opensource.wolfsonmicro.com \
    /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).