[PATCH 00/17] ASoC: Intel: AVS - Audio DSP for cAVS

[Pierre-Louis Bossart]

> The request was to split the initial series into smaller chunks and
> separate the driver-specific stuff from parts that _could_ get
> incorporated into the framework to level it up in regard to DSP
> management. Series: "Intel: avs: Topology and path management" [1] has
> been provided for such discussion.
> 
> Given the request, we are planning to upstream avs-driver in four chunks:
> - IPC protocol and code loading (this one)
> - Topology and path management [1]
> - secondary flows e.g.: DSP recovery
> - machine boards
> 
> 
> In regard to DPCM FE/BE, ASoC already has DAI-link components: let codec
> operations stay with codec component, leaving DSP related operations as
> platform component responsibility. FE for DSP drivers typically comes
> from topology and drives the HOST DMA part whereas BE deals with LINK
> (hardware, data transfer interface such as PDM or I2S) side, including
> its configuration.

I respectfully disagree with your analysis, we cannot dissociate DSP and
link management. The intersection between the BE dailink handling and
the DSP management is the configuration of the cpu-dai on the host side.

When the DSP firmware programs the DAI registers, as we do on the Intel
side for SSP, DMIC and ALH/SoundWire, then the format information needs
to be exposed back to the DSP platform driver so that the codec can be
informed of the configuration. Most interfaces can support multiple
formats, and currently we don't have a good way to know what the
firmware changes and how to match PCM hw_params with link configuration.

The current work-around we use is to rely on the dailink fixup to force
the dailink to operate at a rate consistent with the topology, but
that's really not good at all. What would be needed is that all format
changes through the DSP graph are propagated all the way to the DAI and
used for the dailink configuration. That would also enable us to remove
unnecessary SRCs or format conversions, which I believe is a capability
at the heart of your AVS path proposal.

That's really my point, you cannot really think of DSP management
without factoring in DPCM.

It's not just me blabbering into the wind btw, others have voiced the
need to improve FE->BE format handling and add constraints, see

https://lore.kernel.org/alsa-devel/20210323114327.3969072-1-codrin.ciubotariu@microchip.com/

> I'm happy to continue the discussion regarding "path" in the dedicated
> series [1] as current series covers IPC protocol and code loading -only.

this RFC series was not mentioned in the cover letter for this patchset,
so it wouldn't be surprising if others also missed the connection.

> [1]:
> https://lore.kernel.org/alsa-devel/20220207132532.3782412-1-cezary.rojewski@intel.com/T/#t