A2B codec chain implementation

[Lars-Peter Clausen]

On 10/14/22 18:05, Théo Lebrun wrote:
> 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.
>
Hi,

Daniel, me and a few others have been working on A2B driver support. We 
are in the process of getting it ready for upstreaming. Currently public 
code is in 
https://github.com/analogdevicesinc/linux/commits/a2bupstream. ADI 
squashed the commit history. We need to restore that.

At the moment the remote devices are modeled as a codec2codec link with 
fixed rates. Its not ideal, but the best we can do in the current ALSA 
framework.

I did propose some changes that will allow dynamic hwparams domain and 
propagation through those domains a long long time ago. But that never 
got to the stage where I was able to work on the implementation. See 
http://metafoo.de/the_new_asoc.svg

- Lars