[alsa-devel] Creating single-card driver for multi-codec (TLV320AIC34) board - is it possible at the machine level?
Hi ALSA developers,
I'm developing an ALSA driver for a new board with two TLV320AIC34 chips, which to a driver is the equivalent of 4 TLV320AIC31/2/3 (TLV320AIC3X driver) codecs. The platform is OMAP4, with the OMAP as I2C master.
TDM mode with one McBSP port is used, and it is desired that the four codecs appear as one 8-channel codec (clocks are shared and data buses are connected together). It is OK if there are 4 separate mixers, one for each codec. However, when starting/stopping audio all codecs should act together and audio data presented to the ALSA user interface just as with a single 8-channel sound card.
My questions have two parts: one on binding together the codecs into a "single card", and another on alterations to support an external sample-clock generator.
BONDING CODECS TOGETHER
It is desired to write the driver at the "machine" level (ignore the external-clock modification for now), without modifying the ALSA SoC core or the TLV320AIC3X driver. Is this possible? I've searched the internet and looked through the source code, and I have the following gaps in understanding:
The following TI link seems to suggest such TLV320AIC34 operation may already be possible with ALSA: http://e2e.ti.com/support/data_converters/audio_converters/w/design_notes/23...
However, one of the threads pointed in that link: http://comments.gmane.org/gmane.linux.alsa.devel/84899 suggests such support is not in the ALSA SoC core or the TLV320AIC3X driver. While it is mentioned that if configured appropriately, "you'll end up with a single card", later it is mentioned that
"you're probably trying to break new ground here. You're trying to bind all the CODECs together and treat them as one digital interface, currently the code does a series of point to point links multiplexed on a bus only."
What does point-to-point link mean in this context? What does "you'll end up with a single card" mean if all 8 channels are not exposed in one card? If it is new ground, then what does the rx51 driver do (it is often referenced as a starting point for this type of binding effort), which interfaces to an AIC34 codec?
The threads referenced are a few years old. Is it now possible to write such a driver at the machine level, or must I additionally either modify the core or write a new codec driver (as the original poster did)?
ALTERATIONS TO SUPPORT AN EXTERNAL SAMPLE-CLOCK GENERATOR
The sample clock is being generated by a single, I2C-configurable clock chip. So any sample-rate configuration must be sent to the clock chip. Can this be handled purely in the machine layer, or do I need to modify the AIC3X driver? I understand I need to use the regmap API to do such things, and ALSA uses this API, but I do not yet know much about it. Any pointers to documentation on doing this besides the source code are appreciated.
A key newbie question on regmap (and Linux I2C) as needed by the driver the following: Does the regmap-i2c or i2c driver "own" the I2C bus so that the each device on the bus can be read from/written to via the regmap-i2c or i2c driver without the device's driver having to request-take-release the bus on each access?
Thanks,
- Matt
participants (1)
-
Matt Kleffner