[PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device

[lee.jones@linaro.org (Lee Jones)]

> > "I'm sorry but this patch is breaking the design of ASoC. The ASoC-
> > platform is the DMA-block (in combination with the MSP-block), and
> > there should be a platform-driver for the DMA/PCM. The platform-driver 
> > then has a DAI which is the MSP. The ASoC DAI-link-struct should have
> > one driver for each of these, so the dummy-driver for PCM should be
> > there."
> 
> > So I don't really know where to go with it. Any ideas?
> 
> I think Ola is suggesting probing the DMA driver from the machine which
> will also work though I'm not 100% sure if I'm parsing the above
> correctly.  The issue in DT terms is that if the DMA controller is
> shared with a bunch of other IPs then it should have one node shared
> between them all and not a bunch of shim nodes inserted in the middle
> which only exists due to the way Linux instantiates stuff.

When you say 'machine', do you mean from arch/<arch>/mach-*? If so, I'm
keen for that not to happen.

> > How do the all the other DT:ed audio drivers handle the PCM then? More
> > importantly, how would you like to see it handled? Ola has NACKed this
> > patch and explained why:
> 
> They instantiate the PCM driver dynamically from the DAI when it's
> probed which is pretty much what you're patch is doing.

So they do it in the same why I have with this patch? Do you know why
Ola might think this is a bad idea?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog