Message-ID: <1883687.VdfitvQEN3@avalon>
Date:	Tue, 11 Mar 2014 14:16:37 +0100
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	Philipp Zabel <p.zabel@...gutronix.de>,
	Grant Likely <grant.likely@...aro.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Rob Herring <robherring2@...il.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Philipp Zabel <philipp.zabel@...il.com>
Subject: Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

Hi Tomi,

On Tuesday 11 March 2014 14:59:20 Tomi Valkeinen wrote:
> On 11/03/14 13:43, Laurent Pinchart wrote:
> >> We could scan the whole tree for entities, ports and endpoints once, in
> >> the base oftree code, and put that into a graph structure, adding the
> >> backlinks. The of_graph_* helpers could then use that graph instead of
> >> the device tree.
> > 
> > That could work. The complexity would still be quadratic, but we would
> > parse the full device tree once only.
> > 
> > The runtime complexity would still be increased, as the graph helpers
> > would need to find the endpoint object in the parsed graph corresponding
> > to the DT node they get as an argument. That's proportional to the number
> > of graph elements, not the total number of DT nodes, so I suppose it's not
> > too bad.
> > 
> > We also need to make sure this would work with insertion of DT fragments
> > at runtime. Probably not a big deal, but it has to be kept in mind.
> 
> About the endpoint linking direction... As I think was suggested, the
> base logic would be to make endpoints point "outward" from the SoC, i.e.
> a display controller would point to a panel, and a capture controller
> would point to a sensor.
>
> But how about this case:
> 
> I have a simple video pipeline with a display controller, an encoder and
> a panel, as follows:
> 
> dispc -> encoder -> panel
> 
> Here the arrows show which way the remote-endpoint links point. So
> looking at the encoder, the encoder's input port is pointed at by the
> dispc, and the encoder's output port points at the panel.
> 
> Then, I have a capture pipeline, with a capture controller, an encoder
> (the same one that was used for display above) and a sensor, as follows:
> 
> camc -> encoder -> sensor
> 
> Again the arrows show the links. Note that here the encoder's _output_
> port is pointed at by the camc, and the encoder's _input_ port points at
> the sensor.
> 
> So depending on the use case, the endpoints would point to opposite
> direction from the encoder's point of view.
> 
> And if I gathered Grant's opinion correctly (correct me if I'm wrong),
> he thinks things should be explicit, i.e. the bindings for, say, an
> encoder should state that the encoder's output endpoint _must_ contain a
> remote-endpoint property, whereas the encoder's input endpoint _must
> not_ contain a remote-endpoint property.

Actually my understand was that DT links would have the same direction as the 
data flow. There would be no ambiguity in that case as the direction of the 
data flow is known. What happens for bidirectional data flows still need to be 
discussed though. And if we want to use the of-graph bindings to describe 
graphs without a data flow, a decision will need to be taken there too.

-- 
Regards,

Laurent Pinchart

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)

Powered by blists - more mailing lists