RFC: DSI/DRM multiplexer bridge

[Daniel Vetter]

Adding the usual bridge maintainer/review folks since this looks tricky.
-Daniel

On Thu, 6 Apr 2023 at 10:33, Alexander Stein
<alexander.stein at ew.tq-group.com> wrote:
>
> Hi Jagan,
>
> thanks for your reply.
>
> Am Mittwoch, 5. April 2023, 16:39:07 CEST schrieb Jagan Teki:
> > On Wed, Apr 5, 2023 at 7:39 PM Alexander Stein
> >
> > <alexander.stein at ew.tq-group.com> wrote:
> > > Hi,
> > >
> > > my platform has a DIP switch controlled multiplexer for MIPI DSI output
> > > signals. One output has a TI SN65DSI84 (LVDS) and the other output has a
> > > TI
> > > SN65DSI86 (eDP) attached to it. The Multiplexer status can be read back
> > > from a GPIO. The GPIO is also IRQ capable, so it would be possible to
> > > support hotplug additionally later on.
> >
> > I have this requirement a year back [1] but my design has i.mx8mq DSI
> > outputs to SN65DSI84(LVDS) and ADV7533 (HDMI) and GPIO has muxed as
> > IRQ in order to find the bridge selection. (not confused with HDMI
> > HPD).
>
> Looks quite similar. This platform can be used using imx8mq, imx8mm or im8xmn.
> That mentioned GPIO is also not the HDMI HPD, but connected to a DIP switch on
> the mainboard to be changed manually.
>
> > > My initial idea was to create a DRM multiplexer bridge driver which
> > > (depending on the input GPIO) allows only one output to be enabled.
> > > Unfortunately ti- sn65dsi86.c driver expects a DSI host on remote node 0
> > > (see ti_sn_attach_host and ti_sn_bridge_parse_dsi_host), so it does not
> > > work. ti-sn65dsi83.c just requires a drm_bridge.
> >
> > Yes, we need to have a finite amount of pipeline changes. assuming
> > that your mux bridge sits between DSI to Output interfaces the
> > proposed mux bridge selects which pipeline.
>
> My setup looks like this, but the switch is a different one than yours.
>
>                               | => SN54DSI86 => DP Connector
> DSI Host => display-switch => |
>                               | => SN65DSI83 => Panel-Simple
>
> > > What is the best approach for this? I currently see two approaches:
> > > * Create an explicit DSI/DRM multiplexer bridge driver which registers
> > > itself as DSI host
> > > * Create a DRM multiplexer bridge (only). But this needs to remove the DSI
> > > device registration from ti-sn65dsi86.c
> >
> > Based on my experience, having a muxed bridge between in and out would
> > be proper in order to satisfy the pipeline as well as the design. That
> > mux bridge has to be a normal bridge doesn't aware of DSI or any other
> > interface like one of the submissions has done in the recent mailing
> > list. [2] Things would be complicated when we switch the outputs but
> > we still use normal static switching of outputs in a proper way.
> >
> > > I am aware that DSI support is suboptimal, so I'm not sure which approach
> > > on the TI bridge drivers is the correct one and needs to be considered as
> > > given. Any ideas?
> >
> > I did implement some complicated things of switching outputs at
> > runtime but the idea of the switching pipelines would be similar if
> > you want to implement it in a normal static way. Here are some details
> > and a demo of how those been worked. [3] [4]
>
> Thanks for the links. From what I read in those discussions dynamically
> (re)building the bridge chains it not correct/acceptable. Instead two bridges
> shall be created, but only one connector at the end shall be enabled. This
> would look like this:
>
>    switched-bridge
>     +------------+                 +-------------+
>     | drm_bridge-|- next_bridge -- | LVDS bridge |- connector
>     |            |                 +-------------+
> in -|            |
>     |            |                 +-------------+
>     | drm_bridge-|- next_bridge -- | eDP bridge  |- connector
>     +------------+                 +-------------+
>           ^
>           |
>       DIP switch
>
> But here I'm not so sure how an (hotplug) event (e.g. IRQ) on the switched-
> bridge can be forwarded to the connectors. But this hotplug event seems to be
> essential so that DRM master can reconfigure it's output.
>
> Best regards,
> Alexander
>
> > [1]
> > https://lore.kernel.org/all/CAMty3ZD7eFi4o7ZXNtjShoLd5yj3wn85Fm6ZNL89=QpWj4
> > 4KPw at mail.gmail.com/T/ [2]
> > https://patchwork.kernel.org/project/dri-devel/patch/20230218111712.2380225
> > -6-treapking at chromium.org/ [3]
> > https://indico.freedesktop.org/event/2/contributions/76/
> > [4] https://www.youtube.com/watch?v=PoYdP9fPn-4&t=624s
> >
> > Thanks,
> > Jagan.
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch