[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

Laurent Pinchart laurent.pinchart at ideasonboard.com
Wed Oct 30 00:08:39 CET 2013


Hello,

On Tuesday 29 October 2013 20:47:44 Sylwester Nawrocki wrote:
> On 29/10/13 20:23, Tomasz Figa wrote:
> > On Tuesday 29 of October 2013 12:19:35 Olof Johansson wrote:
> > > It's a very deeply nested structure, I'm not sure there's a need to
> > > make a ports {} subnode really.

Agreed, this can be simplified. We've introduced the ports node to group 
multiple ports when the device tree node that contains them also has child 
devices (which is a pretty uncommon case). When this happens, we need 
potentially different #address-cells values for the ports and for the child 
devices. In all other case the ports node can be omitted and the port nodes 
placed directly as children of the device node.

> > > 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 agree, a bus type would be useful. I've also been thinking about adding a 
direction property for ports, although that information could be considered as 
device driver knowledge.

> 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.

It's not too late to clean it up and create a v2 :-)

> >> > 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.

I should have read Sylwester's e-mail completely before writing the same 
explanation above :-)

-- 
Regards,

Laurent Pinchart



More information about the dri-devel mailing list