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

[Sylwester Nawrocki <sylvester.nawrocki@gmail.com>]

On 03/08/2014 12:41 PM, Grant Likely wrote:
>>> Another thought. In terms of the pattern, I would add a recommendation
>>> >  >  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.
>
>> >  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.