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