Hi Tomi,
On Monday 10 March 2014 08:00:02 Tomi Valkeinen wrote:
> On 08/03/14 17:54, Laurent Pinchart wrote:
> >> Sylwester suggested as an alternative, if I understood correctly, to
> >>
> >> drop the endpoint node and instead keep the port:
> >> device-a {
> >> implicit_output_ep: port {
> >> remote-endpoint = <&explicit_input_ep>;
> >> };
> >> };
> >>
> >> device-b {
> >> port {
> >> explicit_input_ep: endpoint {
> >> remote-endpoint = <&implicit_output_ep>;
> >> };
> >> };
> >> };
> >>
> >> This would have the advantage to reduce verbosity for devices with
> >> multiple ports that are only connected via one endport each, and you'd
> >> always have the connected ports in the device tree as 'port' nodes.
> >
> > I like that idea. I would prefer making the 'port' nodes mandatory and the
> > 'ports' and 'endpoint' nodes optional. Leaving the 'port' node out
> > slightly
> > decreases readability in my opinion, but making the 'endpoint' node
> > optional increases it. That's just my point of view though.
>
> I, on the other hand, don't like it =). With that format, the
> remote-endpoint doesn't point to an EP, but a port. And you'll have
> endpoint's properties in a port node, among the port's properties.
We'll need to discuss port and endpoint properties separately, but it might
make sense to allow endpoints to override port properties instead of
specifying the same value explicitly for each endpoint. Endpoint parsing
functions would thus look for properties in endpoints first and then in the
parent port node if the property can't be found. This would work with implicit
endpoints and would be hidden to the drivers.
(Please note that this is just food for thought)
--
Regards,
Laurent Pinchart
Attachment:
signature.asc
Description: This is a digitally signed message part.
