On Wed, Mar 14, 2012 at 02:57:00AM +0000, Tabi Timur-B04825 wrote:
Mark Brown wrote:
With this card those would just be separate CODECs. This is a binding for a simple card.
But that is insufficient for the SSI driver, which is expected to handle multiple SSIs. If you're going to document a binding for the SSI driver, then you need to document how to handle multiple SSIs.
For almost all SoC audio ports this works in exactly the same way it works for multiple instances of any other device - you do a binding that covers a single device and then you bind multiple instances of that device in the system each of which need know nothing about any other instances of the IP.
If your SoC has IP which provides more than one port in a single IP block then the driver for that IP would need to register multiple DAIs from a single binding which is again exactly the same thing as you'd do with any other IP block that behaved similarly.
All of which is exactly the same as for any other device and essentially irrelevant to how we define the bindings for the cards.
The biggest improvement is that the SoC binding knows nothing about the card binding at all, cards are completely separate and are free to define any binding they choose using any number of on-SoC and off-SoC devices.
Ok, I don't understand that at all.
Do you have some questions about the above? What is it that you find unclear?
I also don't understand why you insist on perverting my driver to support two incompatible bindings, especially since I still haven't heard an explanation as to what's wrong with the binding that I defined.
We've been through this *repeatedly*, including in the message you're replying to, and we're still going back to square one every time you decide to start talking about device tree again. This is frustrating in the extreme.