[PATCH v1] ARM: imx_v6_v7_defconfig: enable SND_SOC_SPDIF

[Stefan Eichenberger]

Hi Stefan,

On Sat, Nov 02, 2024 at 04:35:19PM +0100, Stefan Wahren wrote:
> Hi Stefan,
> 
> Am 02.11.24 um 15:36 schrieb Stefan Eichenberger:
> > Hi Shawn,
> > 
> > On Sat, Nov 02, 2024 at 03:21:58PM +0800, Shawn Guo wrote:
> > > On Wed, Oct 30, 2024 at 01:21:12PM +0100, Stefan Eichenberger wrote:
> > > > From: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> > > > 
> > > > Enable SND_SOC_SPDIF in imx_v6_v7_defconfig to support SPDIF audio. This
> > > > change will fix commit d469b771afe1 ("ARM: dts: imx6: update spdif sound
> > > > card node properties") which moves away from the old "spdif-controller"
> > > > property to the new "audio-codec" property.
> > > > 
> > > > Fixes: d469b771afe1 ("ARM: dts: imx6: update spdif sound card node properties")
> > > It doesn't look a fix to me.
> > I agree somehow, it was just that before the referenced commit our test
> > succeeds with the imx_v6_v7_defconfig and after that we get the
> > following error:
> > [   24.165534] platform sound-spdif: deferred probe pending: fsl-asoc-card: snd_soc_register_card failed
> this error should have been in the commit message including the
> information which platform/board is affected.

Okay, I will add this information to the next version. We see this error
on an Apalis iMX6 which has in my variant an NXP i.MX6Q SoC.

> > So maybe it is not a fix in the sense of a bug, but it fixes the error
> > message. However, I'm also fine with removing the Fixes tag.
> But this patch doesn't look like the real approach.
> 
> Could you please clarify the impact of the regression?

So the problem is that before commit d469b771afe1 ("ARM: dts: imx6:
update spdif sound card node properties") the audio driver was
using an implementation of linux,spdif-dit and linux,spdif-dir which was
directly inside the fsl,imx-audio-spdif compatible driver. Now with the
referenced commit the idea is to use the more generic linux,spdif-dir
and linux,spdif-dit compatible drivers. That's why this driver must be
enabled in the kernel configuration.

> Is it just this error message and audio works fine or is audio also broken?

It is not just the error message, audio is not working because the
driver deferes and because it is not enabled it will never succeed to
load. I don't know if this is called a regression, because the driver is
there it is just not enabled in the imx6_v7_defconfig. I thought because
a lot of the i.MX6 based board use the generic driver, it makes sense to
enable it in the imx_v6_v7_defconfig.

Here the output of git stat to show which boards are most likely showing
the same behavior as the Apalis iMX6 with the current
imx_v6_v7_defconfig:
git show d469b771afe1 --stat
....
 arch/arm/boot/dts/nxp/imx/imx6q-cm-fx6.dts          | 15 ++++++++++++---
 arch/arm/boot/dts/nxp/imx/imx6q-prti6q.dts          | 15 ++++++++++++---
 arch/arm/boot/dts/nxp/imx/imx6q-tbs2910.dts         |  9 +++++++--
 arch/arm/boot/dts/nxp/imx/imx6qdl-apalis.dtsi       | 15 ++++++++++++---
 arch/arm/boot/dts/nxp/imx/imx6qdl-apf6dev.dtsi      |  9 +++++++--
 arch/arm/boot/dts/nxp/imx/imx6qdl-colibri.dtsi      | 15 ++++++++++++---
 arch/arm/boot/dts/nxp/imx/imx6qdl-cubox-i.dtsi      |  9 +++++++--
 arch/arm/boot/dts/nxp/imx/imx6qdl-hummingboard.dtsi |  9 +++++++--
 arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi    |  9 +++++++--
 arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi    |  9 +++++++--
 arch/arm/boot/dts/nxp/imx/imx6sx-sabreauto.dts      |  9 +++++++--
 arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi           |  9 +++++++--

Regards,
Stefan