On Thu, Aug 23, 2012 at 01:20:03PM +0100, Lee Jones wrote:
> > I say I don't understand the motivation for this change.  All the modern
> > DT bindings are perfectly happy handling this without an explicit shim
> > in the device tree to bodge things for Linux, adding them in seems like
> > it'd be a retrograde step.  What benefit do you believe this brings?

> 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.

> "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.