Re: RFC: DSI/DRM multiplexer bridge

[Alexander Stein <alexander.stein@ew.tq-group.com>]

Am Donnerstag, 6. April 2023, 11:55:52 CEST schrieb Jagan Teki:
> [Replying the Daniel thread since he included bridge maintainers]
> 
> On Thu, Apr 6, 2023 at 2:07 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > Adding the usual bridge maintainer/review folks since this looks tricky.
> > -Daniel
> > 
> > On Thu, 6 Apr 2023 at 10:33, Alexander Stein
> > 
> > <alexander.stein@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@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.
> 
> So, you need to manually adjust the switch and boot the required
> output and the state of the output depends on the set switch gpios
> isn't it? do you need to set any gpio so that the required output will
> select?

That's correct. There is no GPIO I need to set by software for the outputs 
(despite the enable GPIO on the DSI-to-X bridges, but this is handled in their 
appropriate drivers).

> > > > > 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
> 
> This looks correct to me, as I designed the similar one.
> 
> > > > > 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.
> 
> In my opinion, the switched-bridge needs to focus on switching the
> outputs based on DIP gpios, and hotplug events need to handle the
> associated display bridges like DP, HDMI, etc. It is possible for the
> switched-bridge to route the output displays without the hot plug.

I agree, IMHO hotplug/HPD events is related to downstream connectors.

> Assume the switched-bridge has port 1 and ep 0 connected to LVDS and
> port 1 and ep 1 connected to DP. then find and attach them at the
> bridge attach function. and do the necessary gpio enablements in
> enable or pre_enables.

Ah nice. My initial idea was:
* port 0 ep 0: input
* port 1 ep 0: LVDS
* port 2 ep 0: DP

But using two endpoints in one port looks neat. Although I'm not sure if there 
is an actual difference.
But if the GPIO check is only done in enable/pre_enable there is no way to 
support changing the DIP switch aka switched-bridge at runtime. There is 
nothing the hotplug (non-HPD) event can be sent to, no?

Best regards,
Alexander
-- 
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/