On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding <thierry.red...@gmail.com> wrote: > On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote: >> Hi Ajay, >> >> On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote: >> > On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote: >> > > On 20/09/14 14:22, Ajay kumar wrote: >> > >> 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. >> > > >> > > The discussion did digress somewhat. >> > > >> > > As a clarification, I'm in no way nack'ing this series because it >> > > doesn't use the graphs for video connections. I don't see the simple >> > > phandle bindings used here as broken as such. >> > >> > Well, I am okay with any approach you guys decide on. I desperately want >> > this to get this in since it has been floating around for quite sometime. >> > The more we drag this, the more rework for me since the number of platforms >> > using bridge support is increasing daily! >> >> I won't nack this patch either. I'm however concerned that we'll run straight >> into the wall if we don't come up with an agreement on a standard way to >> describe connections in DT for display devices, which is why I would prefer >> the ps8622 bindings to use OF graph to describe connections. > > I think there's not really an easy way out here. It's pretty bold trying > to come up with a common way to describe bridges when we have only a > single one (and a single use-case at that). The worst that can happen is > that we need to change the binding at some point, in which case we may > have to special-case early drivers, but I really don't think that's as > much of an issue as everybody seems to think. > > This series has been floating around for months because we're being > overly prudent to accept a binding that /may/ turn out to not be generic > enough. Right. It would be great if you guys come to agreement ASAP!
Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
