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
