Hi Rob, On Thu, May 28, 2020 at 01:48:04PM -0600, Rob Herring wrote: > On Fri, May 15, 2020 at 03:12:10PM +0200, Guido Günther wrote: > > The bridge allows to select the input source via a mux controller. > > > > Signed-off-by: Guido Günther <agx@xxxxxxxxxxx> > > --- > > .../display/bridge/mux-input-bridge.yaml | 123 ++++++++++++++++++ > > 1 file changed, 123 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml > > new file mode 100644 > > index 000000000000..4029cf63ee5c > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml > > @@ -0,0 +1,123 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: DRM input source selection via multiplexer > > DRM is not a hardware thing. > > The graph binding is already designed to support muxing. Generally, > multiple endpoints on an input node is a mux. So either the device with > the input ports knows how to select the input, or you just need a > mux-control property for the port to have some other device implement > the control. The mux modelled by this binding is used by Guido with the NWL DSI bridge integrated in the i.MX8. The NWL DSI is an IP core that has a single input. The i.MX8 has an additional mux in front of the NWL DSI, to select between the two display controllers in the SoC (eLCDIF and DCSS). The mux doesn't belong to any of the display controller, it's really glue logic between the display controllers and the NWL DSI bridge. I agree that the bindings shouldn't mention DRM. I would however prefer not adding a mux-control property and multiple input ports to the NWL DSI binding, as the mux isn't internal to that IP core (if we go that route, we would need to add mux control to any IP core that would be integrated in an SoC with a mux in front). As DT should describe the hardware, I think describing the standalone mux between the display controllers and the NWL DSI bridge makex sense. We already have a DT binding for a video mux (Documentation/devicetree/bindings/media/video-mux.txt). From a DT point of view, I see no reason not to reuse that. From a driver point of view that will be messy, as the driver that binds to the video-mux compatible string is part of V4L2. That's a driver issue however (and not a new one, we already have devices that can be part of a video capture pipeline or a video display pipeline), and should be solved on the software side, not the DT side. It will however not be easy work, which explains why, so far, everybody has ignored the issue hoping that someone else would be hit by it first. We may have reached that day. > You could do it like you have below. That would be appropriate if > there's a separate h/w device controlling the muxing. Say for example > some board level device controlled by i2c. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
