[alsa-devel] simple-audio-card vs. platform question
I'm trying to set up a simple device tree framework so I can do some development on an I2S driver. I'm trying to use simple-audio-card, but I keep running into the problem that once soc_bind_dai_link() gets called, dai_link->platform is set to NULL (because it is not initialized by simple-card.c when there is a DT node), while dai_link->platform_of_node has been set to dai_link->cpu_of_node in asoc_simple_card_parse_of().
This results in the following code in soc-core:soc_bind_dai_link() to set platform to NULL,
/* if there's no platform we match on the empty platform */ platform_name = dai_link->platform_name; if (!platform_name && !dai_link->platform_of_node) platform_name = "snd-soc-dummy";
/* find one from the set of registered platforms */ list_for_each_entry(platform, &platform_list, list) { if (dai_link->platform_of_node) { if (platform->dev->of_node != dai_link->platform_of_node) continue; } else { if (strcmp(platform->component.name, platform_name)) continue; }
rtd->platform = platform; } if (!rtd->platform) { dev_err(card->dev, "ASoC: platform %s not registered\n", dai_link->platform_name); return -EPROBE_DEFER; }
with -EPROBE_DEFER as a result.
I can't figure out either how to set up a platform (=DMA) driver in this environment. Perhaps the case of having a CPU DAI, DMA driver and codec DAI is not supported by simple-audio-card?
On other hand, the way it looks there is no way the resulting setup can get through soc_bind_dai_link() unless there is a platform and associated driver.
This indicates to me that I'm doing something seriously wrong in my setup, but having looked at various DT configurations in arch/arm/boot/dts in this case, as well as the documentation in Documentation/devicetree/bindings/sound/simple-card.txt I can't figure how to set it up any other way.
/Ricard
On 01/27/2015 01:01 PM, Ricard Wanderlof wrote:
I'm trying to set up a simple device tree framework so I can do some development on an I2S driver. I'm trying to use simple-audio-card, but I keep running into the problem that once soc_bind_dai_link() gets called, dai_link->platform is set to NULL (because it is not initialized by simple-card.c when there is a DT node), while dai_link->platform_of_node has been set to dai_link->cpu_of_node in asoc_simple_card_parse_of().
[...]
I can't figure out either how to set up a platform (=DMA) driver in this environment. Perhaps the case of having a CPU DAI, DMA driver and codec DAI is not supported by simple-audio-card?
[...]
Usually in such a setup the CPU DAI driver also register the platform component. Which then as the same of_node as the CPU DAI and so the matching works. There are plenty of examples e.g. check the drivers using devm_snd_dmaengine_pcm_register().
- Lars
On Tue, 27 Jan 2015, Lars-Peter Clausen wrote:
On 01/27/2015 01:01 PM, Ricard Wanderlof wrote:
I'm trying to set up a simple device tree framework so I can do some development on an I2S driver. I'm trying to use simple-audio-card, but I keep running into the problem that once soc_bind_dai_link() gets called, dai_link->platform is set to NULL (because it is not initialized by simple-card.c when there is a DT node), while dai_link->platform_of_node has been set to dai_link->cpu_of_node in asoc_simple_card_parse_of().
[...]
I can't figure out either how to set up a platform (=DMA) driver in this environment. Perhaps the case of having a CPU DAI, DMA driver and codec DAI is not supported by simple-audio-card?
[...]
Usually in such a setup the CPU DAI driver also register the platform component. Which then as the same of_node as the CPU DAI and so the matching works. There are plenty of examples e.g. check the drivers using devm_snd_dmaengine_pcm_register().
Thanks for the hint, that helps me back on track!
Curious though, wouldn't it be more natural to bind it all together in the simple-audio-card DT entry, having a "simple-audio-card,platform" specification? Or is the idea that normally the CPU DAI driver is fairly tightly coupled to the PCM driver so it makes more sense to make that connection in the code?
/Ricard
On 01/27/2015 05:31 PM, Ricard Wanderlof wrote:
On Tue, 27 Jan 2015, Lars-Peter Clausen wrote:
On 01/27/2015 01:01 PM, Ricard Wanderlof wrote:
I'm trying to set up a simple device tree framework so I can do some development on an I2S driver. I'm trying to use simple-audio-card, but I keep running into the problem that once soc_bind_dai_link() gets called, dai_link->platform is set to NULL (because it is not initialized by simple-card.c when there is a DT node), while dai_link->platform_of_node has been set to dai_link->cpu_of_node in asoc_simple_card_parse_of().
[...]
I can't figure out either how to set up a platform (=DMA) driver in this environment. Perhaps the case of having a CPU DAI, DMA driver and codec DAI is not supported by simple-audio-card?
[...]
Usually in such a setup the CPU DAI driver also register the platform component. Which then as the same of_node as the CPU DAI and so the matching works. There are plenty of examples e.g. check the drivers using devm_snd_dmaengine_pcm_register().
Thanks for the hint, that helps me back on track!
Curious though, wouldn't it be more natural to bind it all together in the simple-audio-card DT entry, having a "simple-audio-card,platform" specification? Or is the idea that normally the CPU DAI driver is fairly tightly coupled to the PCM driver so it makes more sense to make that connection in the code?
Usually there is no representation of the platform object in the devicetree. E.g. typically this is a external shared DMA controller which is referenced by the dmas property in the CPU DAI node.
- Lars
On Tue, 27 Jan 2015, Lars-Peter Clausen wrote:
Usually in such a setup the CPU DAI driver also register the platform component. Which then as the same of_node as the CPU DAI and so the matching works. There are plenty of examples e.g. check the drivers using devm_snd_dmaengine_pcm_register().
Curious though, wouldn't it be more natural to bind it all together in the simple-audio-card DT entry, having a "simple-audio-card,platform" specification? Or is the idea that normally the CPU DAI driver is fairly tightly coupled to the PCM driver so it makes more sense to make that connection in the code?
Usually there is no representation of the platform object in the devicetree. E.g. typically this is a external shared DMA controller which is referenced by the dmas property in the CPU DAI node.
But perhaps there should be? As it is now, the I2S driver is bound in the code to the PCM driver using the devm_snd_dmaengine_pcm_register() call, which doesn't seem to fit in with the device tree philosphy of having the DT describe the hardware.
Taking davinci-mcasp.c as an example, there's a bulk of #if's which govern calling the correct PCM driver depending on the setup, which is a bit cumbersome.
Granted, having a platform description in the DT would not actually describe any specific hardware since as you said the DMA controller is normally described elsewhere, which would go against the DT philosophy.
I'm not necessarily saying it would be better with a platform description in the DT, all things considered, just trying to understand why it may not be.
BTW, I can't find any DT in the kernel where the DMA is referenced in the CPU DAI node, all the DT's I can find which use simple-audio-card at least just reference the i2s device, which in turn references the DMA. Makes sense to me, perhaps that is what you meant?
/Ricard
On 01/29/2015 09:58 AM, Ricard Wanderlof wrote:
On Tue, 27 Jan 2015, Lars-Peter Clausen wrote:
Usually in such a setup the CPU DAI driver also register the platform component. Which then as the same of_node as the CPU DAI and so the matching works. There are plenty of examples e.g. check the drivers using devm_snd_dmaengine_pcm_register().
Curious though, wouldn't it be more natural to bind it all together in the simple-audio-card DT entry, having a "simple-audio-card,platform" specification? Or is the idea that normally the CPU DAI driver is fairly tightly coupled to the PCM driver so it makes more sense to make that connection in the code?
Usually there is no representation of the platform object in the devicetree. E.g. typically this is a external shared DMA controller which is referenced by the dmas property in the CPU DAI node.
But perhaps there should be? As it is now, the I2S driver is bound in the code to the PCM driver using the devm_snd_dmaengine_pcm_register() call, which doesn't seem to fit in with the device tree philosphy of having the DT describe the hardware.
Taking davinci-mcasp.c as an example, there's a bulk of #if's which govern calling the correct PCM driver depending on the setup, which is a bit cumbersome.
Granted, having a platform description in the DT would not actually describe any specific hardware since as you said the DMA controller is normally described elsewhere, which would go against the DT philosophy.
I'm not necessarily saying it would be better with a platform description in the DT, all things considered, just trying to understand why it may not be.
If you can make a compelling case that it should be added and that it describes the hardware that you have accurately I shouldn't be a problem to add it.
But in my opinion and experience the model where you have platform, CPU DAI, CODEC DAI is antiquated and does not match the modern hardware very well. We've started to restructure the ASoC framework to better accommodate the requirements of modern systems. And I'm hoping that once this restructuring is complete there will be no need for snd_soc_platform anymore.
BTW, I can't find any DT in the kernel where the DMA is referenced in the CPU DAI node, all the DT's I can find which use simple-audio-card at least just reference the i2s device, which in turn references the DMA. Makes sense to me, perhaps that is what you meant?
Yes, that's what I meant.
- Lars
On Thu, 29 Jan 2015, Lars-Peter Clausen wrote:
Curious though, wouldn't it be more natural to bind it all together in the simple-audio-card DT entry, having a "simple-audio-card,platform" specification? Or is the idea that normally the CPU DAI driver is fairly tightly coupled to the PCM driver so it makes more sense to make that connection in the code?
...
I'm not necessarily saying it would be better with a platform description in the DT, all things considered, just trying to understand why it may not be.
If you can make a compelling case that it should be added and that it describes the hardware that you have accurately I shouldn't be a problem to add it.
But in my opinion and experience the model where you have platform, CPU DAI, CODEC DAI is antiquated and does not match the modern hardware very well. We've started to restructure the ASoC framework to better accommodate the requirements of modern systems. And I'm hoping that once this restructuring is complete there will be no need for snd_soc_platform anymore.
Well, your experience definitely greatly outweighes mine for sure. At this stage I'm mostly trying to get my head around why things are the way they are.
My experience so far has basically been with a single SoC. It does fit the platform - CPU DAI - CODEC DAI paradigm quite well though, as there is one PCM = platform driver to handle the DMA, an on-chip I2S DAI, and an off-chip codec. In what way do 'modern systems' differ?
One thing I could imagine is that if the DMA driver is implemented in the kernel DMA framework as a DMA engine, then a single generic platform driver will be able to handle multiple 'platforms' which would eventually make the concept obsolete. But I don't if that is the issue here.
/Ricard
participants (2)
-
Lars-Peter Clausen -
Ricard Wanderlof