Hi Tomi,
On Thursday 17 October 2013 15:32:29 Tomi Valkeinen wrote:
> On 17/10/13 15:17, Laurent Pinchart wrote:
> > On Thursday 17 October 2013 14:59:41 Tomi Valkeinen wrote:
> >> On 17/10/13 14:51, Laurent Pinchart wrote:
> >>>> I'm not sure if there's a specific need for the port or endpoint nodes
> >>>> in cases like the above. Even if we have common properties describing
> >>>> the endpoint, I guess they could just be in the parent node.
> >>>>
> >>>> panel {
> >>>> remote = <&dc>;
> >>>> common-video-property = <asd>;
> >>>> };
> >>>>
> >>>> The above would imply one port and one endpoint. Would that work? If we
> >>>> had a function like parse_endpoint(node), we could just point it to
> >>>> either a real endpoint node, or to the device's node.
> >>>
> >>> You reference the display controller here, not a specific display
> >>> controller output. Don't most display controllers have several outputs ?
> >>
> >> Sure. Then the display controller could have more verbose description.
> >> But the panel could still have what I wrote above, except the 'remote'
> >> property would point to a real endpoint node inside the dispc node, not
> >> to the dispc node.
> >>
> >> This would, of course, need some extra code to handle the different
> >> cases, but just from DT point of view, I think all the relevant
> >> information is there.
> >
> > There's many ways to describe the same information in DT. While we could
> > have DT bindings that use different descriptions for different devices
> > and still support all of them in our code, why should we opt for that
> > option that will make the implementation much more complex when we can
> > describe connections in a simple and generic way ?
>
> My suggestion was simple and generic. I'm not proposing per-device
> custom bindings.
>
> My point was, if we can describe the connections as I described above,
> which to me sounds possible, we can simplify the panel DT data for 99.9%
> of the cases.
>
> To me, the first of these looks much nicer:
>
> panel {
> remote = <&remote-endpoint>;
> common-video-property = <asd>;
> };
>
> panel {
> port {
> endpoint {
> remote = <&remote-endpoint>;
> common-video-property = <asd>;
> };
> };
> };
Please note that the common video properties would be in the panel node, not
in the endpoint node (unless you have specific requirements to do so, which
isn't the common case).
> If that can be supported in the SW by adding complexity to a few functions,
> and it covers practically all the panels, isn't it worth it?
>
> Note that I have not tried this, so I don't know if there are issues.
> It's just a thought. Even if there's need for a endpoint node, perhaps
> the port node can be made optional.
It can be worth it, as long as we make sure that simplified bindings cover the
needs of the generic code.
We could assume that, if the port subnode isn't present, the device will have
a single port, with a single endpoint. However, isn't the number of endpoints
a system property rather than a device property ? If a port of a device is
connected to two remote ports it will require two endpoints. We could select
the simplified or full bindings based on the system topology though.
I've CC'ed Sylwester Nawrocki and Guennadi Liakhovetski, the V4L2 DT bindings
authors, as well as the linux-media list, to get their opinion on this.
--
Regards,
Laurent Pinchart
Attachment:
signature.asc
Description: This is a digitally signed message part.
