Messages in this thread | | | Date | Tue, 11 Mar 2014 14:59:20 +0200 | From | Tomi Valkeinen <> | Subject | Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of |
| |
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.
Tomi
[unhandled content-type:application/pgp-signature] | |