All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liam Girdwood <lrg@ti.com>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Dong Aisheng-B29396 <B29396@freescale.com>,
	Zeng Zhaoming <b32542@freescale.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH RESEND] ASoC: sgtl5000: fix cache handling
Date: Tue, 2 Aug 2011 21:11:44 +0100	[thread overview]
Message-ID: <4E385A00.6060809@ti.com> (raw)
In-Reply-To: <1312306939-5140-1-git-send-email-w.sang@pengutronix.de>

On 02/08/11 18:42, Wolfram Sang wrote:
> Cache handling in this driver is broken. The chip has 16-bit registers, yet the
> register numbers also increase by 2 per register, i.e.  there are only
> even-numbered registers. The cache in this driver, though, simply increments
> register numbers, so it does need some mapping as seen in
> sgtl5000_restore_regs(), note the '>> 1':
> 
> 	snd_soc_write(codec, SGTL5000_CHIP_LINREG_CTRL,
>                         cache[SGTL5000_CHIP_LINREG_CTRL >> 1]);
> 
> That, of course, won't work with snd_soc_update_bits(). (Thus, we won't even
> notice the missing register 0x1c in the default regs which shifted all follwing
> registers to wrong values.) Noticed on the MX28EVK where enabling the regulators
> simply locked up the chip.
> 
> Refactor the routines and use a properly sized default_regs array which matches
> the register layout of the underlying chip, i.e. create a truly flat cache.
> This also saves some code which should make up for the bigger array a little.
> When soc-core will somewhen have another cache type which handles a step size,
> this conversion will also ease the transition.

This would probably be the preferred solution. I guess we can wait a little longer for this fix.

> 
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Tested-by: Dong Aisheng <b29396@freescale.com>
> Tested-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Zeng Zhaoming <b32542@freescale.com>
> Cc: Liam Girdwood <lrg@ti.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---

Acked-by: Liam Girdwood <lrg@ti.com>

WARNING: multiple messages have this Message-ID (diff)
From: lrg@ti.com (Liam Girdwood)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND] ASoC: sgtl5000: fix cache handling
Date: Tue, 2 Aug 2011 21:11:44 +0100	[thread overview]
Message-ID: <4E385A00.6060809@ti.com> (raw)
In-Reply-To: <1312306939-5140-1-git-send-email-w.sang@pengutronix.de>

On 02/08/11 18:42, Wolfram Sang wrote:
> Cache handling in this driver is broken. The chip has 16-bit registers, yet the
> register numbers also increase by 2 per register, i.e.  there are only
> even-numbered registers. The cache in this driver, though, simply increments
> register numbers, so it does need some mapping as seen in
> sgtl5000_restore_regs(), note the '>> 1':
> 
> 	snd_soc_write(codec, SGTL5000_CHIP_LINREG_CTRL,
>                         cache[SGTL5000_CHIP_LINREG_CTRL >> 1]);
> 
> That, of course, won't work with snd_soc_update_bits(). (Thus, we won't even
> notice the missing register 0x1c in the default regs which shifted all follwing
> registers to wrong values.) Noticed on the MX28EVK where enabling the regulators
> simply locked up the chip.
> 
> Refactor the routines and use a properly sized default_regs array which matches
> the register layout of the underlying chip, i.e. create a truly flat cache.
> This also saves some code which should make up for the bigger array a little.
> When soc-core will somewhen have another cache type which handles a step size,
> this conversion will also ease the transition.

This would probably be the preferred solution. I guess we can wait a little longer for this fix.

> 
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Tested-by: Dong Aisheng <b29396@freescale.com>
> Tested-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Zeng Zhaoming <b32542@freescale.com>
> Cc: Liam Girdwood <lrg@ti.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---

Acked-by: Liam Girdwood <lrg@ti.com>

  reply	other threads:[~2011-08-02 20:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-02 17:42 [PATCH RESEND] ASoC: sgtl5000: fix cache handling Wolfram Sang
2011-08-02 17:42 ` Wolfram Sang
2011-08-02 20:11 ` Liam Girdwood [this message]
2011-08-02 20:11   ` Liam Girdwood
2011-08-02 23:52 ` Mark Brown
2011-08-02 23:52   ` 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=4E385A00.6060809@ti.com \
    --to=lrg@ti.com \
    --cc=B29396@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=b32542@freescale.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=w.sang@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.