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.ciubotari...
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.