simple-audio-card vs. platform question

simple-audio-card vs. platform question

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: simple-audio-card vs. platform question

[Lars-Peter Clausen]

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

Re: simple-audio-card vs. platform question

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: simple-audio-card vs. platform question

[Lars-Peter Clausen]

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

Re: simple-audio-card vs. platform question

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: simple-audio-card vs. platform question

[Lars-Peter Clausen]

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

Re: simple-audio-card vs. platform question

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30