DRM Master ignoring hotplug event during display switching (QT)

DRM Master ignoring hotplug event during display switching (QT)

[Jagan Teki]

Hi all,

I have implemented runtime display switching in the MIPI switch design
where LVDS and HDMI bridges are selected with the help of runtime
GPIO.

Initial discussion on the same can be found here,
https://www.spinics.net/lists/dri-devel/msg318524.html

The implementation has been done by creating each connector at
runtime. The default boot will create the LVDS connector and based on
the HDMI plug-in the ISR.

1. forcing the LVDS to disconnect
2. call drm_kms_helper_hotplug_event
3. detach the bridge chain
4. attach the new bridge chain (HDMI)
5. call drm_kms_helper_hotplug_event

do the reverse when we unplug the HDMI cable.

So, the bridge chains are attached and detached based on GPIO
Interrupt which is indeed identified based on the physical HDMIA
connector.

Pipeline for LVDS,
mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge

Pipeline for HDMI,
mxfsb => nwl-dsi => display-switch => adv7511 => display-connector

With this, implementation and I can able switch the displays with
default DRM (without specific DRM applications) where the LVDS is ON
by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
unplug the HDMI OFF/LVDS ON.

However, with QT5 I can see the DRM Master ignoring hotplug event by
returning 0 on drm_master_internal_acquire in
drm_fb_helper_hotplug_event. With this the hotplug returned early so
it cannot able to disconnect and connect the new switching connector.

Any help?

Thanks,
Jagan.

Re: DRM Master ignoring hotplug event during display switching (QT)

[Maxime Ripard]

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

On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> Hi all,
> 
> I have implemented runtime display switching in the MIPI switch design
> where LVDS and HDMI bridges are selected with the help of runtime
> GPIO.
> 
> Initial discussion on the same can be found here,
> https://www.spinics.net/lists/dri-devel/msg318524.html
> 
> The implementation has been done by creating each connector at
> runtime. The default boot will create the LVDS connector and based on
> the HDMI plug-in the ISR.
> 
> 1. forcing the LVDS to disconnect
> 2. call drm_kms_helper_hotplug_event
> 3. detach the bridge chain
> 4. attach the new bridge chain (HDMI)
> 5. call drm_kms_helper_hotplug_event
> 
> do the reverse when we unplug the HDMI cable.
> 
> So, the bridge chains are attached and detached based on GPIO
> Interrupt which is indeed identified based on the physical HDMIA
> connector.
> 
> Pipeline for LVDS,
> mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> 
> Pipeline for HDMI,
> mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> 
> With this, implementation and I can able switch the displays with
> default DRM (without specific DRM applications) where the LVDS is ON
> by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> unplug the HDMI OFF/LVDS ON.
> 
> However, with QT5 I can see the DRM Master ignoring hotplug event by
> returning 0 on drm_master_internal_acquire in
> drm_fb_helper_hotplug_event. With this the hotplug returned early so
> it cannot able to disconnect and connect the new switching connector.
> 
> Any help?

I'm not sure why you started another discussion with pretty much the
same content, but you can't rely on userspace handling the hotplug
event. You'll have to deal with the case where it just doesn't.

Maxime

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

Re: DRM Master ignoring hotplug event during display switching (QT)

[Jagan Teki]

On Wed, Mar 30, 2022 at 2:22 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > Hi all,
> >
> > I have implemented runtime display switching in the MIPI switch design
> > where LVDS and HDMI bridges are selected with the help of runtime
> > GPIO.
> >
> > Initial discussion on the same can be found here,
> > https://www.spinics.net/lists/dri-devel/msg318524.html
> >
> > The implementation has been done by creating each connector at
> > runtime. The default boot will create the LVDS connector and based on
> > the HDMI plug-in the ISR.
> >
> > 1. forcing the LVDS to disconnect
> > 2. call drm_kms_helper_hotplug_event
> > 3. detach the bridge chain
> > 4. attach the new bridge chain (HDMI)
> > 5. call drm_kms_helper_hotplug_event
> >
> > do the reverse when we unplug the HDMI cable.
> >
> > So, the bridge chains are attached and detached based on GPIO
> > Interrupt which is indeed identified based on the physical HDMIA
> > connector.
> >
> > Pipeline for LVDS,
> > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> >
> > Pipeline for HDMI,
> > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> >
> > With this, implementation and I can able switch the displays with
> > default DRM (without specific DRM applications) where the LVDS is ON
> > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > unplug the HDMI OFF/LVDS ON.
> >
> > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > returning 0 on drm_master_internal_acquire in
> > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > it cannot able to disconnect and connect the new switching connector.
> >
> > Any help?
>
> I'm not sure why you started another discussion with pretty much the
> same content, but you can't rely on userspace handling the hotplug
> event. You'll have to deal with the case where it just doesn't.

I've added clear details here - thought that it reaches more people.
Okay, I will continue on the old thread.

Jagan.

Re: DRM Master ignoring hotplug event during display switching (QT)

[Daniel Vetter]

On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > Hi all,
> > 
> > I have implemented runtime display switching in the MIPI switch design
> > where LVDS and HDMI bridges are selected with the help of runtime
> > GPIO.
> > 
> > Initial discussion on the same can be found here,
> > https://www.spinics.net/lists/dri-devel/msg318524.html
> > 
> > The implementation has been done by creating each connector at
> > runtime. The default boot will create the LVDS connector and based on
> > the HDMI plug-in the ISR.
> > 
> > 1. forcing the LVDS to disconnect
> > 2. call drm_kms_helper_hotplug_event
> > 3. detach the bridge chain
> > 4. attach the new bridge chain (HDMI)
> > 5. call drm_kms_helper_hotplug_event
> > 
> > do the reverse when we unplug the HDMI cable.
> > 
> > So, the bridge chains are attached and detached based on GPIO
> > Interrupt which is indeed identified based on the physical HDMIA
> > connector.
> > 
> > Pipeline for LVDS,
> > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> > 
> > Pipeline for HDMI,
> > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> > 
> > With this, implementation and I can able switch the displays with
> > default DRM (without specific DRM applications) where the LVDS is ON
> > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > unplug the HDMI OFF/LVDS ON.
> > 
> > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > returning 0 on drm_master_internal_acquire in
> > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > it cannot able to disconnect and connect the new switching connector.
> > 
> > Any help?
> 
> I'm not sure why you started another discussion with pretty much the
> same content, but you can't rely on userspace handling the hotplug
> event. You'll have to deal with the case where it just doesn't.

Well I missed the old thread, so I'm replying here.

You should not handle this at all from a hotplug.

The way kms works is roughly as follows:

1. hw output state changes
2. driver detects this (either through hpd interrupt or polling)
3. driver sends out hotplug uevent

That's it. Nothing else, no bridge rebinding, no link retaining is
required.

Then either userspace or fbcon emulation reacts to this hotplug event by
doing an atomic modeset, where it hopefully disables the old output and
re-enables the new output. Your atomic_check needs to validate that
everything is all right (i.e. not enabling both at the same time).

Note that if you change stuff underneath, then that tends to seriously
upset atomic users. Also you should try to continue supporting at least
page flips with the wrong config, compositors otherwise tend to crash.

This also means that if userspace doesn't handle hotplug events, then you
might end up with a black screen. That's ok. We try to avoid that when
it's practical (e.g. dp sst link retraining), but not when it's too hard
(dp mst hot-replug relies on userspace restoring everything).

Finally exchanging the bridge chain isn't supported, there's no locking
for that since it's assumed to be invariant over the lifetim of the
drm_device instance. The simplest way to make that happen right now is to
have 2 drm_encoder instances, one with the lvds bridge chain, the other
with the hdmi bridge chain, and select the right encoder/bridge chain
depending upon which output userspace picks.

Also ofc your atomic_check needs to make sure that they're not both
enabled at the same time :-)

I wouldn't try to make bridge chains exchangeable instead, that's
headaches - e.g. with dp mst we've also opted for a bunch of fake
drm_encoders to model that kind of switching.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: DRM Master ignoring hotplug event during display switching (QT)

[Jagan Teki]

On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > Hi all,
> > >
> > > I have implemented runtime display switching in the MIPI switch design
> > > where LVDS and HDMI bridges are selected with the help of runtime
> > > GPIO.
> > >
> > > Initial discussion on the same can be found here,
> > > https://www.spinics.net/lists/dri-devel/msg318524.html
> > >
> > > The implementation has been done by creating each connector at
> > > runtime. The default boot will create the LVDS connector and based on
> > > the HDMI plug-in the ISR.
> > >
> > > 1. forcing the LVDS to disconnect
> > > 2. call drm_kms_helper_hotplug_event
> > > 3. detach the bridge chain
> > > 4. attach the new bridge chain (HDMI)
> > > 5. call drm_kms_helper_hotplug_event
> > >
> > > do the reverse when we unplug the HDMI cable.
> > >
> > > So, the bridge chains are attached and detached based on GPIO
> > > Interrupt which is indeed identified based on the physical HDMIA
> > > connector.
> > >
> > > Pipeline for LVDS,
> > > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> > >
> > > Pipeline for HDMI,
> > > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> > >
> > > With this, implementation and I can able switch the displays with
> > > default DRM (without specific DRM applications) where the LVDS is ON
> > > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > > unplug the HDMI OFF/LVDS ON.
> > >
> > > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > > returning 0 on drm_master_internal_acquire in
> > > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > > it cannot able to disconnect and connect the new switching connector.
> > >
> > > Any help?
> >
> > I'm not sure why you started another discussion with pretty much the
> > same content, but you can't rely on userspace handling the hotplug
> > event. You'll have to deal with the case where it just doesn't.
>
> Well I missed the old thread, so I'm replying here.
>
> You should not handle this at all from a hotplug.

Just to be clear. ISR is handling bridge detach and attach management
and call hotplug not the hotplug don't know anything about bridges
here.

>
> The way kms works is roughly as follows:
>
> 1. hw output state changes
> 2. driver detects this (either through hpd interrupt or polling)
> 3. driver sends out hotplug uevent
>
> That's it. Nothing else, no bridge rebinding, no link retaining is
> required.
>
> Then either userspace or fbcon emulation reacts to this hotplug event by
> doing an atomic modeset, where it hopefully disables the old output and
> re-enables the new output. Your atomic_check needs to validate that
> everything is all right (i.e. not enabling both at the same time).

Does it mean the userspace knows when to disconnect and connect the
LVDS or HDMI? What if display-switch ISR will disconnect LVDS and
connect HDMI when HPD is On and connect LVDS and disconnect HDMI when
HDP is Off of-course it makes only one enable at a time.

>
> Note that if you change stuff underneath, then that tends to seriously
> upset atomic users. Also you should try to continue supporting at least
> page flips with the wrong config, compositors otherwise tend to crash.
>
> This also means that if userspace doesn't handle hotplug events, then you
> might end up with a black screen. That's ok. We try to avoid that when
> it's practical (e.g. dp sst link retraining), but not when it's too hard
> (dp mst hot-replug relies on userspace restoring everything).

This is what I'm not sure about it as normal FB testing without any
specific applications like QT - I can still see the switching works
well without any issues. However, QT applications seem to control the
hotplug by acquiring DRM master. is there any way from kernel side to
ignore those application control over hotplug so that I can switch
even the QT application as normal FB does? just to understand my
testing and flow?

>
> Finally exchanging the bridge chain isn't supported, there's no locking
> for that since it's assumed to be invariant over the lifetim of the
> drm_device instance. The simplest way to make that happen right now is to
> have 2 drm_encoder instances, one with the lvds bridge chain, the other
> with the hdmi bridge chain, and select the right encoder/bridge chain
> depending upon which output userspace picks.

Does it mean to initialize to encoder instances and start attaching
those to respective bridge pipelines?

>
> Also ofc your atomic_check needs to make sure that they're not both
> enabled at the same time :-)
>
> I wouldn't try to make bridge chains exchangeable instead, that's
> headaches - e.g. with dp mst we've also opted for a bunch of fake
> drm_encoders to model that kind of switching.

Can you link some references in the source tree for it to make a quick check?

Thanks,
Jagan.

Re: DRM Master ignoring hotplug event during display switching (QT)

[Daniel Vetter]

On Thu, Mar 31, 2022 at 12:14:31AM +0530, Jagan Teki wrote:
> On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > > Hi all,
> > > >
> > > > I have implemented runtime display switching in the MIPI switch design
> > > > where LVDS and HDMI bridges are selected with the help of runtime
> > > > GPIO.
> > > >
> > > > Initial discussion on the same can be found here,
> > > > https://www.spinics.net/lists/dri-devel/msg318524.html
> > > >
> > > > The implementation has been done by creating each connector at
> > > > runtime. The default boot will create the LVDS connector and based on
> > > > the HDMI plug-in the ISR.
> > > >
> > > > 1. forcing the LVDS to disconnect
> > > > 2. call drm_kms_helper_hotplug_event
> > > > 3. detach the bridge chain
> > > > 4. attach the new bridge chain (HDMI)
> > > > 5. call drm_kms_helper_hotplug_event
> > > >
> > > > do the reverse when we unplug the HDMI cable.
> > > >
> > > > So, the bridge chains are attached and detached based on GPIO
> > > > Interrupt which is indeed identified based on the physical HDMIA
> > > > connector.
> > > >
> > > > Pipeline for LVDS,
> > > > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> > > >
> > > > Pipeline for HDMI,
> > > > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> > > >
> > > > With this, implementation and I can able switch the displays with
> > > > default DRM (without specific DRM applications) where the LVDS is ON
> > > > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > > > unplug the HDMI OFF/LVDS ON.
> > > >
> > > > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > > > returning 0 on drm_master_internal_acquire in
> > > > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > > > it cannot able to disconnect and connect the new switching connector.
> > > >
> > > > Any help?
> > >
> > > I'm not sure why you started another discussion with pretty much the
> > > same content, but you can't rely on userspace handling the hotplug
> > > event. You'll have to deal with the case where it just doesn't.
> >
> > Well I missed the old thread, so I'm replying here.
> >
> > You should not handle this at all from a hotplug.
> 
> Just to be clear. ISR is handling bridge detach and attach management
> and call hotplug not the hotplug don't know anything about bridges
> here.
> 
> >
> > The way kms works is roughly as follows:
> >
> > 1. hw output state changes
> > 2. driver detects this (either through hpd interrupt or polling)
> > 3. driver sends out hotplug uevent
> >
> > That's it. Nothing else, no bridge rebinding, no link retaining is
> > required.
> >
> > Then either userspace or fbcon emulation reacts to this hotplug event by
> > doing an atomic modeset, where it hopefully disables the old output and
> > re-enables the new output. Your atomic_check needs to validate that
> > everything is all right (i.e. not enabling both at the same time).
> 
> Does it mean the userspace knows when to disconnect and connect the
> LVDS or HDMI? What if display-switch ISR will disconnect LVDS and
> connect HDMI when HPD is On and connect LVDS and disconnect HDMI when
> HDP is Off of-course it makes only one enable at a time.
> 
> >
> > Note that if you change stuff underneath, then that tends to seriously
> > upset atomic users. Also you should try to continue supporting at least
> > page flips with the wrong config, compositors otherwise tend to crash.
> >
> > This also means that if userspace doesn't handle hotplug events, then you
> > might end up with a black screen. That's ok. We try to avoid that when
> > it's practical (e.g. dp sst link retraining), but not when it's too hard
> > (dp mst hot-replug relies on userspace restoring everything).
> 
> This is what I'm not sure about it as normal FB testing without any
> specific applications like QT - I can still see the switching works
> well without any issues. However, QT applications seem to control the
> hotplug by acquiring DRM master. is there any way from kernel side to
> ignore those application control over hotplug so that I can switch
> even the QT application as normal FB does? just to understand my
> testing and flow?

No, that's not how kms works.

When fbcon is active, then fbcon takes over all responsibilities of a drm
master. Including reacting to hotplug events.

If your QT app directly uses kms, but doesn't handle hotplugs, then yes
nothing at all happens. But that's just a userspace bug, not a kernel bug,
and we really should _not_ work around random userspace issues like this
in the kernel.

Actually we cannot, because doing so would upset real kms compositors,
since the kernel doing funny stuff underneath it will at best confuse it.
And it some cases it resulted in crashes.

> 
> >
> > Finally exchanging the bridge chain isn't supported, there's no locking
> > for that since it's assumed to be invariant over the lifetim of the
> > drm_device instance. The simplest way to make that happen right now is to
> > have 2 drm_encoder instances, one with the lvds bridge chain, the other
> > with the hdmi bridge chain, and select the right encoder/bridge chain
> > depending upon which output userspace picks.
> 
> Does it mean to initialize to encoder instances and start attaching
> those to respective bridge pipelines?

I haven't checked, but I think it's not possible to change the bridge
chaining after drm_dev_register is called due to locking.

So doing bridge attach/detach from the hotplug handler is a no-go. The
bridges need to be set up at driver load.

Also with this design each bridge chain has its own drm_connector (HDMI
and LVDS, if I got you right). But that's just how bridges work.

> > Also ofc your atomic_check needs to make sure that they're not both
> > enabled at the same time :-)
> >
> > I wouldn't try to make bridge chains exchangeable instead, that's
> > headaches - e.g. with dp mst we've also opted for a bunch of fake
> > drm_encoders to model that kind of switching.
> 
> Can you link some references in the source tree for it to make a quick check?

See the atomic_best_encoder callback, doc link here:

https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=atomic_best_encoder#c.drm_connector_helper_funcs

Although thinking about this you should have only 1 encoder for each
drm_connector (if you go with separate connector for hdmi and lvds), and
in that case the atomic helpers will take care of everything for you. Well
except making sure that only one encoder of the two is enabled at the same
time.
-Daniel

> 
> Thanks,
> Jagan.

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

Re: DRM Master ignoring hotplug event during display switching (QT)

[Daniel Stone]

Hi,

On Wed, 30 Mar 2022 at 20:47, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Mar 31, 2022 at 12:14:31AM +0530, Jagan Teki wrote:
> > Does it mean the userspace knows when to disconnect and connect the
> > LVDS or HDMI? What if display-switch ISR will disconnect LVDS and
> > connect HDMI when HPD is On and connect LVDS and disconnect HDMI when
> > HDP is Off of-course it makes only one enable at a time.

Don't do that. :)

Be fully clear and explicit to userspace. Declare that there are
multiple connectors (one LVDS, one HDMI), with different backing
encoders as well. Declare their connection status appropriately, and
send hotplug events when it changes.

It is the responsibility of userspace to listen to these events, check
the status, and react accordingly. In the absence of userspace, fbcon
pretends to be userspace and tries to do the right thing.

> If your QT app directly uses kms, but doesn't handle hotplugs, then yes
> nothing at all happens. But that's just a userspace bug, not a kernel bug,
> and we really should _not_ work around random userspace issues like this
> in the kernel.
>
> Actually we cannot, because doing so would upset real kms compositors,
> since the kernel doing funny stuff underneath it will at best confuse it.
> And it some cases it resulted in crashes.

FWIW, this is not because userspace sucks and can't handle corner
cases; it's because hotplug is an unfixable race condition. The
correct way to handle this is eventual consistency; you make the
previous connections a zombie (allow them to continue even if they are
no longer alive), tell userspace that the connections have changed,
and trust that it will make the appropriate changes.

> > Does it mean to initialize to encoder instances and start attaching
> > those to respective bridge pipelines?
>
> I haven't checked, but I think it's not possible to change the bridge
> chaining after drm_dev_register is called due to locking.
>
> So doing bridge attach/detach from the hotplug handler is a no-go. The
> bridges need to be set up at driver load.
>
> Also with this design each bridge chain has its own drm_connector (HDMI
> and LVDS, if I got you right). But that's just how bridges work.

Yep.

> > Can you link some references in the source tree for it to make a quick check?
>
> See the atomic_best_encoder callback, doc link here:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=atomic_best_encoder#c.drm_connector_helper_funcs
>
> Although thinking about this you should have only 1 encoder for each
> drm_connector (if you go with separate connector for hdmi and lvds), and
> in that case the atomic helpers will take care of everything for you. Well
> except making sure that only one encoder of the two is enabled at the same
> time.

Yep again. But that's fine: declare one DRM connector for each
physical connector, only ever report one connector (and thus encoder)
connected at a time, and things will work.

Any userspace which tries to light up an output reported as
'disconnected' will expect that it will not work. Any userspace which
does not react to hotplug events cannot work with outputs which are
being hotplugged. And that's OK. You don't need to solve this with
elaborate workarounds in your drivers, you just need to give userspace
all the information it needs to make the right decisions, and then fix
it if it doesn't.

Cheers,
Daniel

Re: DRM Master ignoring hotplug event during display switching (QT)

[Jagan Teki]

Hi Daniel,

On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > Hi all,
> > >
> > > I have implemented runtime display switching in the MIPI switch design
> > > where LVDS and HDMI bridges are selected with the help of runtime
> > > GPIO.
> > >
> > > Initial discussion on the same can be found here,
> > > https://www.spinics.net/lists/dri-devel/msg318524.html
> > >
> > > The implementation has been done by creating each connector at
> > > runtime. The default boot will create the LVDS connector and based on
> > > the HDMI plug-in the ISR.
> > >
> > > 1. forcing the LVDS to disconnect
> > > 2. call drm_kms_helper_hotplug_event
> > > 3. detach the bridge chain
> > > 4. attach the new bridge chain (HDMI)
> > > 5. call drm_kms_helper_hotplug_event
> > >
> > > do the reverse when we unplug the HDMI cable.
> > >
> > > So, the bridge chains are attached and detached based on GPIO
> > > Interrupt which is indeed identified based on the physical HDMIA
> > > connector.
> > >
> > > Pipeline for LVDS,
> > > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> > >
> > > Pipeline for HDMI,
> > > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> > >
> > > With this, implementation and I can able switch the displays with
> > > default DRM (without specific DRM applications) where the LVDS is ON
> > > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > > unplug the HDMI OFF/LVDS ON.
> > >
> > > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > > returning 0 on drm_master_internal_acquire in
> > > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > > it cannot able to disconnect and connect the new switching connector.
> > >
> > > Any help?
> >
> > I'm not sure why you started another discussion with pretty much the
> > same content, but you can't rely on userspace handling the hotplug
> > event. You'll have to deal with the case where it just doesn't.
>
> Well I missed the old thread, so I'm replying here.
>
> You should not handle this at all from a hotplug.
>
> The way kms works is roughly as follows:
>
> 1. hw output state changes
> 2. driver detects this (either through hpd interrupt or polling)
> 3. driver sends out hotplug uevent
>
> That's it. Nothing else, no bridge rebinding, no link retaining is
> required.
>
> Then either userspace or fbcon emulation reacts to this hotplug event by
> doing an atomic modeset, where it hopefully disables the old output and
> re-enables the new output. Your atomic_check needs to validate that
> everything is all right (i.e. not enabling both at the same time).
>
> Note that if you change stuff underneath, then that tends to seriously
> upset atomic users. Also you should try to continue supporting at least
> page flips with the wrong config, compositors otherwise tend to crash.
>
> This also means that if userspace doesn't handle hotplug events, then you
> might end up with a black screen. That's ok. We try to avoid that when
> it's practical (e.g. dp sst link retraining), but not when it's too hard
> (dp mst hot-replug relies on userspace restoring everything).
>
> Finally exchanging the bridge chain isn't supported, there's no locking
> for that since it's assumed to be invariant over the lifetim of the
> drm_device instance. The simplest way to make that happen right now is to
> have 2 drm_encoder instances, one with the lvds bridge chain, the other
> with the hdmi bridge chain, and select the right encoder/bridge chain
> depending upon which output userspace picks.

I've created 2 instances of encoders. endpoint 0 for HDMI bridge chain
and endpoint 1 for LVDS bridge chain. Each bridge chain uses a
respective encoder instance in order to start attaching the bridge
like below.

1. find the bridge at endpoint 0
2. drm_bridge_attach(&mxsfb->encoder[0], mxsfb->bridge[0], NULL, 0)

and repeat for endpoint 1

The bridge chain established fine for endpoint 0 but returned -EBUSY
while the bridge chain attached for endpoint 1. looks like bridge->dev
is still being used in endpoint 0 even though we have a separate
bridge point from mxsfb.

Any thought on how to establish the dual bridge chain here?

Thanks,
Jagan.

Re: DRM Master ignoring hotplug event during display switching (QT)

[Daniel Vetter]

On Thu, 2 Jun 2022 at 17:43, Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> Hi Daniel,
>
> On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > > Hi all,
> > > >
> > > > I have implemented runtime display switching in the MIPI switch design
> > > > where LVDS and HDMI bridges are selected with the help of runtime
> > > > GPIO.
> > > >
> > > > Initial discussion on the same can be found here,
> > > > https://www.spinics.net/lists/dri-devel/msg318524.html
> > > >
> > > > The implementation has been done by creating each connector at
> > > > runtime. The default boot will create the LVDS connector and based on
> > > > the HDMI plug-in the ISR.
> > > >
> > > > 1. forcing the LVDS to disconnect
> > > > 2. call drm_kms_helper_hotplug_event
> > > > 3. detach the bridge chain
> > > > 4. attach the new bridge chain (HDMI)
> > > > 5. call drm_kms_helper_hotplug_event
> > > >
> > > > do the reverse when we unplug the HDMI cable.
> > > >
> > > > So, the bridge chains are attached and detached based on GPIO
> > > > Interrupt which is indeed identified based on the physical HDMIA
> > > > connector.
> > > >
> > > > Pipeline for LVDS,
> > > > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> > > >
> > > > Pipeline for HDMI,
> > > > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> > > >
> > > > With this, implementation and I can able switch the displays with
> > > > default DRM (without specific DRM applications) where the LVDS is ON
> > > > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > > > unplug the HDMI OFF/LVDS ON.
> > > >
> > > > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > > > returning 0 on drm_master_internal_acquire in
> > > > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > > > it cannot able to disconnect and connect the new switching connector.
> > > >
> > > > Any help?
> > >
> > > I'm not sure why you started another discussion with pretty much the
> > > same content, but you can't rely on userspace handling the hotplug
> > > event. You'll have to deal with the case where it just doesn't.
> >
> > Well I missed the old thread, so I'm replying here.
> >
> > You should not handle this at all from a hotplug.
> >
> > The way kms works is roughly as follows:
> >
> > 1. hw output state changes
> > 2. driver detects this (either through hpd interrupt or polling)
> > 3. driver sends out hotplug uevent
> >
> > That's it. Nothing else, no bridge rebinding, no link retaining is
> > required.
> >
> > Then either userspace or fbcon emulation reacts to this hotplug event by
> > doing an atomic modeset, where it hopefully disables the old output and
> > re-enables the new output. Your atomic_check needs to validate that
> > everything is all right (i.e. not enabling both at the same time).
> >
> > Note that if you change stuff underneath, then that tends to seriously
> > upset atomic users. Also you should try to continue supporting at least
> > page flips with the wrong config, compositors otherwise tend to crash.
> >
> > This also means that if userspace doesn't handle hotplug events, then you
> > might end up with a black screen. That's ok. We try to avoid that when
> > it's practical (e.g. dp sst link retraining), but not when it's too hard
> > (dp mst hot-replug relies on userspace restoring everything).
> >
> > Finally exchanging the bridge chain isn't supported, there's no locking
> > for that since it's assumed to be invariant over the lifetim of the
> > drm_device instance. The simplest way to make that happen right now is to
> > have 2 drm_encoder instances, one with the lvds bridge chain, the other
> > with the hdmi bridge chain, and select the right encoder/bridge chain
> > depending upon which output userspace picks.
>
> I've created 2 instances of encoders. endpoint 0 for HDMI bridge chain
> and endpoint 1 for LVDS bridge chain. Each bridge chain uses a
> respective encoder instance in order to start attaching the bridge
> like below.
>
> 1. find the bridge at endpoint 0
> 2. drm_bridge_attach(&mxsfb->encoder[0], mxsfb->bridge[0], NULL, 0)
>
> and repeat for endpoint 1
>
> The bridge chain established fine for endpoint 0 but returned -EBUSY
> while the bridge chain attached for endpoint 1. looks like bridge->dev
> is still being used in endpoint 0 even though we have a separate
> bridge point from mxsfb.
>
> Any thought on how to establish the dual bridge chain here?

Are you using 2 different struct drm_bridge for this? Reusing the same
drm_bridge for the 2nd encoder and endpoint is the only thing I can
come up with that would result in this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: DRM Master ignoring hotplug event during display switching (QT)

[Jagan Teki]

On Tue, Jun 7, 2022 at 8:04 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Thu, 2 Jun 2022 at 17:43, Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > Hi Daniel,
> >
> > On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > > > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > > > Hi all,
> > > > >
> > > > > I have implemented runtime display switching in the MIPI switch design
> > > > > where LVDS and HDMI bridges are selected with the help of runtime
> > > > > GPIO.
> > > > >
> > > > > Initial discussion on the same can be found here,
> > > > > https://www.spinics.net/lists/dri-devel/msg318524.html
> > > > >
> > > > > The implementation has been done by creating each connector at
> > > > > runtime. The default boot will create the LVDS connector and based on
> > > > > the HDMI plug-in the ISR.
> > > > >
> > > > > 1. forcing the LVDS to disconnect
> > > > > 2. call drm_kms_helper_hotplug_event
> > > > > 3. detach the bridge chain
> > > > > 4. attach the new bridge chain (HDMI)
> > > > > 5. call drm_kms_helper_hotplug_event
> > > > >
> > > > > do the reverse when we unplug the HDMI cable.
> > > > >
> > > > > So, the bridge chains are attached and detached based on GPIO
> > > > > Interrupt which is indeed identified based on the physical HDMIA
> > > > > connector.
> > > > >
> > > > > Pipeline for LVDS,
> > > > > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> > > > >
> > > > > Pipeline for HDMI,
> > > > > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> > > > >
> > > > > With this, implementation and I can able switch the displays with
> > > > > default DRM (without specific DRM applications) where the LVDS is ON
> > > > > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > > > > unplug the HDMI OFF/LVDS ON.
> > > > >
> > > > > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > > > > returning 0 on drm_master_internal_acquire in
> > > > > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > > > > it cannot able to disconnect and connect the new switching connector.
> > > > >
> > > > > Any help?
> > > >
> > > > I'm not sure why you started another discussion with pretty much the
> > > > same content, but you can't rely on userspace handling the hotplug
> > > > event. You'll have to deal with the case where it just doesn't.
> > >
> > > Well I missed the old thread, so I'm replying here.
> > >
> > > You should not handle this at all from a hotplug.
> > >
> > > The way kms works is roughly as follows:
> > >
> > > 1. hw output state changes
> > > 2. driver detects this (either through hpd interrupt or polling)
> > > 3. driver sends out hotplug uevent
> > >
> > > That's it. Nothing else, no bridge rebinding, no link retaining is
> > > required.
> > >
> > > Then either userspace or fbcon emulation reacts to this hotplug event by
> > > doing an atomic modeset, where it hopefully disables the old output and
> > > re-enables the new output. Your atomic_check needs to validate that
> > > everything is all right (i.e. not enabling both at the same time).
> > >
> > > Note that if you change stuff underneath, then that tends to seriously
> > > upset atomic users. Also you should try to continue supporting at least
> > > page flips with the wrong config, compositors otherwise tend to crash.
> > >
> > > This also means that if userspace doesn't handle hotplug events, then you
> > > might end up with a black screen. That's ok. We try to avoid that when
> > > it's practical (e.g. dp sst link retraining), but not when it's too hard
> > > (dp mst hot-replug relies on userspace restoring everything).
> > >
> > > Finally exchanging the bridge chain isn't supported, there's no locking
> > > for that since it's assumed to be invariant over the lifetim of the
> > > drm_device instance. The simplest way to make that happen right now is to
> > > have 2 drm_encoder instances, one with the lvds bridge chain, the other
> > > with the hdmi bridge chain, and select the right encoder/bridge chain
> > > depending upon which output userspace picks.
> >
> > I've created 2 instances of encoders. endpoint 0 for HDMI bridge chain
> > and endpoint 1 for LVDS bridge chain. Each bridge chain uses a
> > respective encoder instance in order to start attaching the bridge
> > like below.
> >
> > 1. find the bridge at endpoint 0
> > 2. drm_bridge_attach(&mxsfb->encoder[0], mxsfb->bridge[0], NULL, 0)
> >
> > and repeat for endpoint 1
> >
> > The bridge chain established fine for endpoint 0 but returned -EBUSY
> > while the bridge chain attached for endpoint 1. looks like bridge->dev
> > is still being used in endpoint 0 even though we have a separate
> > bridge point from mxsfb.
> >
> > Any thought on how to establish the dual bridge chain here?
>
> Are you using 2 different struct drm_bridge for this? Reusing the same
> drm_bridge for the 2nd encoder and endpoint is the only thing I can
> come up with that would result in this.

Yes, I did try to re-use the same bridge pointer. drm_bridge_attach
giving an -EBUSY while attaching the 2nd bridge chain.

Jagan.

Re: DRM Master ignoring hotplug event during display switching (QT)

[Daniel Vetter]

On Tue, Jun 07, 2022 at 11:03:09PM +0530, Jagan Teki wrote:
> On Tue, Jun 7, 2022 at 8:04 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Thu, 2 Jun 2022 at 17:43, Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >
> > > > On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > > > > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I have implemented runtime display switching in the MIPI switch design
> > > > > > where LVDS and HDMI bridges are selected with the help of runtime
> > > > > > GPIO.
> > > > > >
> > > > > > Initial discussion on the same can be found here,
> > > > > > https://www.spinics.net/lists/dri-devel/msg318524.html
> > > > > >
> > > > > > The implementation has been done by creating each connector at
> > > > > > runtime. The default boot will create the LVDS connector and based on
> > > > > > the HDMI plug-in the ISR.
> > > > > >
> > > > > > 1. forcing the LVDS to disconnect
> > > > > > 2. call drm_kms_helper_hotplug_event
> > > > > > 3. detach the bridge chain
> > > > > > 4. attach the new bridge chain (HDMI)
> > > > > > 5. call drm_kms_helper_hotplug_event
> > > > > >
> > > > > > do the reverse when we unplug the HDMI cable.
> > > > > >
> > > > > > So, the bridge chains are attached and detached based on GPIO
> > > > > > Interrupt which is indeed identified based on the physical HDMIA
> > > > > > connector.
> > > > > >
> > > > > > Pipeline for LVDS,
> > > > > > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> > > > > >
> > > > > > Pipeline for HDMI,
> > > > > > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> > > > > >
> > > > > > With this, implementation and I can able switch the displays with
> > > > > > default DRM (without specific DRM applications) where the LVDS is ON
> > > > > > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > > > > > unplug the HDMI OFF/LVDS ON.
> > > > > >
> > > > > > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > > > > > returning 0 on drm_master_internal_acquire in
> > > > > > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > > > > > it cannot able to disconnect and connect the new switching connector.
> > > > > >
> > > > > > Any help?
> > > > >
> > > > > I'm not sure why you started another discussion with pretty much the
> > > > > same content, but you can't rely on userspace handling the hotplug
> > > > > event. You'll have to deal with the case where it just doesn't.
> > > >
> > > > Well I missed the old thread, so I'm replying here.
> > > >
> > > > You should not handle this at all from a hotplug.
> > > >
> > > > The way kms works is roughly as follows:
> > > >
> > > > 1. hw output state changes
> > > > 2. driver detects this (either through hpd interrupt or polling)
> > > > 3. driver sends out hotplug uevent
> > > >
> > > > That's it. Nothing else, no bridge rebinding, no link retaining is
> > > > required.
> > > >
> > > > Then either userspace or fbcon emulation reacts to this hotplug event by
> > > > doing an atomic modeset, where it hopefully disables the old output and
> > > > re-enables the new output. Your atomic_check needs to validate that
> > > > everything is all right (i.e. not enabling both at the same time).
> > > >
> > > > Note that if you change stuff underneath, then that tends to seriously
> > > > upset atomic users. Also you should try to continue supporting at least
> > > > page flips with the wrong config, compositors otherwise tend to crash.
> > > >
> > > > This also means that if userspace doesn't handle hotplug events, then you
> > > > might end up with a black screen. That's ok. We try to avoid that when
> > > > it's practical (e.g. dp sst link retraining), but not when it's too hard
> > > > (dp mst hot-replug relies on userspace restoring everything).
> > > >
> > > > Finally exchanging the bridge chain isn't supported, there's no locking
> > > > for that since it's assumed to be invariant over the lifetim of the
> > > > drm_device instance. The simplest way to make that happen right now is to
> > > > have 2 drm_encoder instances, one with the lvds bridge chain, the other
> > > > with the hdmi bridge chain, and select the right encoder/bridge chain
> > > > depending upon which output userspace picks.
> > >
> > > I've created 2 instances of encoders. endpoint 0 for HDMI bridge chain
> > > and endpoint 1 for LVDS bridge chain. Each bridge chain uses a
> > > respective encoder instance in order to start attaching the bridge
> > > like below.
> > >
> > > 1. find the bridge at endpoint 0
> > > 2. drm_bridge_attach(&mxsfb->encoder[0], mxsfb->bridge[0], NULL, 0)
> > >
> > > and repeat for endpoint 1
> > >
> > > The bridge chain established fine for endpoint 0 but returned -EBUSY
> > > while the bridge chain attached for endpoint 1. looks like bridge->dev
> > > is still being used in endpoint 0 even though we have a separate
> > > bridge point from mxsfb.
> > >
> > > Any thought on how to establish the dual bridge chain here?
> >
> > Are you using 2 different struct drm_bridge for this? Reusing the same
> > drm_bridge for the 2nd encoder and endpoint is the only thing I can
> > come up with that would result in this.
> 
> Yes, I did try to re-use the same bridge pointer. drm_bridge_attach
> giving an -EBUSY while attaching the 2nd bridge chain.

Yeah that doesn't work. You can embed 2 drm_bridge within the same struct,
that should work. So essentially 1 platform_driver which registers 2
bridges. But binding the same bridge twice is an error, because a bridge
is strictly a 1:1 connection. Not a 2:2 connection.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: DRM Master ignoring hotplug event during display switching (QT)

[Daniel Vetter]

On Wed, Jun 08, 2022 at 05:41:29PM +0200, Daniel Vetter wrote:
> On Tue, Jun 07, 2022 at 11:03:09PM +0530, Jagan Teki wrote:
> > On Tue, Jun 7, 2022 at 8:04 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Thu, 2 Jun 2022 at 17:43, Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > Hi Daniel,
> > > >
> > > > On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > > > > > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I have implemented runtime display switching in the MIPI switch design
> > > > > > > where LVDS and HDMI bridges are selected with the help of runtime
> > > > > > > GPIO.
> > > > > > >
> > > > > > > Initial discussion on the same can be found here,
> > > > > > > https://www.spinics.net/lists/dri-devel/msg318524.html
> > > > > > >
> > > > > > > The implementation has been done by creating each connector at
> > > > > > > runtime. The default boot will create the LVDS connector and based on
> > > > > > > the HDMI plug-in the ISR.
> > > > > > >
> > > > > > > 1. forcing the LVDS to disconnect
> > > > > > > 2. call drm_kms_helper_hotplug_event
> > > > > > > 3. detach the bridge chain
> > > > > > > 4. attach the new bridge chain (HDMI)
> > > > > > > 5. call drm_kms_helper_hotplug_event
> > > > > > >
> > > > > > > do the reverse when we unplug the HDMI cable.
> > > > > > >
> > > > > > > So, the bridge chains are attached and detached based on GPIO
> > > > > > > Interrupt which is indeed identified based on the physical HDMIA
> > > > > > > connector.
> > > > > > >
> > > > > > > Pipeline for LVDS,
> > > > > > > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge
> > > > > > >
> > > > > > > Pipeline for HDMI,
> > > > > > > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector
> > > > > > >
> > > > > > > With this, implementation and I can able switch the displays with
> > > > > > > default DRM (without specific DRM applications) where the LVDS is ON
> > > > > > > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI
> > > > > > > unplug the HDMI OFF/LVDS ON.
> > > > > > >
> > > > > > > However, with QT5 I can see the DRM Master ignoring hotplug event by
> > > > > > > returning 0 on drm_master_internal_acquire in
> > > > > > > drm_fb_helper_hotplug_event. With this the hotplug returned early so
> > > > > > > it cannot able to disconnect and connect the new switching connector.
> > > > > > >
> > > > > > > Any help?
> > > > > >
> > > > > > I'm not sure why you started another discussion with pretty much the
> > > > > > same content, but you can't rely on userspace handling the hotplug
> > > > > > event. You'll have to deal with the case where it just doesn't.
> > > > >
> > > > > Well I missed the old thread, so I'm replying here.
> > > > >
> > > > > You should not handle this at all from a hotplug.
> > > > >
> > > > > The way kms works is roughly as follows:
> > > > >
> > > > > 1. hw output state changes
> > > > > 2. driver detects this (either through hpd interrupt or polling)
> > > > > 3. driver sends out hotplug uevent
> > > > >
> > > > > That's it. Nothing else, no bridge rebinding, no link retaining is
> > > > > required.
> > > > >
> > > > > Then either userspace or fbcon emulation reacts to this hotplug event by
> > > > > doing an atomic modeset, where it hopefully disables the old output and
> > > > > re-enables the new output. Your atomic_check needs to validate that
> > > > > everything is all right (i.e. not enabling both at the same time).
> > > > >
> > > > > Note that if you change stuff underneath, then that tends to seriously
> > > > > upset atomic users. Also you should try to continue supporting at least
> > > > > page flips with the wrong config, compositors otherwise tend to crash.
> > > > >
> > > > > This also means that if userspace doesn't handle hotplug events, then you
> > > > > might end up with a black screen. That's ok. We try to avoid that when
> > > > > it's practical (e.g. dp sst link retraining), but not when it's too hard
> > > > > (dp mst hot-replug relies on userspace restoring everything).
> > > > >
> > > > > Finally exchanging the bridge chain isn't supported, there's no locking
> > > > > for that since it's assumed to be invariant over the lifetim of the
> > > > > drm_device instance. The simplest way to make that happen right now is to
> > > > > have 2 drm_encoder instances, one with the lvds bridge chain, the other
> > > > > with the hdmi bridge chain, and select the right encoder/bridge chain
> > > > > depending upon which output userspace picks.
> > > >
> > > > I've created 2 instances of encoders. endpoint 0 for HDMI bridge chain
> > > > and endpoint 1 for LVDS bridge chain. Each bridge chain uses a
> > > > respective encoder instance in order to start attaching the bridge
> > > > like below.
> > > >
> > > > 1. find the bridge at endpoint 0
> > > > 2. drm_bridge_attach(&mxsfb->encoder[0], mxsfb->bridge[0], NULL, 0)
> > > >
> > > > and repeat for endpoint 1
> > > >
> > > > The bridge chain established fine for endpoint 0 but returned -EBUSY
> > > > while the bridge chain attached for endpoint 1. looks like bridge->dev
> > > > is still being used in endpoint 0 even though we have a separate
> > > > bridge point from mxsfb.
> > > >
> > > > Any thought on how to establish the dual bridge chain here?
> > >
> > > Are you using 2 different struct drm_bridge for this? Reusing the same
> > > drm_bridge for the 2nd encoder and endpoint is the only thing I can
> > > come up with that would result in this.
> > 
> > Yes, I did try to re-use the same bridge pointer. drm_bridge_attach
> > giving an -EBUSY while attaching the 2nd bridge chain.
> 
> Yeah that doesn't work. You can embed 2 drm_bridge within the same struct,
> that should work. So essentially 1 platform_driver which registers 2
> bridges. But binding the same bridge twice is an error, because a bridge
> is strictly a 1:1 connection. Not a 2:2 connection.

Two clarify: That struct with the 2 drm_bridge would be the platform
driver private you register, not part of your platform_driver structure
ofc. It needs to be attached to the struct platform_dev, not the driver.
Just in case I confused you here even more :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch