lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1276858862.3054.28.camel@odin>
Date:	Fri, 18 Jun 2010 12:01:02 +0100
From:	Liam Girdwood <lrg@...mlogic.co.uk>
To:	Stuart Longland <redhatter@...too.org>
Cc:	ALSA Development List <alsa-devel@...a-project.org>,
	Takashi Iwai <tiwai@...e.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linux ARM Kernel <linux-arm-kernel@...ts.infradead.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: Add new TI TLV320AIC3204 CODEC driver

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@...too.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ