All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liam Girdwood <lrg@slimlogic.co.uk>
To: Stuart Longland <redhatter@gentoo.org>
Cc: ALSA Development List <alsa-devel@alsa-project.org>,
	Takashi Iwai <tiwai@suse.de>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: Add new TI TLV320AIC3204 CODEC driver
Date: Fri, 18 Jun 2010 12:01:02 +0100	[thread overview]
Message-ID: <1276858862.3054.28.camel@odin> (raw)
In-Reply-To: <1276833465-31702-1-git-send-email-redhatter@gentoo.org>

On Fri, 2010-06-18 at 13:57 +1000, Stuart Longland wrote:
> The TLV320AIC3204 is a low-power stereo audio CODEC capable of sample
> rates of up to 192kHz.  This driver implements basic functionality,
> using I²C for the control channel.
> 
> The audio interface supports many data bus formats, including I²S
> master/slave, DSP, left/right justified and TDM.
> 
> What works:
> 	- Playback at various bitrates up to 96kHz
> 	- Recording at various bitrates up to 96kHz
> 	- Mixer interface
> 	- PLL generation of CODEC clocks from MCLK
> 
> What could work better:
> 	- DAPM
> 
> What isn't tested:
> 	- Audio interfaces other than I²S
> 	- PLL with clocks other than ~12MHz
> 	- Mono recording/playback
> 	- 192kHz recording/playback
> 
> What isn't implemented:
> 	- SPI interface support
> 	- PLL without fractional divider (would allow <10MHz clocks)
> 	- Clock sources other than MCLK
> 	- Adaptive filtering
> 	- AGC
> 	- Headset detection, JACK framework
> 
> Signed-off-by: Stuart Longland <redhatter@gentoo.org>

Just had a quick check and the register caching needs addressed.

I agree with your comments, I don't think we really want to cache all
16K of codec registers here as we will probably only ever use a handful
of them. I think a smaller lookup table containing only the registers
that we care about will do.

Fwiw, a generic ASoC lookup table would be best as this could be used by
other codecs with large register maps too. The table should be ordered
(for quick lookup) and also contain a readable/writeable/volatile flag
for each register.

Thanks

Liam
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

WARNING: multiple messages have this Message-ID (diff)
From: lrg@slimlogic.co.uk (Liam Girdwood)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ASoC: Add new TI TLV320AIC3204 CODEC driver
Date: Fri, 18 Jun 2010 12:01:02 +0100	[thread overview]
Message-ID: <1276858862.3054.28.camel@odin> (raw)
In-Reply-To: <1276833465-31702-1-git-send-email-redhatter@gentoo.org>

On Fri, 2010-06-18 at 13:57 +1000, Stuart Longland wrote:
> The TLV320AIC3204 is a low-power stereo audio CODEC capable of sample
> rates of up to 192kHz.  This driver implements basic functionality,
> using I?C for the control channel.
> 
> The audio interface supports many data bus formats, including I?S
> master/slave, DSP, left/right justified and TDM.
> 
> What works:
> 	- Playback at various bitrates up to 96kHz
> 	- Recording at various bitrates up to 96kHz
> 	- Mixer interface
> 	- PLL generation of CODEC clocks from MCLK
> 
> What could work better:
> 	- DAPM
> 
> What isn't tested:
> 	- Audio interfaces other than I?S
> 	- PLL with clocks other than ~12MHz
> 	- Mono recording/playback
> 	- 192kHz recording/playback
> 
> What isn't implemented:
> 	- SPI interface support
> 	- PLL without fractional divider (would allow <10MHz clocks)
> 	- Clock sources other than MCLK
> 	- Adaptive filtering
> 	- AGC
> 	- Headset detection, JACK framework
> 
> Signed-off-by: Stuart Longland <redhatter@gentoo.org>

Just had a quick check and the register caching needs addressed.

I agree with your comments, I don't think we really want to cache all
16K of codec registers here as we will probably only ever use a handful
of them. I think a smaller lookup table containing only the registers
that we care about will do.

Fwiw, a generic ASoC lookup table would be best as this could be used by
other codecs with large register maps too. The table should be ordered
(for quick lookup) and also contain a readable/writeable/volatile flag
for each register.

Thanks

Liam
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

  reply	other threads:[~2010-06-18 11:01 UTC|newest]

Thread overview: 33+ 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  3:57 ` Stuart Longland
2010-06-18  3:57 ` Stuart Longland
2010-06-18 11:01 ` Liam Girdwood [this message]
2010-06-18 11:01   ` Liam Girdwood
2010-06-18 11:33   ` Stuart Longland
2010-06-18 11:33     ` Stuart Longland
2010-06-18 11:33     ` Stuart Longland
2010-06-18 15:53     ` Mark Brown
2010-06-18 15:53       ` Mark Brown
2010-06-18 15:53       ` Mark Brown
2010-06-18 22:43       ` Stuart Longland
2010-06-18 22:43         ` [alsa-devel] " Stuart Longland
2010-06-18 22:43         ` Stuart Longland
2010-06-19  1:25         ` Mark Brown
2010-06-19  1:25           ` [alsa-devel] " Mark Brown
2010-06-19  1:25           ` Mark Brown
2010-06-18 22:24 ` Stuart Longland
2010-06-18 22:24   ` Stuart Longland
2010-06-19  1:12   ` Mark Brown
2010-06-19  1:12     ` Mark Brown
2010-06-19  1:12     ` Mark Brown
2010-06-19  9:49     ` [alsa-devel] " Stuart Longland
2010-06-19  9:49       ` Stuart Longland
2010-06-19 10:57       ` Mark Brown
2010-06-19 10:57         ` [alsa-devel] " Mark Brown
2010-06-19 10:57         ` Mark Brown
2010-06-20 11:28         ` Stuart Longland
2010-06-20 13:20           ` Mark Brown
2010-06-21 23:43     ` Stuart Longland
2010-06-21 23:43       ` Stuart Longland
2010-06-22 10:15       ` Mark Brown
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=1276858862.3054.28.camel@odin \
    --to=lrg@slimlogic.co.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=redhatter@gentoo.org \
    --cc=tiwai@suse.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.