Thread (74 messages) 74 messages, 13 authors, 2014-03-21

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

From: Laurent Pinchart <hidden>
Date: 2014-03-11 13:15:19
Also in: linux-media, lkml

Hi Tomi,

On Tuesday 11 March 2014 14:59:20 Tomi Valkeinen wrote:
On 11/03/14 13:43, Laurent Pinchart wrote:
quoted
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help