linux-kernel - Re: [PATCH] ASoC: Add new TI TLV320AIC3204 CODEC driver

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]

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/