On Fri, Sep 19, 2014 at 7:58 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On 19/09/14 16:59, Ajay kumar wrote: > >> I am not really able to understand, what's stopping us from using this >> bridge on a board with "complex" display connections. To use ps8622 driver, >> one needs to "attach" it to the DRM framework. For this, the DRM driver > > Remember that when we talk about DT bindings, there's no such thing as > DRM. We talk about hardware. The same bindings need to work on any > operating system. Agreed. >> would need the DT node for ps8622 bridge. For which I use a phandle. > > A complex one could be for example a case where you have two different > panels connected to ps8622, and you can switch between the two panels > with, say, a gpio. How do you present that with a simple phandle? > > In the exynos5420-peach-pit.dts, which you linked earlier, I see a > "panel" property in the ps8625 node. That's missing from the bindings in > this patch. Why is that? How is the panel linked in this version? Oops, my bad! Panel should also be present in the DT binding(for which, I am using a phandle for panel node) >> If some XYZ platform wishes to pick the DT node via a different method, >> they are always welcome to do it. Just because I am not specifying a >> video port/endpoint in the DT binding example, would it mean that platform >> cannot make use of ports in future? If that is the case, I can add something > > All the platforms share the same bindings for ps8622. If you now specify > that ps8622 bindings use a simple phandle, then anyone who uses ps8622 > should support that. > > Of course the bindings can be extended in the future. In that case the > drivers need to support both the old and the new bindings, which is > always a hassle. > > Generally speaking, I sense that we have different views of how display > devices and drivers are structured. You say "If some XYZ platform wishes > to pick the DT node via a different method, they are always welcome to > do it.". This sounds to me that you see the connections between display > devices as something handled by a platform specific driver. > I, on the other hand, see connections between display devices as common > properties. Well, I am okay with using video ports to describe the relationship between the encoder, bridge and the panel. But, its just that I need to make use of 2 functions when phandle does it using just one function ;) - panel_node = of_parse_phandle(dev->of_node, "panel", 0) + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); + if (!endpoint) + return -EPROBE_DEFER; + + panel_node = of_graph_get_remote_port_parent(endpoint); + if (!panel_node) + return -EPROBE_DEFER; If nobody else has objections over using of_graph functions instead of phandles, I can respin this patchset by making use of video ports. Ajay > Say, we could have a display board, with a panel and an encoder and > maybe some other components, which takes parallel RGB as input. The same > display board could as well be connected to an OMAP board or to an > Exynos board. > > I think the exact same display-board.dtsi file, which describes the > devices and connections in the display board, should be usable on both > OMAP and Exynos platforms. This means we need to have a common way to > describe video devices, just as we have for other things. > > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |