Hi,
On 29/10/13 20:23, Tomasz Figa wrote:
>> It's a very deeply nested structure, I'm not sure there's a need to
>> > make a ports {} subnode really.
>> >
>> > Also, I don't know if it makes sense to always name it
>> > remote-endpoint, or to use a more flexible name depending on what is
>> > actually connected, over which bus, etc.
I have been thinking about a 'bus_type' as an 'endpoint' node property.
Currently the data bus type is derived from selected properties in
endpoint node, which is IMO not good enough.
I'm not sure if naming 'remote-endpoint' differently would be helpful,
as it is now it seems easier to write a generic links parser.
Nevertheless I wish we have defined a bit simplified option in this binding
right from the beginning.
>> > But overall this looks sane-ish.
>
> I fully agree with you. Personally I would take a bit different design
> decisions when designing this bindings, but here I'm just pointing an
> already defined binding that should suit the needs described in this
> thread, to avoid reinventing the wheel.
The 'ports' node is optional. It needs to be used only if, e.g. bridge-a
node contains device child nodes and these sub-nodes use 'reg' property.
In such case #address-cells, #size-cells properties for 'port' nodes could
be conflicting with those for the device child nodes.
Thanks,
Sylwester
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
