On Thu, 2 Jun 2022 at 17:43, Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > > Hi Daniel, > > On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter <daniel@xxxxxxxx> 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
