On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote: > I don't think all physical connectors require a DT binding per-se, but they > need to be represented in DT as they're part of the hardware. We could push > connector-related information to the nodes of all chips that have interfaces > wired directly to connectors, but that would result in more complex DT > bindings and core. I believe modeling connectors using separate DT nodes is be > best, and would allow easier support for more complex connectors that carry > multiple streams/signals in parallel (video, audio, DDC, ...). There is some sanity to representing physical connectors in DT, but it's not for the reason you mention above. If you consider that it's possible on PCs to find out what connectors are on the motherboard and where they are located, this is very useful information to be stored and presented. However, the idea that you combine streams at connectors is not a universal truth, and is certainly false for HDMI. HDMI combines video and audio at the encoder stage, not at the connector stage, and many HDMI encoders will provide everything required for driving the connector. However, my major objection here is not really that: my major objection is using something as generic as "hdmi-connector" as a compatible string. The reason is that we have to remember that DT is not just "a Linux thing". It's /supposed/ to be an OS independent representation of the hardware. If we invent something generic called a "hdmi-connector" then we had better first do a thorough search to make sure we're not trampling on anything which is standardized or becoming a standard - if there is, we should work with them - and if that's not possible, then we need to distingush ourselves from them. What we can't do is go around inventing generic stuff without having our eyes wide open. So, here's a good question to probe how far this has been thought through already: what has been done to discuss the creation of this generic "hdmi-connector" thing with the various parties who are interested in HDMI outputs under DRM using device tree? If that hasn't happened, that's quite a failing - it means that we're on the road to having two _implementation specific_ DT representations for the same hardware - one for fbdev and one for DRM. That really isn't on. Yes, it then opens a pandora's box of problems about how we determine whether DRM or fbdev should bind to the DT nodes, but that should be an entirely separate issue (and, ideally of course, both should use the same sub-drivers for the components.) -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
