[alsa-devel] ASoC: Failed to create component debugfs directory
Hi,
On linux-next I see the following errors on imx6 wandboard:
[ 3.040897] fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs directory [ 3.065722] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory
I haven't started debugging this yet and not sure if this is something fsl driver specific.
Any ideas?
Thanks
On Mon, Feb 19, 2018 at 03:49:11PM -0300, Fabio Estevam wrote:
Hi,
On linux-next I see the following errors on imx6 wandboard:
[ 3.040897] fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs directory [ 3.065722] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory
I haven't started debugging this yet and not sure if this is something fsl driver specific.
I think it's because we recently changed all CPU dai drivers to component drivers, so our drivers should probably add something to create debugfs directories I guess...will take a look at it.
On Mon, Feb 19, 2018 at 12:14:41PM -0800, Nicolin Chen wrote:
On Mon, Feb 19, 2018 at 03:49:11PM -0300, Fabio Estevam wrote:
[ 3.065722] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory
I haven't started debugging this yet and not sure if this is something fsl driver specific.
I think it's because we recently changed all CPU dai drivers to component drivers, so our drivers should probably add something to create debugfs directories I guess...will take a look at it.
Hrm, that's not the goal - if every driver has to do it there's something wrong.
On Mon, Feb 19, 2018 at 3:49 PM, Fabio Estevam festevam@gmail.com wrote:
Hi,
On linux-next I see the following errors on imx6 wandboard:
[ 3.040897] fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs directory [ 3.065722] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory
I haven't started debugging this yet and not sure if this is something fsl driver specific.
This is not fsl sound specific as I see the same warnings in kernelci.org boot logs with other SoCs.
The failures happens because we are trying to create debugfs twice:
[ 2.122894] mmc1: new SDIO card at address 0001 [ 2.150560] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered [ 2.160601] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW [ 2.326140] [drm] Cannot find any crtc or sizes [ 2.538048] ******** component name is 2028000.ssi [ 2.542911] fsl-ssi-dai 2028000.ssi: ASoC: Succeeded in creating component debugfs directory [ 2.551513] ******** component name is sgtl5000.1-000a [ 2.556761] sgtl5000 1-000a: ASoC: Succeeded in creating component debugfs directory [ 2.580521] ******** component name is 2028000.ssi [ 2.585552] fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs directory [ 2.601344] imx-sgtl5000 sound: sgtl5000 <-> 2028000.ssi mapping ok [ 2.620625] ******** component name is 2004000.spdif [ 2.625867] fsl-spdif-dai 2004000.spdif: ASoC: Succeeded in creating component debugfs directory [ 2.634754] ******** component name is 2004000.spdif [ 2.639850] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory [ 2.652127] imx-spdif sound-spdif: snd-soc-dummy-dai <-> 2004000.spdif mapping ok
Any ideas why this second debugfs registration is being attempted?
On 02/20/2018 03:18 PM, Fabio Estevam wrote:
On Mon, Feb 19, 2018 at 3:49 PM, Fabio Estevam festevam@gmail.com wrote:
Hi,
On linux-next I see the following errors on imx6 wandboard:
[ 3.040897] fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs directory [ 3.065722] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory
I haven't started debugging this yet and not sure if this is something fsl driver specific.
This is not fsl sound specific as I see the same warnings in kernelci.org boot logs with other SoCs.
The failures happens because we are trying to create debugfs twice:
[ 2.122894] mmc1: new SDIO card at address 0001 [ 2.150560] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered [ 2.160601] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW [ 2.326140] [drm] Cannot find any crtc or sizes [ 2.538048] ******** component name is 2028000.ssi [ 2.542911] fsl-ssi-dai 2028000.ssi: ASoC: Succeeded in creating component debugfs directory [ 2.551513] ******** component name is sgtl5000.1-000a [ 2.556761] sgtl5000 1-000a: ASoC: Succeeded in creating component debugfs directory [ 2.580521] ******** component name is 2028000.ssi [ 2.585552] fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs directory [ 2.601344] imx-sgtl5000 sound: sgtl5000 <-> 2028000.ssi mapping ok [ 2.620625] ******** component name is 2004000.spdif [ 2.625867] fsl-spdif-dai 2004000.spdif: ASoC: Succeeded in creating component debugfs directory [ 2.634754] ******** component name is 2004000.spdif [ 2.639850] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory [ 2.652127] imx-spdif sound-spdif: snd-soc-dummy-dai <-> 2004000.spdif mapping ok
Any ideas why this second debugfs registration is being attempted?
One for the DMA, one for the I2S?
On Tue, Feb 20, 2018 at 11:24 AM, Lars-Peter Clausen lars@metafoo.de wrote:
Any ideas why this second debugfs registration is being attempted?
One for the DMA, one for the I2S?
but this second debugfs registration only happens in linux-next.
On master it tries to only register once and it succeeds.
On linux-next it succeeds the first time and it fails the second time as it tries to register the same debugfs entry.
On 02/20/2018 08:26 PM, Fabio Estevam wrote:
On Tue, Feb 20, 2018 at 11:24 AM, Lars-Peter Clausen lars@metafoo.de wrote:
Any ideas why this second debugfs registration is being attempted?
One for the DMA, one for the I2S?
but this second debugfs registration only happens in linux-next.
On master it tries to only register once and it succeeds.
On linux-next it succeeds the first time and it fails the second time as it tries to register the same debugfs entry.
Because on linux-next they are all components now, before one was a platform, the other a component. So they were created in different sub-directories. Now they are created in the same sub-directory.
On Tue, Feb 20, 2018 at 4:30 PM, Lars-Peter Clausen lars@metafoo.de wrote:
Because on linux-next they are all components now, before one was a platform, the other a component. So they were created in different sub-directories. Now they are created in the same sub-directory.
Thanks for your clarification.
What is the best way to avoid the "Failed to create component debugfs directory" warning?
--- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -319,8 +319,6 @@ static void soc_init_component_debugfs(struct snd_soc_component *component) }
if (!component->debugfs_root) { - dev_warn(component->dev, - "ASoC: Failed to create component debugfs directory\n"); return; }
or
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 3987673..270109c 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -329,6 +329,8 @@ static void soc_init_component_debugfs(struct snd_soc_component *component)
if (component->init_debugfs) component->init_debugfs(component); + + component->card->debugfs_card_root = NULL; }
static void soc_cleanup_component_debugfs(struct snd_soc_component *component)
Thanks
On Tue, Feb 20, 2018 at 04:37:33PM -0300, Fabio Estevam wrote:
Thanks for your clarification.
What is the best way to avoid the "Failed to create component debugfs directory" warning?
It's a legit warning - we shouldn't really be creating two components for the same device. However this is a bit of a corner case as it's the dmaengine platform driver which is kind of a virtual device, it's not really the device that we use with DMA that's being represented but rather the link between that and the DMA controller.
Does the below patch (completely untested) help here? It adds a prefix to the name for deduplication.
diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index d53786498b61..d5a6eea64036 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -431,6 +431,7 @@ int snd_dmaengine_pcm_register(struct device *dev, if (!pcm) return -ENOMEM;
+ pcm->platform.component.name_prefix = "dma"; pcm->config = config; pcm->flags = flags;
Hi Mark,
On Wed, Feb 21, 2018 at 10:02 AM, Mark Brown broonie@kernel.org wrote:
It's a legit warning - we shouldn't really be creating two components for the same device. However this is a bit of a corner case as it's the dmaengine platform driver which is kind of a virtual device, it's not really the device that we use with DMA that's being represented but rather the link between that and the DMA controller.
Does the below patch (completely untested) help here? It adds a prefix to the name for deduplication.
diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index d53786498b61..d5a6eea64036 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -431,6 +431,7 @@ int snd_dmaengine_pcm_register(struct device *dev, if (!pcm) return -ENOMEM;
pcm->platform.component.name_prefix = "dma";
Had to change it to pcm->component.name_prefix = "dma"; but still see the warnings.
Here are the suggested change plus some additional debug lines:
--- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -303,6 +303,8 @@ static void soc_init_component_debugfs(struct snd_soc_component *component) if (!component->card->debugfs_card_root) return;
+ pr_err("************** component name is %s\n", component->name); + if (component->debugfs_prefix) { char *name;
@@ -318,6 +320,12 @@ static void soc_init_component_debugfs(struct snd_soc_component *component) component->card->debugfs_card_root); }
+ if (component->debugfs_root) { + dev_warn(component->dev, + "ASoC: Succeded to create component debugfs directory\n"); + return; + } + if (!component->debugfs_root) { dev_warn(component->dev, "ASoC: Failed to create component debugfs directory\n"); diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index c07d5c7..16995dd 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -442,6 +442,7 @@ int snd_dmaengine_pcm_register(struct device *dev, if (!pcm) return -ENOMEM;
+ pcm->component.name_prefix = "dma"; pcm->config = config; pcm->flags = flags;
and the log looks like this:
[ 2.062294] sgtl5000 1-000a: sgtl5000 revision 0x11 [ 2.069367] sgtl5000 1-000a: Using internal LDO instead of VDDD: check ER1 erratum [ 2.113827] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered [ 2.123954] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW [ 2.326451] [drm] Cannot find any crtc or sizes [ 2.501744] ************** component name is 2028000.ssi [ 2.507217] fsl-ssi-dai 2028000.ssi: ASoC: Succeded to create component debugfs directory [ 2.515429] ************** component name is sgtl5000.1-000a [ 2.521194] sgtl5000 1-000a: ASoC: Succeded to create component debugfs directory [ 2.544264] ************** component name is 2028000.ssi [ 2.549879] fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs directory [ 2.565605] imx-sgtl5000 sound: sgtl5000 <-> 2028000.ssi mapping ok [ 2.584074] ************** component name is 2004000.spdif [ 2.589721] fsl-spdif-dai 2004000.spdif: ASoC: Succeded to create component debugfs directory [ 2.598437] ************** component name is 2004000.spdif [ 2.603978] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory [ 2.616340] imx-spdif sound-spdif: snd-soc-dummy-dai <-> 2004000.spdif mapping ok
Looks like the 'dma' prefix did not take effect, as we are still trying to register the same name twice.
Thanks
On Wed, Feb 21, 2018 at 10:43 AM, Fabio Estevam festevam@gmail.com wrote:
Had to change it to pcm->component.name_prefix = "dma"; but still see the warnings.
Looks like this can fix it:
--- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -442,6 +442,7 @@ int snd_dmaengine_pcm_register(struct device *dev, if (!pcm) return -ENOMEM;
+ pcm->component.debugfs_prefix = "dma"; pcm->config = config; pcm->flags = flags;
Would you like me to submit it?
Thanks
On Wed, Feb 21, 2018 at 10:47:45AM -0300, Fabio Estevam wrote:
Looks like this can fix it:
--- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -442,6 +442,7 @@ int snd_dmaengine_pcm_register(struct device *dev, if (!pcm) return -ENOMEM;
pcm->component.debugfs_prefix = "dma"; pcm->config = config; pcm->flags = flags;
Would you like me to submit it?
Yes, please.
On Tue, Feb 20, 2018 at 11:18 AM, Fabio Estevam festevam@gmail.com wrote:
Any ideas why this second debugfs registration is being attempted?
The change below avoids the double component debugfs registration:
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 3987673..270109c 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -329,6 +329,8 @@ static void soc_init_component_debugfs(struct snd_soc_component *component)
if (component->init_debugfs) component->init_debugfs(component); + + component->card->debugfs_card_root = NULL; }
static void soc_cleanup_component_debugfs(struct snd_soc_component *component)
Not sure what a proper fix would be.
On 19/02/18 18:49, Fabio Estevam wrote:
Hi,
On linux-next I see the following errors on imx6 wandboard:
[ 3.040897] fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs directory [ 3.065722] fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs directory
I haven't started debugging this yet and not sure if this is something fsl driver specific.
Any ideas?
I hit something similar while testing some of the qcom sound card.
This patch fixed the issue for me:
https://git.linaro.org/people/srinivas.kandagatla/linux.git/commit/?h=v4.16-...
Its basically to do with nested device tree nodes, the device name seems to exceed the NAME_SIZE of 32 bytes.
thanks, srini
Thanks _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi Srinivas,
On Tue, Feb 20, 2018 at 3:37 PM, Srinivas Kandagatla srinivas.kandagatla@linaro.org wrote:
I hit something similar while testing some of the qcom sound card.
This patch fixed the issue for me:
https://git.linaro.org/people/srinivas.kandagatla/linux.git/commit/?h=v4.16-...
Its basically to do with nested device tree nodes, the device name seems to exceed the NAME_SIZE of 32 bytes.
Thanks for the suggestion, but this does not solve the issue on my case.
participants (5)
-
Fabio Estevam
-
Lars-Peter Clausen
-
Mark Brown
-
Nicolin Chen
-
Srinivas Kandagatla