On Fri, Jun 11, 2010 at 03:55:12PM +1000, Stuart Longland wrote:
(1) When using the SOC_DOUBLE_R_SX_TLV controls, I notice there's an odd interaction between the mute switch associated with the control, and its corresponding gain setting.
Nothing changes in the actual registers (except the mute bit of course) but the displayed gain shoots up to infinity if the mute is toggled when the gain associated with that mute control is set below 0dB. When the gain is at 0dB or above, toggling the mute has no effect on the displayed gain setting.
This is almost always due to having an overlap between the bitfield for the volume and the mute bit.
(2) On the TLV320AIC3204, the clocks used on the audio bus can either be sourced from the ADC clocks, or the DAC clocks. Naturally, before you see any clocks on the bus, you must first power up either the DAC or ADC (or both), and choose the appropriate source. I do this currently in the hw_params callback (right where I *used* to power up the DACs/ADCs, DAPM does this now).
SND_SOC_DAPM_SUPPLY can help you here - you can have a conditional supply.
(3) The sysfs interface of my driver still remains. I had a look at using the ASoC debugfs interface, however there are a *lot* of registers on the 'AIC3204 in a sparse memory map. When I try to inspect the registers via /sys/kernel/debug/asoc/tlv320aic3204.0-0018/codec_reg ... I notice there are more registers in the device than are accessible via this interface:
Provide a display_register() callback which filters out the undefined registers or otherwise improve the standard functionality.
Notice it stops at 0x01b0 (corresponding to page 3, register 48), with an incomplete line. There were more registers, than there was buffer space to write the file. Is there a way to increase this buffer?
No, it's a sysfs limit.
The driver is still using the registration model that was used in kernel 2.6.34. I've managed to backport the ALSA tree to 2.6.28 for our project (since that's what's officially supported by Ka-Ro) and so far, it's working, although things are still quite crude.
If you could convince Ka-Ro to work with mainline that'd be nice :/
I cache more of the registers now, I tried doing something "clever" and skipping the pages of registers that aren't used and trying to cache just the pages that were meaningful, but I noticed that the rest of ALSA more or less assumed the register address used with cache was the real address. Digging around on the mailing list about how to handle a sparse register map lead me to the solution of just biting the bullet and caching all 80-odd pages. Wasteful on memory, but I won't miss anything.
If the registers are mostly clustered at the starts of pages then an array of pointers to per-page arrays might do the trick.
The driver still has an initialisation script facility, whereby custom register settings can be made at init. I'm still undecided as to whether to keep this or not... it's not the "done thing", but if I leave it there, it allows for custom adaptive filtering coefficients and other parameters to be set by the machine driver, which may be useful in some applications. Is it worth cleaning this up, or should it be ditched before the driver is submitted for inclusion?
If the data is stuff that's calculated off-line then it's reasonable to supply specific bits of data via platform data, several existing drivers do this for filter coefficients. Providing completely arbatrary register writes is not suitable for mainline.
The driver is accessible online at http://www.longlandclan.yi.org/~stuartl/asoc/ along with some comments about how to add it to your kernel sources. I'd appreciate any feedback or advice on how the driver can be improved.
Please post to the mailing list if you want review - the standard workflow is to provide comments by replying to the patch.