[alsa-devel] [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device
Lee Jones
lee.jones at linaro.org
Thu Aug 23 15:26:19 CEST 2012
> > "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
More information about the Alsa-devel
mailing list