RFC: DSI/DRM multiplexer bridge

RFC: DSI/DRM multiplexer bridge

[Alexander Stein]

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.

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.

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

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?

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/

Re: RFC: DSI/DRM multiplexer bridge

[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).

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

>
> 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]

[1] https://lore.kernel.org/all/CAMty3ZD7eFi4o7ZXNtjShoLd5yj3wn85Fm6ZNL89=QpWj44KPw@mail.gmail.com/T/
[2] https://patchwork.kernel.org/project/dri-devel/patch/20230218111712.2380225-6-treapking@chromium.org/
[3] https://indico.freedesktop.org/event/2/contributions/76/
[4] https://www.youtube.com/watch?v=PoYdP9fPn-4&t=624s

Thanks,
Jagan.

Re: RFC: DSI/DRM multiplexer bridge

[Alexander Stein]

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.

> > 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@mail.gmail.com/T/ [2]
> https://patchwork.kernel.org/project/dri-devel/patch/20230218111712.2380225
> -6-treapking@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/

Re: 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@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.
>
> > > 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@mail.gmail.com/T/ [2]
> > https://patchwork.kernel.org/project/dri-devel/patch/20230218111712.2380225
> > -6-treapking@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

Re: RFC: DSI/DRM multiplexer bridge

[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?

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

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.

Thanks,
Jagan.

Re: RFC: DSI/DRM multiplexer bridge

[Alexander Stein]

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/

Re: RFC: DSI/DRM multiplexer bridge

[Jagan Teki]

On Tue, Apr 11, 2023 at 1:17 PM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:
>
> 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).

If we don't do any gpio handling in mux-bridge then why do we need
mux-bridge? what exactly is the job of the mux-bridge driver?

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

This is also possible but sometimes port 1 with ep 0, 1 means we
pipeline offers 2 outputs but one at a time.

> 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?

The idea here is to change the bridge chain and this can be done in
static via dt or runtime. In your case the state of the DIP-switch
resembles desired output, correct? if so if we read that state at
run-time, find the output, and attach that particular bridge chain. Fo
dt case of showing output read the dt about the output state and
attach the bridge chain accordingly.

Thanks,
Jagan.