ping!
On Fri, Oct 10, 2014 at 6:33 PM, Ajay kumar ajaynumb@gmail.com wrote:
On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding thierry.reding@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