Hi,
On 01/30/2013 01:40 PM, Sylwester Nawrocki wrote:
On 01/25/2013 02:52 AM, Laurent Pinchart wrote:
+Data interfaces on all video devices are described by their child 'port'
+nodes. Configuration of a port depends on other devices participating in
+the data transfer and is described by 'endpoint' subnodes.
+
+dev {
+ #address-cells =<1>;
+ #size-cells =<0>;
+ port@0 {
+ endpoint@0 { ... };
+ endpoint@1 { ... };
+ };
+ port@1 { ... };
+};
+
+If a port can be configured to work with more than one other device on
+the same bus, an 'endpoint' child node must be provided for each of
+them. If more than one port is present in a device node or there is more
+than one endpoint at a port, a common scheme, using '#address-cells',
+'#size-cells' and 'reg' properties is used.
Wouldn't this cause problems if the device has both video ports and a
child bus ? Using #address-cells and #size-cells for the video ports would
prevent the child bus from being handled in the usual way.
Indeed, it looks like a serious issue in these bindings.
A possible solution would be to number ports with a dash instead of a @,
as done in pinctrl for instance. We would then get
port-0 {
endpoint-0 { ... };
endpoint-1 { ... };
};
port-1 { ... };
Another possible solution could be putting the port nodes under
a ports node, for these cases where a device has a child bus.
Where there is no conflict, the ports node could be omitted for
simplicity. Does it sound reasonable ?
device {
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
endpoint@0 {
reg = <0>;
};
endpoint@1 { ... };
};
port@1 { ... };
};
};
One problem here is that index of the port or the endpoint node can have
random value and don't need to start with 0, which is the case for the pinctrl
properties. It makes iterating over those nodes more difficult, instead
of using standard functions like of_node_cmp() we would need to search for
sub-strings in the node name.
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
