| Message ID | 20220207122108.3780926-1-cezary.rojewski@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: Intel: AVS - Audio DSP for cAVS | expand |
On 2022-02-07 1:20 PM, Cezary Rojewski wrote: > A continuation of cleanup work of Intel SST solutions found in > sound/soc/intel/. With two major chapters released last year catpt [1] > and removal of haswell solution [2], time has come for Skylake-driver. > > Througout 2019, 2020 and 2021 Skylake-driver has had many fixes applied > and even attempts of refactors as seen in fundamental overhaul [3], IPC > flow adjustments [4] and LARGE_CONFIG overhaul [5] series. > Unfortunately, story repeats itself - problems are found within the core > of a driver. Painting it with different colors does not change the fact > that is it still a house of cards. As changes needed to address those > issues would make Skylake solution incompatible with its previous > revisions, a decision has been made to provide a new solution instead. > In time it would deprecate and replace Skylake-driver. > > That solution has been called AVS - from AudioDSP architecture name: > Audio-Voice-Speech. It is meant to provide support for the exact same > range of platforms as its predecessor: SKL, KBL, AML and APL. > > Note: this series is dependent upon HDA-series [6] which exposes several > codec-organization functions allowing for reduced code size on > avs-driver side. Hello, Despite HDA-series being updated to v2 [1], no changes are required on the side of this series. Mark, Should I resend this one regardless of the above? Also, is there anything else I can help with or explain further regarding code-loading and IPC protocol which this series implements? Regards, Czarek [1]: https://lore.kernel.org/alsa-devel/20220214101404.4074026-1-cezary.rojewski@intel.com/T/#t > 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. ... > [1]: https://www.spinics.net/lists/alsa-devel/msg116440.html > [2]: https://www.spinics.net/lists/alsa-devel/msg116901.html > [3]: https://www.spinics.net/lists/alsa-devel/msg94199.html > [4]: https://www.spinics.net/lists/alsa-devel/msg92588.html > [5]: https://lore.kernel.org/all/20190808181549.12521-1-cezary.rojewski@intel.com/ > [6]: https://lore.kernel.org/alsa-devel/20220207114906.3759800-1-cezary.rojewski@intel.com/T/#t > [7]: https://lore.kernel.org/all/20211208111301.1817725-1-cezary.rojewski@intel.com/
> 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.
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@intel.com/T/#t
> 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
On Thu, Feb 24, 2022 at 08:35:50PM -0600, Pierre-Louis Bossart wrote: > 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. I think it's fine that none of the complicated stuff is considered here, one of the objectives with splitting things up into multiple serieses is to ensure that the simpler stuff doesn't obscure the bits that need more attention paying to them.