[alsa-devel] Creating single-card driver for multi-codec (TLV320AIC34) board - is it possible at the machine level?

[Matt Kleffner]

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/2361.tlv320aic34-tdm-mode-driver-questions-vocera.aspx

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