On Mon, Aug 05, 2013 at 08:14:47PM +0200, Sebastian Hesselbarth wrote:
On 08/05/2013 06:59 PM, Mark Brown wrote:
The clocking arrangements are an example of why the boards can get interesting enough to describe for themselves.
I understand there are complex arrangements, I still don't think that you need a global super-node to describe them. Anyway, I am not voting against a super-node.
Please look back through the list archives, we've been round this loop repeatedly.
Also, all those "nvidia," properties would have fit very well into the i2s controller node
No, almost none of them have any place there. For example, the audio routing contains only connections to the CODEC so the I2S controller isn't in play, the headphone detection is connected to the AP but isn't connected to the I2S port.
From a quick look in tegra30_hub.h, I can see configuration registers i2s formatting. I assume that i2s controller on Tegra can therefore directly connected to a I2S codec, can't it? Then, with an existing i2s node and an existing codec node - why is there no place to link both?
At a minimum we'd need to figure out which end of the link to put it on and what to do about multi-drop links or links which share some or all of the clocks but have split data lines.
I can think of use cases that are hard to describe in a link-to-link way, but none of them really requires a super-node nor special board-specific compatible strings. With that we can just have the root DT node be compatible with Beaver above and register all the old platform_device way.
It's just plain good practice to have some way to figure out which board we're running on.
[...]
I learned to never match "device nodes" with "drivers" as there is simply no relation between them.
That's clearly a thinko for device node.
I assume with "thinko" you mean "thought wrong" - IMHO the above statement is very true. If it wouldn't, why not just have a node for kirkwood-dma and kirkwood-i2s instead of merging the drivers? You think that will also be accepted by DT maintainers?
We don't have a node for the DMA driver because it's just a software wrapper for the DMA controller. We do have a node for the board because it's an actual physical thing that we can point at, the board driver is representing the audio subsystem schematic.
From my point of view I'd rather not be shoving vendor prefixes on all the properties, this is coming from DT convention requiring vendor prefixes on bindings.
I understand that those vendor prefixes are part of the helper functions of ASoC. But no other subsystem has a similar approach but
No? I can't parse what you're saying here at all.
though of properties generic enough to help drivers find what they need to know. Either ASoC is mis-interpreting the vendor-prefix requirement - or all other subsystems are.
This isn't me, this is people like Stephen (who's one of the DT guys...).