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.