A2B codec chain implementation

[Théo Lebrun]

Hi,

Automotive Audio Bus (A2B) is a bus that carries a clock, I2S/TDM, I2C,
GPIO and mailboxes over a two wire connection that carries power as
well. It has a leader-follower (master-slave in the spec) structure,
with no obligation to have all samples going from or to the leader.

Analog Devices sells transceivers, that can also decode PDM inputs.
Their configuration is register based, with ways of accessing follower
registers from the leader. Here is their technical reference:
https://www.analog.com/media/en/technical-documentation/user-guides/AD242x_TRM_Rev1.1.pdf

The goal is to implement support for those, when the host is connected
to the leader. The implementation would be done by registering a new
bus_type and device_type, with a device for each functionality (on each
bus node) provided by the bus. Two issues were faced though:

  - At runtime, when an PCM stream is started, not only do the CPU and
    codec need to be configured, but also the leader and follower need
    some dynamic configuration based on hw_params. We have something
    resembling a chain, and all 4 devices need to be configured
    I2S-wise:
    CPU <-I2S-> leader node <-A2B-> follower node <-I2S-> codec.
    That does not fit the standard form of a DAI link that only has a CPU
    and a codec. Is there a way to have a sound card that contains
    multiple codecs, all actived?

  - Clocks will have to be handled at the bus level and not at the
    soundcard level, as the master clock is needed at all times for the
    bus to be functional. Sadly it's probably not doable to use the
    clocks provided by the I2S/TDM CPU codec (which would be ideal as
    they are audio rate, which is what the bus expects), because they
    only get enabled when a PCM stream is active. On the hardware used
    for testing (SAMA7G54), we can't use an external (relative to the
    CPU codec) clock as master clock and use the peripheral to generate
    the bitclock, it doesn't support it; therefore both have to be
    handled at the bus level using board specific clocks.

So the first point is the main question: how could a codec chain be
modeled?

I was potentially thinking about a custom soundcard? That could surely
help? Would it be the right solution? Any pointers would help.

The clock aspect would have been an issue as a codec is either a clock
provider or consumer but for this particular use it is not as we'll use
the bus and not the soundcard to handle the clock management.

Thanks!

Théo

-- 
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com