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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022-02-25 3:35 AM, Pierre-Louis Bossart wrote:

Note: this series does not add fully functional driver as its size would
get out of control. Here, focus is put on adding IPC protocol and code
loading code.

This series is much simpler indeed, see comments in patches, but that
leaves the next steps completely open. It's not quite clear to me how
the previous feedback on trying to up-level the DSP management
functionality might be handled, and if/when you are planning to submit
follow-up patchsets that would implement the required functionality to
at least match what the Skylake driver can do today.

To repeat my previous points: the existing DPCM FE/BE split does not
even being to represent how a DSP might be handled. The BE typically
represents a physical DAI connected to a codec, and the FE pretty much
everything else between a host DMA and the DAI. All the internal format
conversions, mixers and processing are not really represented other than
with DAPM logical widgets, and that's a big miss. There's room for a lot
of improvements that would be of interest to all DSP users.


Thanks for taking time to provide round of review for the series!

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


Regards,
Czarek


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



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux