Hello,
This is the v2 of the series of patch aiming to make the machine driver fsl-asoc-card compatible with use cases where there is no real codec driver. It proposes to use the spdif_receiver and spdif_transmitter drivers instead of the dummy codec. This is a first step in using the S/PDIF controller with the ASRC.
The five first patches add compatibility with the pair of codecs spdif_receiver and spdif_transmitter with a new compatible, "fsl,imx-audio-generic". Codec parameters are set with default values.
The remaining patches add configuration options for the device tree. They configure the CPU DAI when using "fsl,imx-audio-generic". These are usually hard-coded in fsl-asoc-card for each audio codec. Because the generic codec could be used with other CPU DAI than the S/PDIF controller, setting these parameters could be required.
This series of patch was successfully built for arm64 and x86 on top of the latest for-next branch of the ASoC git tree on the 24/10. These modifications have also been tested on an i.MX8MN evaluation board, with a linux kernel RT v6.1.26-rt8.
We also have a few questions :
* We named the compatible "fsl,imx-audio-generic" as, for the moment, it could work with any CPU DAI, even if it uses S/PDIF codecs. Is it preferable to keep these modifications specific to the S/PDIF, thus specifying "spdif" in the compatible ? Or is it okay to keep the actual name of the compatible, and the generic purpose of this compatible ?
* Part of the dai_fmt variable hold information on the codec provider or consumer status for bit/frame clocks. In patch 03/10, as we add compatibility for multiple codecs, we make the test about bit/frame clock provider only check with codec[0]. That way we assure compatibility with all already existing compatibles. As it was never intended before to have multiple codecs for this test, is there a better way to handle it ? Should we make this test check if any codec is clock provider ? Or should we let codec[0] be the default possibility ? That way, future compatibles that could encounter this specific case with multi-codecs should adapt the test for their needs.
Best regards, Elinor Montmasson
Changelog: v1 -> v2: * replace use of the dummy codec by the pair of codecs spdif_receiver / spdif_transmitter * adapt how dai links codecs are used to take into account the possibility for multiple codecs per link * change compatible name * adapt driver to be able to register two codecs given in the device tree * v1 patch series at: https://lore.kernel.org/alsa-devel/20230901144550.520072-1-elinor.montmasson...
Elinor Montmasson (10): ASoC: fsl-asoc-card: add support for dai links with multiple codecs ASoC: fsl-asoc-card: add second dai link component for codecs ASoC: fsl-asoc-card: add compatibility to use 2 codecs from device tree ASoC: fsl-asoc-card: add new compatible for a generic codec use case ASoC: fsl-asoc-card: set generic codec as clock provider ASoC: fsl-asoc-card: add dts property "cpu-slot-width" ASoC: fsl-asoc-card: add dts property "cpu-slot-num" ASoC: fsl-asoc-card: add dts properties "cpu-sysclk-freq" ASoC: fsl-asoc-card: add dts properties "cpu-sysclk-dir-out" Documentation: fsl-asoc-card: add documentation for generic codec case
.../bindings/sound/fsl-asoc-card.txt | 26 +++- sound/soc/fsl/fsl-asoc-card.c | 128 ++++++++++++------ 2 files changed, 114 insertions(+), 40 deletions(-)