| Message ID | 14a44a664f40584ffa25c1764aab5ebf97809c71.1589548223.git.agx@sigxcpu.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/bridge: Add mux input selection bridge | expand |
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@sigxcpu.org> > --- > .../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. 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. Rob
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@sigxcpu.org> > > --- > > .../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.
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@sigxcpu.org> > > --- > > .../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. I thought about naming the mux pixel-input-mux (input-mux sounding too generic) but then i hit rockchip-drm and went for that name. The binding itself is not a drm thing in itself it really aims to model how the mux is placed in the 'display pipeline' of the SoC (as Laurent explained). Should I go with pixel-input-mux? > 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. A mux control property is how it's modeled at the moment but that is very SoC specific. > 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. It's a different part of the SoC that lives in a register range very separate (iomuxc_gpr) from MIPI/DSI (nwl). Does that qualify? Cheers, -- Guido > > Rob >
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 + +maintainers: + - Guido Gúnther <agx@sigxcpu.org> + +description: | + The input multiplexer bridge allows to select an input source + via an associated mux controller. + +properties: + compatible: + const: mux-input-bridge + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + default-input: + description: The default input to use + + mux-controls: + description: + mux controller node to use for operating the input mux + + ports: + type: object + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^port@[0-9]+": + type: object + description: + At least three nodes containing endpoints connecting to the + pixel data inputs and outputs. The last port is always the + output port. + + properties: + reg: + maxItems: 1 + + endpoint: + description: sub-node describing the input + type: object + + required: + - reg + + additionalProperties: false + + required: + - port@0 + - port@1 + - port@2 + + additionalProperties: false + +required: + - '#address-cells' + - '#size-cells' + - mux-controls + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + }; + + mipi-mux { + compatible = "mux-input-bridge"; + default-input = <0>; + mux-controls = <&mux 0>; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dpi_mux_from_lcdif: endpoint { + remote-endpoint = <&lcdif_dpi_out>; + }; + }; + + port@1 { + reg = <1>; + + dpi_mux_from_dccss: endpoint { + remote-endpoint = <&dcss_dpi_out>; + }; + }; + + port@2 { + reg = <2>; + + dpi_mux_out: endpoint { + remote-endpoint = <&nwl_dpi_in>; + }; + }; + }; + };
The bridge allows to select the input source via a mux controller. Signed-off-by: Guido Günther <agx@sigxcpu.org> --- .../display/bridge/mux-input-bridge.yaml | 123 ++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml