DRM Master ignoring hotplug event during display switching (QT)

[Daniel Vetter]

On Thu, 2 Jun 2022 at 17:43, Jagan Teki <jagan at amarulasolutions.com> wrote:
>
> 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?

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