Mark Brown wrote:
On Wed, Mar 14, 2012 at 06:00:41PM -0500, Timur Tabi wrote:
Mark Brown wrote:
So using imx-audio-sgtl5000.txt as an example, you're saying that if I have two SSIs, I should do this in my device tree:
sound1 { };
sound2 { };
That's a totally sensible option if you've got two unrelated audio subsystems on your board for some reason. If you've got a system where that's not applicable and the two devices are related in some way then you'd define a new sound card binding that reflects that.
Well, the two SSIs are related only in that they're the same kind of device. But SSI1 connected to CS4270_1 is completely independent from SSI2 connected to CS4270_2.
So I guess that means that we'd have two soundX {} top-level nodes.
The SoC is the bit of silicon with the CPU and other devices on it like the DMA controller and SSI or whatever ports. The card is the PCB this has been soldered down onto.
Well, I asked about the difference between the soc BINDING and the card BINDING. On PowerPC, at least, there's no distinct binding for either. For example, I2C devices are on the PCB, but they're listed as child nodes of the I2C controller, which is on the SoC.
The problem with your binding has always been, and continues to be, that it's based on the idea that there's one CODEC per SSI and that the CODEC is a simple appendage of that SSI. There's no real real binding for the machine driver, it's just silently created by a single SSI port. Really there's nothing new with this issue, there's always been this absence of a representation for the machine distinct from the individual devices it is built up from.
This means that when you get systems which have auxiliary devices (like most of the Wolfson reference boards which have a power amplifier for the sub speaker not connected to an SSI port) or that need to set up things like complex accessory detection mechanisms there's no real place in your binding to support those systems. Things like the configuration of the input and output connections which the nVidia WM8903 drivers are able to do over multiple boards are another example.
Ok, fair enough. I understand that my binding has no way of specifying board-specific properties, or anything that isn't directly related to the SSI, codec, or DMA controller.
However, I don't like the way this is being represented as a PowerPC vs. ARM issue, because that's just not correct. It's an "old binding" vs "new binding" issue. For example:
+ /* + * In case of imx, the machine driver uses new binding which does + * not require SSI driver to trigger machine driver's probe, but + * the pcm device needs to be registered here. + */ + if (ssi_private->ssi_on_imx) { + ssi_private->imx_pcm_pdev = + platform_device_register_simple("imx-pcm-audio",
This prohibits me from using the new binding on any future PowerPC parts, because it clearly says "iMX" on everything.