Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Tomi Valkeinen <hidden>
Date: 2014-03-11 12:59:50
Also in:
linux-media, lkml
On 11/03/14 13:43, Laurent Pinchart wrote:
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. Tomi
Attachments
- signature.asc [application/pgp-signature] 901 bytes