DSI Bridge switching

DSI Bridge switching

[Jagan Teki]

Hi,

I think this seems to be a known use case for industrial these days with i.mx8m.

The host DSI would configure with two bridges one for DSI to LVDS
(SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
can use only one bridge at a time as host DSI support single out port.
So we can have two separate device tree files for LVDS and HDMI and
load them static.

But, one of the use cases is to support both of them in single dts, and
- Turn On LVDS (default)
- Turn Off LVDS then Turn On HDMI when cable plug-in.

The HDMI event can be detected via some HDMI-INT GPIO on-board design.

The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
port 2 in the DSI host node, and trying to attach the respective
bridge based on HDMI-INT like repeating the bridge attachment cycle
based on the HDMI-INT.

Can it be possible to do bridge attachment at runtime? something like
a bridge hotplug event? or any other possible solutions?

Any suggestions?

Thanks,
Jagan.

Re: DSI Bridge switching

[Andrzej Hajda]

Hi,

Removed my invalid email (I will update files next week).


On 08.10.2021 13:14, Jagan Teki wrote:
> Hi,
> 
> I think this seems to be a known use case for industrial these days with i.mx8m.
> 
> The host DSI would configure with two bridges one for DSI to LVDS
> (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> can use only one bridge at a time as host DSI support single out port.
> So we can have two separate device tree files for LVDS and HDMI and
> load them static.
> 
> But, one of the use cases is to support both of them in single dts, and
> - Turn On LVDS (default)
> - Turn Off LVDS then Turn On HDMI when cable plug-in

Are you sure it will work from hardware PoV? Do you have some demuxer? 
isolation of pins?

> 
> The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> 
> The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> port 2 in the DSI host node, and trying to attach the respective
> bridge based on HDMI-INT like repeating the bridge attachment cycle
> based on the HDMI-INT.

I think more appropriate would be to share the same port, but provide 
two endpoints inside this port - we have two hardware sharing the same 
physical port.

> 
> Can it be possible to do bridge attachment at runtime? something like
> a bridge hotplug event? or any other possible solutions?
> 
> Any suggestions?

Practically it is possible, see exynos_dsi + panels, or exynos_dsi + 
some toshiba bridge - panel and bridge are dynamically 'plugged' and 
'unplugged' from exynos_drm, but they do not use bridge chain for this 
and some other reasons. (un|re|)plugging should be performed of course 
when pipeline is off (connector disconnected). I am not sure about 
bridges added to bridge chain - you need to inspect all opses to ensure 
it can be done safely.

And the main issue: Daniel does not like it :)

Regards
Andrzej


> 
> Thanks,
> Jagan.
> 

Re: DSI Bridge switching

[Laurent Pinchart]

Hello,

On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> Hi,
> 
> Removed my invalid email (I will update files next week).
> 
> On 08.10.2021 13:14, Jagan Teki wrote:
> > Hi,
> > 
> > I think this seems to be a known use case for industrial these days with i.mx8m.
> > 
> > The host DSI would configure with two bridges one for DSI to LVDS
> > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > can use only one bridge at a time as host DSI support single out port.
> > So we can have two separate device tree files for LVDS and HDMI and
> > load them static.
> > 
> > But, one of the use cases is to support both of them in single dts, and
> > - Turn On LVDS (default)
> > - Turn Off LVDS then Turn On HDMI when cable plug-in
> 
> Are you sure it will work from hardware PoV? Do you have some demuxer? 
> isolation of pins?

It may be in the category of "you shouldn't do this, but it actually
works". I've seen the same being done with two CSI-2 camera sensors
connected to the same receiver, with one of them being held in reset at
all times.

> > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > 
> > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > port 2 in the DSI host node, and trying to attach the respective
> > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > based on the HDMI-INT.
> 
> I think more appropriate would be to share the same port, but provide 
> two endpoints inside this port - we have two hardware sharing the same 
> physical port.

That sounds like the correct DT description to me.

> > Can it be possible to do bridge attachment at runtime? something like
> > a bridge hotplug event? or any other possible solutions?
> > 
> > Any suggestions?
> 
> Practically it is possible, see exynos_dsi + panels, or exynos_dsi + 
> some toshiba bridge - panel and bridge are dynamically 'plugged' and 
> 'unplugged' from exynos_drm, but they do not use bridge chain for this 
> and some other reasons. (un|re|)plugging should be performed of course 
> when pipeline is off (connector disconnected). I am not sure about 
> bridges added to bridge chain - you need to inspect all opses to ensure 
> it can be done safely.
> 
> And the main issue: Daniel does not like it :)

Neither do I :-) Could it be handled with two DRM connectors that are
mutually exclusive ?

-- 
Regards,

Laurent Pinchart

Re: DSI Bridge switching

[Dave Stevenson]

On Fri, 8 Oct 2021 at 14:37, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hello,
>
> On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > Hi,
> >
> > Removed my invalid email (I will update files next week).
> >
> > On 08.10.2021 13:14, Jagan Teki wrote:
> > > Hi,
> > >
> > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > >
> > > The host DSI would configure with two bridges one for DSI to LVDS
> > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > can use only one bridge at a time as host DSI support single out port.
> > > So we can have two separate device tree files for LVDS and HDMI and
> > > load them static.
> > >
> > > But, one of the use cases is to support both of them in single dts, and
> > > - Turn On LVDS (default)
> > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> >
> > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > isolation of pins?
>
> It may be in the category of "you shouldn't do this, but it actually
> works". I've seen the same being done with two CSI-2 camera sensors
> connected to the same receiver, with one of them being held in reset at
> all times.

Surely the correct way to do this would be with a D-PHY mux chip such
as OnSemi FSA642 [1] or those from Diodes Incorporated [2].
How you'd integrate such a mux into DRM is a totally different question.
With V4L2 and CSI2 it'd be relatively simple via Media Controller.

Just wiring them together isn't going to work very well for DSI
reverse direction communication, but neither of the chips Jagan lists
support this.

  Dave

[1] https://www.onsemi.com/products/interfaces/analog-switches/fsa642
[2] https://www.diodes.com/products/connectivity-and-timing/switches-mux/protocol-switches/mipi-switches/

> > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > >
> > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > port 2 in the DSI host node, and trying to attach the respective
> > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > based on the HDMI-INT.
> >
> > I think more appropriate would be to share the same port, but provide
> > two endpoints inside this port - we have two hardware sharing the same
> > physical port.
>
> That sounds like the correct DT description to me.
>
> > > Can it be possible to do bridge attachment at runtime? something like
> > > a bridge hotplug event? or any other possible solutions?
> > >
> > > Any suggestions?
> >
> > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > and some other reasons. (un|re|)plugging should be performed of course
> > when pipeline is off (connector disconnected). I am not sure about
> > bridges added to bridge chain - you need to inspect all opses to ensure
> > it can be done safely.
> >
> > And the main issue: Daniel does not like it :)
>
> Neither do I :-) Could it be handled with two DRM connectors that are
> mutually exclusive ?
>
> --
> Regards,
>
> Laurent Pinchart

Re: DSI Bridge switching

[Jagan Teki]

Hi Andrzej,

On Fri, Oct 8, 2021 at 6:57 PM Andrzej Hajda <andrzej.hajda@gmail.com> wrote:
>
> Hi,
>
> Removed my invalid email (I will update files next week).
>
>
> On 08.10.2021 13:14, Jagan Teki wrote:
> > Hi,
> >
> > I think this seems to be a known use case for industrial these days with i.mx8m.
> >
> > The host DSI would configure with two bridges one for DSI to LVDS
> > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > can use only one bridge at a time as host DSI support single out port.
> > So we can have two separate device tree files for LVDS and HDMI and
> > load them static.
> >
> > But, one of the use cases is to support both of them in single dts, and
> > - Turn On LVDS (default)
> > - Turn Off LVDS then Turn On HDMI when cable plug-in
>
> Are you sure it will work from hardware PoV? Do you have some demuxer?
> isolation of pins?

Correct. I have noticed after you mentioned this. Design has two 2:1
MIPI Switch PI3WVR626 [1] which take 2 data-lanes and clock from Host
and produce 4 data-lane and 1 clock to connect to ADV7535 and
SN65DSI84 bridges.

The switch has OE, SEL pins to select the desired to MUXed lanes/clock
routing to an appropriate bridge.

>
> >
> > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> >
> > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > port 2 in the DSI host node, and trying to attach the respective
> > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > based on the HDMI-INT.
>
> I think more appropriate would be to share the same port, but provide
> two endpoints inside this port - we have two hardware sharing the same
> physical port.

Make sense to me. I think we can in-corporate the MIPI Switch on the
pipeline as input data and clock lanes are muxing. not sure how it can
be done.

>
> >
> > Can it be possible to do bridge attachment at runtime? something like
> > a bridge hotplug event? or any other possible solutions?
> >
> > Any suggestions?
>
> Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> some toshiba bridge - panel and bridge are dynamically 'plugged' and
> 'unplugged' from exynos_drm, but they do not use bridge chain for this
> and some other reasons. (un|re|)plugging should be performed of course
> when pipeline is off (connector disconnected). I am not sure about
> bridges added to bridge chain - you need to inspect all opses to ensure
> it can be done safely.

I will check with this. However i did tried of hot-plug mechanism for
bridge in exiting DSI host sun6i_mipi_dsi.c [2] look like it surely
not possible with bridge-chain as hot-plug require drm pointer where
the same pointer is not available during attach call.

>
> And the main issue: Daniel does not like it :)

[1] https://www.diodes.com/assets/Datasheets/PI3WVR626.pdf
[2] https://elixir.bootlin.com/linux/v5.15-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L976

Jagan.

Re: DSI Bridge switching

[Jagan Teki]

Hi Dave,

On Fri, Oct 8, 2021 at 9:32 PM Dave Stevenson
<dave.stevenson@raspberrypi.com> wrote:
>
> On Fri, 8 Oct 2021 at 14:37, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> >
> > Hello,
> >
> > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > Hi,
> > >
> > > Removed my invalid email (I will update files next week).
> > >
> > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > Hi,
> > > >
> > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > >
> > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > can use only one bridge at a time as host DSI support single out port.
> > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > load them static.
> > > >
> > > > But, one of the use cases is to support both of them in single dts, and
> > > > - Turn On LVDS (default)
> > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > >
> > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > isolation of pins?
> >
> > It may be in the category of "you shouldn't do this, but it actually
> > works". I've seen the same being done with two CSI-2 camera sensors
> > connected to the same receiver, with one of them being held in reset at
> > all times.
>
> Surely the correct way to do this would be with a D-PHY mux chip such
> as OnSemi FSA642 [1] or those from Diodes Incorporated [2].
> How you'd integrate such a mux into DRM is a totally different question.
> With V4L2 and CSI2 it'd be relatively simple via Media Controller.
>
> Just wiring them together isn't going to work very well for DSI
> reverse direction communication, but neither of the chips Jagan lists
> support this.

Sorry to mention it before, we have two 2:1 MIPI D-PHY Switch [1] on
the design which take 2 data-lanes and clock from Host and produce 4
data-lane and 1 clock to connect to ADV7535 and SN65DSI84 bridges. The
switch has OE, SEL pins to select the desired to MUXed lanes/clock
routing to an appropriate bridge.

I think supporting the switch in the pipeline or logic that handle the
bridge switching might help.

[1] https://www.diodes.com/assets/Datasheets/PI3WVR626.pdf

Jagan.

Re: DSI Bridge switching

[Jagan Teki]

On Mon, Oct 11, 2021 at 12:51 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> Hi Dave,
>
> On Fri, Oct 8, 2021 at 9:32 PM Dave Stevenson
> <dave.stevenson@raspberrypi.com> wrote:
> >
> > On Fri, 8 Oct 2021 at 14:37, Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > >
> > > Hello,
> > >
> > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > Hi,
> > > >
> > > > Removed my invalid email (I will update files next week).
> > > >
> > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > Hi,
> > > > >
> > > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > > >
> > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > > can use only one bridge at a time as host DSI support single out port.
> > > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > > load them static.
> > > > >
> > > > > But, one of the use cases is to support both of them in single dts, and
> > > > > - Turn On LVDS (default)
> > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > >
> > > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > > isolation of pins?
> > >
> > > It may be in the category of "you shouldn't do this, but it actually
> > > works". I've seen the same being done with two CSI-2 camera sensors
> > > connected to the same receiver, with one of them being held in reset at
> > > all times.
> >
> > Surely the correct way to do this would be with a D-PHY mux chip such
> > as OnSemi FSA642 [1] or those from Diodes Incorporated [2].
> > How you'd integrate such a mux into DRM is a totally different question.
> > With V4L2 and CSI2 it'd be relatively simple via Media Controller.
> >
> > Just wiring them together isn't going to work very well for DSI
> > reverse direction communication, but neither of the chips Jagan lists
> > support this.
>
> Sorry to mention it before, we have two 2:1 MIPI D-PHY Switch [1] on
> the design which take 2 data-lanes and clock from Host and produce 4
> data-lane and 1 clock to connect to ADV7535 and SN65DSI84 bridges. The
> switch has OE, SEL pins to select the desired to MUXed lanes/clock
> routing to an appropriate bridge.
>
> I think supporting the switch in the pipeline or logic that handle the
> bridge switching might help.

MIPI Switch (PI3WVR626) has OE, SEL logic to select respective data
and clock lanes which are routed to bridge/panel. I think, these OE
and SEL logic can be part of pinmux so we can configure them on
respective bridge/panel nodes pinctrl (atleast on imx8m) instead of
handling them as separate nodes.

Jagan.

Re: DSI Bridge switching

[Jagan Teki]

Hi Laurent,

On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hello,
>
> On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > Hi,
> >
> > Removed my invalid email (I will update files next week).
> >
> > On 08.10.2021 13:14, Jagan Teki wrote:
> > > Hi,
> > >
> > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > >
> > > The host DSI would configure with two bridges one for DSI to LVDS
> > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > can use only one bridge at a time as host DSI support single out port.
> > > So we can have two separate device tree files for LVDS and HDMI and
> > > load them static.
> > >
> > > But, one of the use cases is to support both of them in single dts, and
> > > - Turn On LVDS (default)
> > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> >
> > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > isolation of pins?
>
> It may be in the category of "you shouldn't do this, but it actually
> works". I've seen the same being done with two CSI-2 camera sensors
> connected to the same receiver, with one of them being held in reset at
> all times.

Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
input data lanes and 1 clock lane from SoC and produces 4 data lanes
and 2 clock lanes and from switch output 2 lanes and 1 clock are
inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
LVDS.

However, routing of these lanes are controlled by SEL, OE GPIO pins.
So at a time we can access only single bridge.

>
> > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > >
> > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > port 2 in the DSI host node, and trying to attach the respective
> > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > based on the HDMI-INT.
> >
> > I think more appropriate would be to share the same port, but provide
> > two endpoints inside this port - we have two hardware sharing the same
> > physical port.
>
> That sounds like the correct DT description to me.
>
> > > Can it be possible to do bridge attachment at runtime? something like
> > > a bridge hotplug event? or any other possible solutions?
> > >
> > > Any suggestions?
> >
> > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > and some other reasons. (un|re|)plugging should be performed of course
> > when pipeline is off (connector disconnected). I am not sure about
> > bridges added to bridge chain - you need to inspect all opses to ensure
> > it can be done safely.
> >
> > And the main issue: Daniel does not like it :)
>
> Neither do I :-) Could it be handled with two DRM connectors that are
> mutually exclusive ?

How about adding lvds-connector, hdmi-connector on the pipeline and
select them based on the switch SEL GPIO? does it make sense to do
this implementation via display-connector.c

Thanks,
Jagan.

Re: DSI Bridge switching

[Jagan Teki]

 or a Hi All,

On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> Hi Laurent,
>
> On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> >
> > Hello,
> >
> > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > Hi,
> > >
> > > Removed my invalid email (I will update files next week).
> > >
> > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > Hi,
> > > >
> > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > >
> > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > can use only one bridge at a time as host DSI support single out port.
> > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > load them static.
> > > >
> > > > But, one of the use cases is to support both of them in single dts, and
> > > > - Turn On LVDS (default)
> > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > >
> > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > isolation of pins?
> >
> > It may be in the category of "you shouldn't do this, but it actually
> > works". I've seen the same being done with two CSI-2 camera sensors
> > connected to the same receiver, with one of them being held in reset at
> > all times.
>
> Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> input data lanes and 1 clock lane from SoC and produces 4 data lanes
> and 2 clock lanes and from switch output 2 lanes and 1 clock are
> inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> LVDS.
>
> However, routing of these lanes are controlled by SEL, OE GPIO pins.
> So at a time we can access only single bridge.
>
> >
> > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > > >
> > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > > port 2 in the DSI host node, and trying to attach the respective
> > > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > > based on the HDMI-INT.
> > >
> > > I think more appropriate would be to share the same port, but provide
> > > two endpoints inside this port - we have two hardware sharing the same
> > > physical port.
> >
> > That sounds like the correct DT description to me.
> >
> > > > Can it be possible to do bridge attachment at runtime? something like
> > > > a bridge hotplug event? or any other possible solutions?
> > > >
> > > > Any suggestions?
> > >
> > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > > and some other reasons. (un|re|)plugging should be performed of course
> > > when pipeline is off (connector disconnected). I am not sure about
> > > bridges added to bridge chain - you need to inspect all opses to ensure
> > > it can be done safely.
> > >
> > > And the main issue: Daniel does not like it :)
> >
> > Neither do I :-) Could it be handled with two DRM connectors that are
> > mutually exclusive ?
>
> How about adding lvds-connector, hdmi-connector on the pipeline and
> select them based on the switch SEL GPIO? does it make sense to do
> this implementation via display-connector.c

I have somehow managed to make runtime switching possible between LVDS
and HDMI with the help of DRM bridges.

                                                  | => ADV7535    =>
HDMI-A Connector
DSI Host => display-switch => |
                                                  |=> SN65DSI83 => Panel-Simple

display-switch here is a bridge driver that can switch or attach the
downstream bridge flow based on HDMI HPD here. One potential problem
is that when we switch from LVDS to HDMI Out the HDMI Out is displayed
with the resolution that LVDS has and it is unable to display higher
HDMI resolutions even though it supports it. Does anyone aware of
changing the resolution at runtime, please let me know?

Technically, the display-switch hardware does available in various forms
1. MIPI Switch PI3WVR626
2. Conventional Mux Switch
3. Converter bridge DSI to LVDS/HDMI (from Lontium).

Overall I believe this can be a potential possible feature and good to
support on Mainline as the hardware is intended to design for it.

Any thoughts on this please let me know?

Thanks,
Jagan.

Re: DSI Bridge switching

[Adam Ford]

On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
>  or a Hi All,
>
> On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > Hi Laurent,
> >
> > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > >
> > > Hello,
> > >
> > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > Hi,
> > > >
> > > > Removed my invalid email (I will update files next week).
> > > >
> > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > Hi,
> > > > >
> > > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > > >
> > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > > can use only one bridge at a time as host DSI support single out port.
> > > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > > load them static.
> > > > >
> > > > > But, one of the use cases is to support both of them in single dts, and
> > > > > - Turn On LVDS (default)
> > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > >
> > > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > > isolation of pins?
> > >
> > > It may be in the category of "you shouldn't do this, but it actually
> > > works". I've seen the same being done with two CSI-2 camera sensors
> > > connected to the same receiver, with one of them being held in reset at
> > > all times.
> >
> > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> > input data lanes and 1 clock lane from SoC and produces 4 data lanes
> > and 2 clock lanes and from switch output 2 lanes and 1 clock are
> > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> > LVDS.
> >
> > However, routing of these lanes are controlled by SEL, OE GPIO pins.
> > So at a time we can access only single bridge.
> >
> > >
> > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > > > >
> > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > > > port 2 in the DSI host node, and trying to attach the respective
> > > > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > > > based on the HDMI-INT.
> > > >
> > > > I think more appropriate would be to share the same port, but provide
> > > > two endpoints inside this port - we have two hardware sharing the same
> > > > physical port.
> > >
> > > That sounds like the correct DT description to me.
> > >
> > > > > Can it be possible to do bridge attachment at runtime? something like
> > > > > a bridge hotplug event? or any other possible solutions?
> > > > >
> > > > > Any suggestions?
> > > >
> > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > > > and some other reasons. (un|re|)plugging should be performed of course
> > > > when pipeline is off (connector disconnected). I am not sure about
> > > > bridges added to bridge chain - you need to inspect all opses to ensure
> > > > it can be done safely.
> > > >
> > > > And the main issue: Daniel does not like it :)
> > >
> > > Neither do I :-) Could it be handled with two DRM connectors that are
> > > mutually exclusive ?
> >
> > How about adding lvds-connector, hdmi-connector on the pipeline and
> > select them based on the switch SEL GPIO? does it make sense to do
> > this implementation via display-connector.c
>
> I have somehow managed to make runtime switching possible between LVDS
> and HDMI with the help of DRM bridges.
>
>                                                   | => ADV7535    =>
> HDMI-A Connector
> DSI Host => display-switch => |
>                                                   |=> SN65DSI83 => Panel-Simple
>
> display-switch here is a bridge driver that can switch or attach the
> downstream bridge flow based on HDMI HPD here. One potential problem
> is that when we switch from LVDS to HDMI Out the HDMI Out is displayed
> with the resolution that LVDS has and it is unable to display higher
> HDMI resolutions even though it supports it. Does anyone aware of
> changing the resolution at runtime, please let me know?
>
> Technically, the display-switch hardware does available in various forms
> 1. MIPI Switch PI3WVR626
> 2. Conventional Mux Switch
> 3. Converter bridge DSI to LVDS/HDMI (from Lontium).
>
> Overall I believe this can be a potential possible feature and good to
> support on Mainline as the hardware is intended to design for it.
>
> Any thoughts on this please let me know?

I wonder if it would be possible to trigger a hot plug event similar
to what is done when an HDMI cable is inserted/disconnected.

If one switches, force a disconnect event, then triggle the connection
event to force the video system to rescan/attach. I am not sure how to
go about implementing such a thing, but that's my first thought

adam
>
> Thanks,
> Jagan.

Re: DSI Bridge switching

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 6260 bytes --]

On Wed, Mar 09, 2022 at 06:45:10PM -0600, Adam Ford wrote:
> On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> >  or a Hi All,
> >
> > On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > Hi Laurent,
> > >
> > > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> > > <laurent.pinchart@ideasonboard.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > > Hi,
> > > > >
> > > > > Removed my invalid email (I will update files next week).
> > > > >
> > > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > > > >
> > > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > > > can use only one bridge at a time as host DSI support single out port.
> > > > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > > > load them static.
> > > > > >
> > > > > > But, one of the use cases is to support both of them in single dts, and
> > > > > > - Turn On LVDS (default)
> > > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > > >
> > > > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > > > isolation of pins?
> > > >
> > > > It may be in the category of "you shouldn't do this, but it actually
> > > > works". I've seen the same being done with two CSI-2 camera sensors
> > > > connected to the same receiver, with one of them being held in reset at
> > > > all times.
> > >
> > > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> > > input data lanes and 1 clock lane from SoC and produces 4 data lanes
> > > and 2 clock lanes and from switch output 2 lanes and 1 clock are
> > > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> > > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> > > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> > > LVDS.
> > >
> > > However, routing of these lanes are controlled by SEL, OE GPIO pins.
> > > So at a time we can access only single bridge.
> > >
> > > >
> > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > > > > >
> > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > > > > port 2 in the DSI host node, and trying to attach the respective
> > > > > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > > > > based on the HDMI-INT.
> > > > >
> > > > > I think more appropriate would be to share the same port, but provide
> > > > > two endpoints inside this port - we have two hardware sharing the same
> > > > > physical port.
> > > >
> > > > That sounds like the correct DT description to me.
> > > >
> > > > > > Can it be possible to do bridge attachment at runtime? something like
> > > > > > a bridge hotplug event? or any other possible solutions?
> > > > > >
> > > > > > Any suggestions?
> > > > >
> > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > > > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > > > > and some other reasons. (un|re|)plugging should be performed of course
> > > > > when pipeline is off (connector disconnected). I am not sure about
> > > > > bridges added to bridge chain - you need to inspect all opses to ensure
> > > > > it can be done safely.
> > > > >
> > > > > And the main issue: Daniel does not like it :)
> > > >
> > > > Neither do I :-) Could it be handled with two DRM connectors that are
> > > > mutually exclusive ?
> > >
> > > How about adding lvds-connector, hdmi-connector on the pipeline and
> > > select them based on the switch SEL GPIO? does it make sense to do
> > > this implementation via display-connector.c
> >
> > I have somehow managed to make runtime switching possible between LVDS
> > and HDMI with the help of DRM bridges.
> >
> >                                                   | => ADV7535    =>
> > HDMI-A Connector
> > DSI Host => display-switch => |
> >                                                   |=> SN65DSI83 => Panel-Simple
> >
> > display-switch here is a bridge driver that can switch or attach the
> > downstream bridge flow based on HDMI HPD here. One potential problem
> > is that when we switch from LVDS to HDMI Out the HDMI Out is displayed
> > with the resolution that LVDS has and it is unable to display higher
> > HDMI resolutions even though it supports it. Does anyone aware of
> > changing the resolution at runtime, please let me know?
> >
> > Technically, the display-switch hardware does available in various forms
> > 1. MIPI Switch PI3WVR626
> > 2. Conventional Mux Switch
> > 3. Converter bridge DSI to LVDS/HDMI (from Lontium).
> >
> > Overall I believe this can be a potential possible feature and good to
> > support on Mainline as the hardware is intended to design for it.
> >
> > Any thoughts on this please let me know?
> 
> I wonder if it would be possible to trigger a hot plug event similar
> to what is done when an HDMI cable is inserted/disconnected.
> 
> If one switches, force a disconnect event, then triggle the connection
> event to force the video system to rescan/attach. I am not sure how to
> go about implementing such a thing, but that's my first thought

Nothing prevents the DRM Master to just ignore the hotplug event though :)
Kodi does that for example.

I think we could simply create two connectors, one for LVDS, one for
HDMI, with atomic_check making sure only one of them is enabled at the
same time?

The one thing that would make it difficult is that we're changing the
bridge list to a tree. For example, in such a case, what should
drm_bridge_get_next_bridge return? This will obviously depend on the
state, but it's used in context were we don't have a state (such as
drm_bridge_connector_init).

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: DSI Bridge switching

[Jagan Teki]

On Thu, Mar 10, 2022 at 6:15 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> >  or a Hi All,
> >
> > On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > Hi Laurent,
> > >
> > > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> > > <laurent.pinchart@ideasonboard.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > > Hi,
> > > > >
> > > > > Removed my invalid email (I will update files next week).
> > > > >
> > > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > > > >
> > > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > > > can use only one bridge at a time as host DSI support single out port.
> > > > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > > > load them static.
> > > > > >
> > > > > > But, one of the use cases is to support both of them in single dts, and
> > > > > > - Turn On LVDS (default)
> > > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > > >
> > > > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > > > isolation of pins?
> > > >
> > > > It may be in the category of "you shouldn't do this, but it actually
> > > > works". I've seen the same being done with two CSI-2 camera sensors
> > > > connected to the same receiver, with one of them being held in reset at
> > > > all times.
> > >
> > > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> > > input data lanes and 1 clock lane from SoC and produces 4 data lanes
> > > and 2 clock lanes and from switch output 2 lanes and 1 clock are
> > > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> > > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> > > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> > > LVDS.
> > >
> > > However, routing of these lanes are controlled by SEL, OE GPIO pins.
> > > So at a time we can access only single bridge.
> > >
> > > >
> > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > > > > >
> > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > > > > port 2 in the DSI host node, and trying to attach the respective
> > > > > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > > > > based on the HDMI-INT.
> > > > >
> > > > > I think more appropriate would be to share the same port, but provide
> > > > > two endpoints inside this port - we have two hardware sharing the same
> > > > > physical port.
> > > >
> > > > That sounds like the correct DT description to me.
> > > >
> > > > > > Can it be possible to do bridge attachment at runtime? something like
> > > > > > a bridge hotplug event? or any other possible solutions?
> > > > > >
> > > > > > Any suggestions?
> > > > >
> > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > > > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > > > > and some other reasons. (un|re|)plugging should be performed of course
> > > > > when pipeline is off (connector disconnected). I am not sure about
> > > > > bridges added to bridge chain - you need to inspect all opses to ensure
> > > > > it can be done safely.
> > > > >
> > > > > And the main issue: Daniel does not like it :)
> > > >
> > > > Neither do I :-) Could it be handled with two DRM connectors that are
> > > > mutually exclusive ?
> > >
> > > How about adding lvds-connector, hdmi-connector on the pipeline and
> > > select them based on the switch SEL GPIO? does it make sense to do
> > > this implementation via display-connector.c
> >
> > I have somehow managed to make runtime switching possible between LVDS
> > and HDMI with the help of DRM bridges.
> >
> >                                                   | => ADV7535    =>
> > HDMI-A Connector
> > DSI Host => display-switch => |
> >                                                   |=> SN65DSI83 => Panel-Simple
> >
> > display-switch here is a bridge driver that can switch or attach the
> > downstream bridge flow based on HDMI HPD here. One potential problem
> > is that when we switch from LVDS to HDMI Out the HDMI Out is displayed
> > with the resolution that LVDS has and it is unable to display higher
> > HDMI resolutions even though it supports it. Does anyone aware of
> > changing the resolution at runtime, please let me know?
> >
> > Technically, the display-switch hardware does available in various forms
> > 1. MIPI Switch PI3WVR626
> > 2. Conventional Mux Switch
> > 3. Converter bridge DSI to LVDS/HDMI (from Lontium).
> >
> > Overall I believe this can be a potential possible feature and good to
> > support on Mainline as the hardware is intended to design for it.
> >
> > Any thoughts on this please let me know?
>
> I wonder if it would be possible to trigger a hot plug event similar
> to what is done when an HDMI cable is inserted/disconnected.
>
> If one switches, force a disconnect event, then triggle the connection
> event to force the video system to rescan/attach. I am not sure how to
> go about implementing such a thing, but that's my first thought

HDP on the connector can be useful in order to switch the displays
like 1 and 2 cases listed above. However, that is indeed a difficult
task for the pipline establishment as switch selection has to be done
before the output bridge and after the host bridge - This is one of
the reasons I've tried the implementation in the form via
display-connector. One more important accept here is the like
bridge-selection in above case 3 has dedicated interrupt gpio to route
the video data to LVDS or HDMI which is not related to HDMI-HPD.

Thanks,
Jagan.

Re: DSI Bridge switching

[Jagan Teki]

On Thu, Mar 10, 2022 at 4:05 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Wed, Mar 09, 2022 at 06:45:10PM -0600, Adam Ford wrote:
> > On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > >  or a Hi All,
> > >
> > > On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > Hi Laurent,
> > > >
> > > > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> > > > <laurent.pinchart@ideasonboard.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Removed my invalid email (I will update files next week).
> > > > > >
> > > > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > > > > >
> > > > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > > > > can use only one bridge at a time as host DSI support single out port.
> > > > > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > > > > load them static.
> > > > > > >
> > > > > > > But, one of the use cases is to support both of them in single dts, and
> > > > > > > - Turn On LVDS (default)
> > > > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > > > >
> > > > > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > > > > isolation of pins?
> > > > >
> > > > > It may be in the category of "you shouldn't do this, but it actually
> > > > > works". I've seen the same being done with two CSI-2 camera sensors
> > > > > connected to the same receiver, with one of them being held in reset at
> > > > > all times.
> > > >
> > > > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> > > > input data lanes and 1 clock lane from SoC and produces 4 data lanes
> > > > and 2 clock lanes and from switch output 2 lanes and 1 clock are
> > > > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> > > > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> > > > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> > > > LVDS.
> > > >
> > > > However, routing of these lanes are controlled by SEL, OE GPIO pins.
> > > > So at a time we can access only single bridge.
> > > >
> > > > >
> > > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > > > > > >
> > > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > > > > > port 2 in the DSI host node, and trying to attach the respective
> > > > > > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > > > > > based on the HDMI-INT.
> > > > > >
> > > > > > I think more appropriate would be to share the same port, but provide
> > > > > > two endpoints inside this port - we have two hardware sharing the same
> > > > > > physical port.
> > > > >
> > > > > That sounds like the correct DT description to me.
> > > > >
> > > > > > > Can it be possible to do bridge attachment at runtime? something like
> > > > > > > a bridge hotplug event? or any other possible solutions?
> > > > > > >
> > > > > > > Any suggestions?
> > > > > >
> > > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > > > > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > > > > > and some other reasons. (un|re|)plugging should be performed of course
> > > > > > when pipeline is off (connector disconnected). I am not sure about
> > > > > > bridges added to bridge chain - you need to inspect all opses to ensure
> > > > > > it can be done safely.
> > > > > >
> > > > > > And the main issue: Daniel does not like it :)
> > > > >
> > > > > Neither do I :-) Could it be handled with two DRM connectors that are
> > > > > mutually exclusive ?
> > > >
> > > > How about adding lvds-connector, hdmi-connector on the pipeline and
> > > > select them based on the switch SEL GPIO? does it make sense to do
> > > > this implementation via display-connector.c
> > >
> > > I have somehow managed to make runtime switching possible between LVDS
> > > and HDMI with the help of DRM bridges.
> > >
> > >                                                   | => ADV7535    =>
> > > HDMI-A Connector
> > > DSI Host => display-switch => |
> > >                                                   |=> SN65DSI83 => Panel-Simple
> > >
> > > display-switch here is a bridge driver that can switch or attach the
> > > downstream bridge flow based on HDMI HPD here. One potential problem
> > > is that when we switch from LVDS to HDMI Out the HDMI Out is displayed
> > > with the resolution that LVDS has and it is unable to display higher
> > > HDMI resolutions even though it supports it. Does anyone aware of
> > > changing the resolution at runtime, please let me know?
> > >
> > > Technically, the display-switch hardware does available in various forms
> > > 1. MIPI Switch PI3WVR626
> > > 2. Conventional Mux Switch
> > > 3. Converter bridge DSI to LVDS/HDMI (from Lontium).
> > >
> > > Overall I believe this can be a potential possible feature and good to
> > > support on Mainline as the hardware is intended to design for it.
> > >
> > > Any thoughts on this please let me know?
> >
> > I wonder if it would be possible to trigger a hot plug event similar
> > to what is done when an HDMI cable is inserted/disconnected.
> >
> > If one switches, force a disconnect event, then triggle the connection
> > event to force the video system to rescan/attach. I am not sure how to
> > go about implementing such a thing, but that's my first thought
>
> Nothing prevents the DRM Master to just ignore the hotplug event though :)
> Kodi does that for example.

Does it mean the DRM master unlocks the kodi if we switch the display?
 In my use-case QT is holding the DRM master so
drm_master_internal_acquire returns 0 in drm_fb_helper_hotplug_event
so it indeed not able to switch. But for non-qt and normal DRM console
applications I can see drm_fb_helper_hotplug_event return properly in
order to do the proper switching.

>
> I think we could simply create two connectors, one for LVDS, one for
> HDMI, with atomic_check making sure only one of them is enabled at the
> same time?

How can we create two connectors at the same time? You mean try to
attach LVDS and HDMI bridge one after another in display-switch
attach. does it create two different bridge lists?

                                                               sndsi83
=> panel-simple
mxsfb => nwl-dsi =>  display-switch =>
                                                               adv7511
=> display-connector

Thanks,
Jagan.

Re: DSI Bridge switching

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 7544 bytes --]

On Tue, Mar 29, 2022 at 07:39:21PM +0530, Jagan Teki wrote:
> On Thu, Mar 10, 2022 at 4:05 PM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > On Wed, Mar 09, 2022 at 06:45:10PM -0600, Adam Ford wrote:
> > > On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > >  or a Hi All,
> > > >
> > > > On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > >
> > > > > Hi Laurent,
> > > > >
> > > > > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> > > > > <laurent.pinchart@ideasonboard.com> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Removed my invalid email (I will update files next week).
> > > > > > >
> > > > > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > > > > > >
> > > > > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > > > > > can use only one bridge at a time as host DSI support single out port.
> > > > > > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > > > > > load them static.
> > > > > > > >
> > > > > > > > But, one of the use cases is to support both of them in single dts, and
> > > > > > > > - Turn On LVDS (default)
> > > > > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > > > > >
> > > > > > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > > > > > isolation of pins?
> > > > > >
> > > > > > It may be in the category of "you shouldn't do this, but it actually
> > > > > > works". I've seen the same being done with two CSI-2 camera sensors
> > > > > > connected to the same receiver, with one of them being held in reset at
> > > > > > all times.
> > > > >
> > > > > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> > > > > input data lanes and 1 clock lane from SoC and produces 4 data lanes
> > > > > and 2 clock lanes and from switch output 2 lanes and 1 clock are
> > > > > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> > > > > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> > > > > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> > > > > LVDS.
> > > > >
> > > > > However, routing of these lanes are controlled by SEL, OE GPIO pins.
> > > > > So at a time we can access only single bridge.
> > > > >
> > > > > >
> > > > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > > > > > > >
> > > > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > > > > > > port 2 in the DSI host node, and trying to attach the respective
> > > > > > > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > > > > > > based on the HDMI-INT.
> > > > > > >
> > > > > > > I think more appropriate would be to share the same port, but provide
> > > > > > > two endpoints inside this port - we have two hardware sharing the same
> > > > > > > physical port.
> > > > > >
> > > > > > That sounds like the correct DT description to me.
> > > > > >
> > > > > > > > Can it be possible to do bridge attachment at runtime? something like
> > > > > > > > a bridge hotplug event? or any other possible solutions?
> > > > > > > >
> > > > > > > > Any suggestions?
> > > > > > >
> > > > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > > > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > > > > > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > > > > > > and some other reasons. (un|re|)plugging should be performed of course
> > > > > > > when pipeline is off (connector disconnected). I am not sure about
> > > > > > > bridges added to bridge chain - you need to inspect all opses to ensure
> > > > > > > it can be done safely.
> > > > > > >
> > > > > > > And the main issue: Daniel does not like it :)
> > > > > >
> > > > > > Neither do I :-) Could it be handled with two DRM connectors that are
> > > > > > mutually exclusive ?
> > > > >
> > > > > How about adding lvds-connector, hdmi-connector on the pipeline and
> > > > > select them based on the switch SEL GPIO? does it make sense to do
> > > > > this implementation via display-connector.c
> > > >
> > > > I have somehow managed to make runtime switching possible between LVDS
> > > > and HDMI with the help of DRM bridges.
> > > >
> > > >                                                   | => ADV7535    =>
> > > > HDMI-A Connector
> > > > DSI Host => display-switch => |
> > > >                                                   |=> SN65DSI83 => Panel-Simple
> > > >
> > > > display-switch here is a bridge driver that can switch or attach the
> > > > downstream bridge flow based on HDMI HPD here. One potential problem
> > > > is that when we switch from LVDS to HDMI Out the HDMI Out is displayed
> > > > with the resolution that LVDS has and it is unable to display higher
> > > > HDMI resolutions even though it supports it. Does anyone aware of
> > > > changing the resolution at runtime, please let me know?
> > > >
> > > > Technically, the display-switch hardware does available in various forms
> > > > 1. MIPI Switch PI3WVR626
> > > > 2. Conventional Mux Switch
> > > > 3. Converter bridge DSI to LVDS/HDMI (from Lontium).
> > > >
> > > > Overall I believe this can be a potential possible feature and good to
> > > > support on Mainline as the hardware is intended to design for it.
> > > >
> > > > Any thoughts on this please let me know?
> > >
> > > I wonder if it would be possible to trigger a hot plug event similar
> > > to what is done when an HDMI cable is inserted/disconnected.
> > >
> > > If one switches, force a disconnect event, then triggle the connection
> > > event to force the video system to rescan/attach. I am not sure how to
> > > go about implementing such a thing, but that's my first thought
> >
> > Nothing prevents the DRM Master to just ignore the hotplug event though :)
> > Kodi does that for example.
> 
> Does it mean the DRM master unlocks the kodi if we switch the display?

What do you mean by "the DRM master unlocks the Kodi"? Kodi is the DRM
master in that case.

> In my use-case QT is holding the DRM master so
> drm_master_internal_acquire returns 0 in drm_fb_helper_hotplug_event
> so it indeed not able to switch. But for non-qt and normal DRM console
> applications I can see drm_fb_helper_hotplug_event return properly in
> order to do the proper switching.

I don't see what QT has to do with it, but like I said, nothing requires
the DRM master to just ignore that hotplug event. So whatever you do,
you can't rely on the master reacting to the hotplug event.

> > I think we could simply create two connectors, one for LVDS, one for
> > HDMI, with atomic_check making sure only one of them is enabled at the
> > same time?
> 
> How can we create two connectors at the same time? You mean try to
> attach LVDS and HDMI bridge one after another in display-switch
> attach. does it create two different bridge lists?

Not two lists, but the bridge list would become a tree yes

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: DSI Bridge switching

[Jagan Teki]

On Wed, Mar 30, 2022 at 2:20 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Tue, Mar 29, 2022 at 07:39:21PM +0530, Jagan Teki wrote:
> > On Thu, Mar 10, 2022 at 4:05 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > >
> > > On Wed, Mar 09, 2022 at 06:45:10PM -0600, Adam Ford wrote:
> > > > On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > >
> > > > >  or a Hi All,
> > > > >
> > > > > On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > > >
> > > > > > Hi Laurent,
> > > > > >
> > > > > > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> > > > > > <laurent.pinchart@ideasonboard.com> wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Removed my invalid email (I will update files next week).
> > > > > > > >
> > > > > > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > > > > > > >
> > > > > > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > > > > > > can use only one bridge at a time as host DSI support single out port.
> > > > > > > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > > > > > > load them static.
> > > > > > > > >
> > > > > > > > > But, one of the use cases is to support both of them in single dts, and
> > > > > > > > > - Turn On LVDS (default)
> > > > > > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > > > > > >
> > > > > > > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > > > > > > isolation of pins?
> > > > > > >
> > > > > > > It may be in the category of "you shouldn't do this, but it actually
> > > > > > > works". I've seen the same being done with two CSI-2 camera sensors
> > > > > > > connected to the same receiver, with one of them being held in reset at
> > > > > > > all times.
> > > > > >
> > > > > > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> > > > > > input data lanes and 1 clock lane from SoC and produces 4 data lanes
> > > > > > and 2 clock lanes and from switch output 2 lanes and 1 clock are
> > > > > > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> > > > > > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> > > > > > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> > > > > > LVDS.
> > > > > >
> > > > > > However, routing of these lanes are controlled by SEL, OE GPIO pins.
> > > > > > So at a time we can access only single bridge.
> > > > > >
> > > > > > >
> > > > > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > > > > > > > >
> > > > > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > > > > > > > port 2 in the DSI host node, and trying to attach the respective
> > > > > > > > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > > > > > > > based on the HDMI-INT.
> > > > > > > >
> > > > > > > > I think more appropriate would be to share the same port, but provide
> > > > > > > > two endpoints inside this port - we have two hardware sharing the same
> > > > > > > > physical port.
> > > > > > >
> > > > > > > That sounds like the correct DT description to me.
> > > > > > >
> > > > > > > > > Can it be possible to do bridge attachment at runtime? something like
> > > > > > > > > a bridge hotplug event? or any other possible solutions?
> > > > > > > > >
> > > > > > > > > Any suggestions?
> > > > > > > >
> > > > > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > > > > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > > > > > > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > > > > > > > and some other reasons. (un|re|)plugging should be performed of course
> > > > > > > > when pipeline is off (connector disconnected). I am not sure about
> > > > > > > > bridges added to bridge chain - you need to inspect all opses to ensure
> > > > > > > > it can be done safely.
> > > > > > > >
> > > > > > > > And the main issue: Daniel does not like it :)
> > > > > > >
> > > > > > > Neither do I :-) Could it be handled with two DRM connectors that are
> > > > > > > mutually exclusive ?
> > > > > >
> > > > > > How about adding lvds-connector, hdmi-connector on the pipeline and
> > > > > > select them based on the switch SEL GPIO? does it make sense to do
> > > > > > this implementation via display-connector.c
> > > > >
> > > > > I have somehow managed to make runtime switching possible between LVDS
> > > > > and HDMI with the help of DRM bridges.
> > > > >
> > > > >                                                   | => ADV7535    =>
> > > > > HDMI-A Connector
> > > > > DSI Host => display-switch => |
> > > > >                                                   |=> SN65DSI83 => Panel-Simple
> > > > >
> > > > > display-switch here is a bridge driver that can switch or attach the
> > > > > downstream bridge flow based on HDMI HPD here. One potential problem
> > > > > is that when we switch from LVDS to HDMI Out the HDMI Out is displayed
> > > > > with the resolution that LVDS has and it is unable to display higher
> > > > > HDMI resolutions even though it supports it. Does anyone aware of
> > > > > changing the resolution at runtime, please let me know?
> > > > >
> > > > > Technically, the display-switch hardware does available in various forms
> > > > > 1. MIPI Switch PI3WVR626
> > > > > 2. Conventional Mux Switch
> > > > > 3. Converter bridge DSI to LVDS/HDMI (from Lontium).
> > > > >
> > > > > Overall I believe this can be a potential possible feature and good to
> > > > > support on Mainline as the hardware is intended to design for it.
> > > > >
> > > > > Any thoughts on this please let me know?
> > > >
> > > > I wonder if it would be possible to trigger a hot plug event similar
> > > > to what is done when an HDMI cable is inserted/disconnected.
> > > >
> > > > If one switches, force a disconnect event, then triggle the connection
> > > > event to force the video system to rescan/attach. I am not sure how to
> > > > go about implementing such a thing, but that's my first thought
> > >
> > > Nothing prevents the DRM Master to just ignore the hotplug event though :)
> > > Kodi does that for example.
> >
> > Does it mean the DRM master unlocks the kodi if we switch the display?
>
> What do you mean by "the DRM master unlocks the Kodi"? Kodi is the DRM
> master in that case.

The QT apps that I'm running seem to hold the master
(drm_master_internal_acquire returns 0) so, hotplug event is not
happing. Does Kodi unlock the master like drm_master_internal_acquire
returns 1 so that hotplug event happing?

>
> > In my use-case QT is holding the DRM master so
> > drm_master_internal_acquire returns 0 in drm_fb_helper_hotplug_event
> > so it indeed not able to switch. But for non-qt and normal DRM console
> > applications I can see drm_fb_helper_hotplug_event return properly in
> > order to do the proper switching.
>
> I don't see what QT has to do with it, but like I said, nothing requires
> the DRM master to just ignore that hotplug event. So whatever you do,
> you can't rely on the master reacting to the hotplug event.

This is what I thought, but with

QT app,
I can see drm_master_internal_acquire returns 0 - so
drm_fb_helper_hotplug_event returns early, so hotplug is breaking.

non-QT (console)
I can see drm_master_internal_acquire returns 1 - so
drm_fb_helper_hotplug_event done smoothly and switched to another
display.

Do drm applications (like QT) have any control over DRM master
acquisition via some IOCTL or any other mechanism from userspace? if
yes, maybe my QT apps are doing that.

>
> > > I think we could simply create two connectors, one for LVDS, one for
> > > HDMI, with atomic_check making sure only one of them is enabled at the
> > > same time?
> >
> > How can we create two connectors at the same time? You mean try to
> > attach LVDS and HDMI bridge one after another in display-switch
> > attach. does it create two different bridge lists?
>
> Not two lists, but the bridge list would become a tree yes

Okay. Just to clarify. The connectors are going to create at the end
of the bridge list (in my case - panel-bridge for LVDS and adv7511 for
HDMI) and connectors will create during the bridge attachment. I'm
attaching the bridge during hotplug so only one connector create at a
time.

Thanks,
Jagan.

Re: DSI Bridge switching

[Jagan Teki]

Hi Maxime,

On Thu, Mar 10, 2022 at 4:05 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Wed, Mar 09, 2022 at 06:45:10PM -0600, Adam Ford wrote:
> > On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > >  or a Hi All,
> > >
> > > On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > Hi Laurent,
> > > >
> > > > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> > > > <laurent.pinchart@ideasonboard.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Removed my invalid email (I will update files next week).
> > > > > >
> > > > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I think this seems to be a known use case for industrial these days with i.mx8m.
> > > > > > >
> > > > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we
> > > > > > > can use only one bridge at a time as host DSI support single out port.
> > > > > > > So we can have two separate device tree files for LVDS and HDMI and
> > > > > > > load them static.
> > > > > > >
> > > > > > > But, one of the use cases is to support both of them in single dts, and
> > > > > > > - Turn On LVDS (default)
> > > > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > > > >
> > > > > > Are you sure it will work from hardware PoV? Do you have some demuxer?
> > > > > > isolation of pins?
> > > > >
> > > > > It may be in the category of "you shouldn't do this, but it actually
> > > > > works". I've seen the same being done with two CSI-2 camera sensors
> > > > > connected to the same receiver, with one of them being held in reset at
> > > > > all times.
> > > >
> > > > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> > > > input data lanes and 1 clock lane from SoC and produces 4 data lanes
> > > > and 2 clock lanes and from switch output 2 lanes and 1 clock are
> > > > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> > > > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> > > > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> > > > LVDS.
> > > >
> > > > However, routing of these lanes are controlled by SEL, OE GPIO pins.
> > > > So at a time we can access only single bridge.
> > > >
> > > > >
> > > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design.
> > > > > > >
> > > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on
> > > > > > > port 2 in the DSI host node, and trying to attach the respective
> > > > > > > bridge based on HDMI-INT like repeating the bridge attachment cycle
> > > > > > > based on the HDMI-INT.
> > > > > >
> > > > > > I think more appropriate would be to share the same port, but provide
> > > > > > two endpoints inside this port - we have two hardware sharing the same
> > > > > > physical port.
> > > > >
> > > > > That sounds like the correct DT description to me.
> > > > >
> > > > > > > Can it be possible to do bridge attachment at runtime? something like
> > > > > > > a bridge hotplug event? or any other possible solutions?
> > > > > > >
> > > > > > > Any suggestions?
> > > > > >
> > > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > > > > 'unplugged' from exynos_drm, but they do not use bridge chain for this
> > > > > > and some other reasons. (un|re|)plugging should be performed of course
> > > > > > when pipeline is off (connector disconnected). I am not sure about
> > > > > > bridges added to bridge chain - you need to inspect all opses to ensure
> > > > > > it can be done safely.
> > > > > >
> > > > > > And the main issue: Daniel does not like it :)
> > > > >
> > > > > Neither do I :-) Could it be handled with two DRM connectors that are
> > > > > mutually exclusive ?
> > > >
> > > > How about adding lvds-connector, hdmi-connector on the pipeline and
> > > > select them based on the switch SEL GPIO? does it make sense to do
> > > > this implementation via display-connector.c
> > >
> > > I have somehow managed to make runtime switching possible between LVDS
> > > and HDMI with the help of DRM bridges.
> > >
> > >                                                   | => ADV7535    =>
> > > HDMI-A Connector
> > > DSI Host => display-switch => |
> > >                                                   |=> SN65DSI83 => Panel-Simple
> > >
> > > display-switch here is a bridge driver that can switch or attach the
> > > downstream bridge flow based on HDMI HPD here. One potential problem
> > > is that when we switch from LVDS to HDMI Out the HDMI Out is displayed
> > > with the resolution that LVDS has and it is unable to display higher
> > > HDMI resolutions even though it supports it. Does anyone aware of
> > > changing the resolution at runtime, please let me know?
> > >
> > > Technically, the display-switch hardware does available in various forms
> > > 1. MIPI Switch PI3WVR626
> > > 2. Conventional Mux Switch
> > > 3. Converter bridge DSI to LVDS/HDMI (from Lontium).
> > >
> > > Overall I believe this can be a potential possible feature and good to
> > > support on Mainline as the hardware is intended to design for it.
> > >
> > > Any thoughts on this please let me know?
> >
> > I wonder if it would be possible to trigger a hot plug event similar
> > to what is done when an HDMI cable is inserted/disconnected.
> >
> > If one switches, force a disconnect event, then triggle the connection
> > event to force the video system to rescan/attach. I am not sure how to
> > go about implementing such a thing, but that's my first thought
>
> Nothing prevents the DRM Master to just ignore the hotplug event though :)
> Kodi does that for example.
>
> I think we could simply create two connectors, one for LVDS, one for
> HDMI, with atomic_check making sure only one of them is enabled at the
> same time?
>
> The one thing that would make it difficult is that we're changing the
> bridge list to a tree. For example, in such a case, what should
> drm_bridge_get_next_bridge return? This will obviously depend on the
> state, but it's used in context were we don't have a state (such as
> drm_bridge_connector_init).

From display-switch bridge, we can have a tree of one bridge chain for
HDMI and another bridge chain for LVDS ended with respective
connectors but how to attach the respective down-stream bridges of the
tree and get the associated connector? does "state" in the above mean
to preserve each bridge chain path in order to get the proper
connector?

I tried to attach the down-stream bridge one after another in for loop
from display-switch. Both attached and last bridge in the loop get
enabled with LVDS-1 and HDMI-A-1 connectors are created but the last
bridge chain is tailed with the first, not like the tree - like
display-switch => lvds bridge => hdmi bridg.

Any suggestions?

Jagan.