Messages in this thread | | | Date | Sun, 09 Mar 2014 00:25:07 +0100 | From | Sylwester Nawrocki <> | Subject | 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: >>> 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.
| |