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

On 03/08/2014 12:41 PM, Grant Likely wrote:

quoted

quoted

Another thought. In terms of the pattern, I would add a recommendation

quoted

 >  that there should be a way to identify ports of a particular type. ie.
 >  If I were using the pattern to implement an patch bay of DSP filters,
 >  where each input and output, then each target node should have a unique
 >  identifier property analogous to "interrupt-controller" or
 >  "gpio-controller". In this fictitious example I would probably choose
 >  "audiostream-input-port" and "audiostream-output-port" as empty
 >  properties in the port nodes. (I'm not suggesting a change to the
 >  existing binding, but making a recommendation to new users).

 I don't see any harm in that, but I don't right away see what could be
 done with them? Did you have something in mind?

It would help with schema validation and allow ports of the same
interface to get grouped together.

quoted

quoted

 I guess those could be used to study the graph before the drivers have
 been loaded. After the drivers have been loaded, the drivers should
 somehow register themselves and the ports/endpoints. And as the driver
 knows what kind of ports they are, it can supply this information in the
 runtime data structures.

 If we do that, would it be better to have two pieces of data:
 input/output/bi-directional, and the port type (say, mipi-dpi, lvds, etc.)?

I'm not sure about the direction information (it also came up when we
originally discussed this binding), but the port type information would
be useful. As it turns out, it is not always possible to describe a data
bus interface type/data transmission protocol with a set of primitive
properties in an endpoint node. Especially in cases when the physical
layer is basically identical, for instance in case of MIPI CSI-2 and
SMIA CCP2, or in future MIPI CSI-3 and MIPI CSI-2.

In general there could likely be more than one supported, if both the
transmitter and the receiver are sufficiently configurable.

Then, to be able to fully describe a data port, perhaps we could
add a property like 'interface-type' or 'bus-type' with values like
"mipi-dbi", mipi-dsi", "mipi-csi2", "smia-ccp2", "hdmi", etc.

Sure. That's worth considering.