Hi Philipp,
On Friday, 23 February 2018 11:56:52 EET Philipp Zabel wrote:
> On Fri, 2018-02-23 at 11:29 +0200, Laurent Pinchart wrote:
> > On Thursday, 22 February 2018 03:39:37 EET Steve Longerbeam wrote:
> >> For some subdevices, a fwnode endpoint that has no connection to a
> >> remote endpoint may not be an error. Let the parse_endpoint callback
> > make that decision in v4l2_async_notifier_fwnode_parse_endpoint(). If
> >> the callback indicates that is not an error, skip adding the asd to the
> >> notifier and return 0.
> >>
> >> For the current users of v4l2_async_notifier_parse_fwnode_endpoints()
> >> (omap3isp, rcar-vin, intel-ipu3), return -EINVAL in the callback for
> >> unavailable remote fwnodes to maintain the previous behavior.
> >
> > I'm not sure this should be a per-driver decision.
> >
> > Generally speaking, if an endpoint node has no remote-endpoint property,
> > the endpoint node is not needed. I've always considered such an endpoint
> > node as invalid. The OF graphs DT bindings are however not clear on this
> > subject.
>
> Documentation/devicetree/bindings/graph.txt says:
>
> Each endpoint should contain a 'remote-endpoint' phandle property
> that points to the corresponding endpoint in the port of the remote
> device.
>
> ("should", not "must").
The DT bindings documentation has historically used "should" to mean "must" in
many places :-( That was a big mistake.
> Later, the remote-node property explicitly lists the remote-endpoint
> property as optional.
I've seen that too, and that's why I mentioned that the documentation isn't
clear on the subject.
> > I have either failed to notice when they got merged, or they slowly
> > evolved over time to contain contradictory information. In any case, I
> > think we should decide on whether such a situation is valid or not from
> > an OF graph point of view, and then always reject or always accept and
> > ignore those endpoints.
>
> We are currently using this on i.MX6 to provide empty labeled endpoints
> in the dtsi files for board DT writers to link to, both for the display
> output and video capture ports.
> See for example the endpoints with the labels ipu1_di0_disp0 and
> ipu1_csi0_mux_from_parallel_sensor in arch/arm/boot/dts/imx6q.dtsi.
This could also be achieved by adding the endpoints in the board DT files. See
for instance the hdmi@fead0000 node in arch/arm64/boot/dts/renesas/
r8a7795.dtsi and how it gets extended in arch/arm64/boot/dts/renesas/r8a7795-
salvator-x.dts. On the other hand, I also have empty endpoints in the
display@feb00000 node of arch/arm64/boot/dts/renesas/r8a7795.dtsi.
I think we should first decide what we want to do going forward (allowing for
empty endpoints or not), clarify the documentation, and then update the code.
In any case I don't think it should be a per-device decision.
--
Regards,
Laurent Pinchart
