linux-kernel - Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200528224832.GE14756@pendragon.ideasonboard.com>
Date:   Fri, 29 May 2020 01:48:32 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Guido Günther <agx@...xcpu.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Shawn Guo <shawnguo@...nel.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Sam Ravnborg <sam@...nborg.org>,
        Anson Huang <Anson.Huang@....com>,
        Leonard Crestez <leonard.crestez@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Peng Fan <peng.fan@....com>,
        Robert Chiras <robert.chiras@....com>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for
 input mux bridge

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@...xcpu.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.

-- 
Regards,

Laurent Pinchart