How to handle disconnection of eDP panels due to dynamic display mux switches

Fri Apr 3 07:16:06 UTC 2020

On Fri, Apr 3, 2020 at 8:54 AM Daniel Dadap <ddadap at nvidia.com> wrote:
>
>
> On 4/2/20 6:39 AM, Lukas Wunner wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote:
> >> A number of hybrid GPU notebook computer designs with dual (integrated plus
> >> discrete) GPUs are equipped with multiplexers (muxes) that allow display
> >> panels to be driven by either the integrated GPU or the discrete GPU.
> >> Typically, this is a selection that can be made at boot time as a menu
> >> option in the system firmware's setup screen, and the mux selection stays
> >> fixed for as long as the system is running and persists across reboots until
> >> it is explicitly changed. However, some muxed hybrid GPU systems have
> >> dynamically switchable muxes which can be switched while the system is
> >> running.
> > As you may be aware, there's drivers/gpu/vga/vga_switcheroo.c (of which
> > I'm listed as a reviewer in MAINTAINERS) to support such hardware.
> >
> > It also supports muxed configurations, including those that support
> > switching at runtime (and not only at boot) such as the MacBook Pro,
> > which uses drivers/platform/x86/apple-gmux.c to interface between
> > vga_switcheroo and the hardware mux.
> >
> > However, so far switching only actually works on LVDS-based MacBook Pros,
> > i.e. all pre-retina machines introduced between Late 2008 and Mid 2012,
> > because that hardware is capable of switching the DDC pins separately
> > from the display, so we lock and switch them when probing the EDID.
>
>
> I have observed that on at least some systems, the EDID for the internal
> panel can be read via the ACPI _DDC method regardless of whether it's
> actively muxed in. I don't know whether that's true for all systems
> where the DDC line can't be switched independently, but maybe
> vga_switcheroo could also export an interface for GPU drivers to cache
> EDIDs so that a muxed-away GPU can read an EDID that was previously read
> by another GPU? I guess the utility of that would depend on how
> prevalent the combination of no DDC muxing + no ACPI EDID reads turns
> out to be.
>
>
> > The retina machines introduced from Mid 2012 onward use eDP and run
> > into the issues you're describing:  The AUX channel cannot be switched
> > separately from the display, so link training fails unless the entire
> > display is switched.  Nevertheless macOS can switch the panel seamlessly.
> > So how are they doing it?
> >
> > Well, I don't own a retina MacBook Pro, hence never got very far with
> > supporting them, but I did some research and experiments in the 2015/2016
> > time frame which a colleague, Bruno Bierbaumer, tested on his machine:
> >
> > First of all, there's DPCD byte 3 bit 6 (NO_AUX_HANDSHAKE_LINK_TRAINING)
> > which is documented as follows:
> >
> >      Does not require AUX CH handshake when the link configuration is
> >      already known. [...] The known-good drive current and pre-emphasis
> >      level (or those used in the last "full" link training with AUX CH
> >      handshake) must be used when the link training is performed without
> >      AUX CH handshake.
> >
> > That bit is set on the MacBook Pros in question.
>
>
> I'll check one of the eDP-based systems I've been experimenting on to
> see if setting the VGA_SWITCHER_NEEDS_EDP_CONFIG capability in the
> handler is sufficient to make i915 avoid poking the AUX channel when
> it's mux-switched away. (This would be in addition to hacking the
> can_switch() callback in the GPU drivers to allow switching while there
> are still active KMS clients for the purposes of this experiment, unless
> somebody can point me to a tree with the WIP per-output switching Daniel
> Vetter mentioned.

Two things: I thought (but not sure) that for the output switching
muxes we'd run vgaswitcheroo in a different mode, where it doesn't
check whether whether the driver can be killed. Because it wont. On a
quick search only thing I've found is the ddc-only switching done by
vga_switcheroo_lock/unlock_ddc. Maybe misremembering, but I thought
there was more. But been a while I last looked at this all in detail.

Wrt per-output switching WIP branch. That would be something you'd
need to type ofc, I was just laying out what I think would make sense
as a possible path to integrate this into upstream.
-Daniel

> > So I think what we should be doing here is that the DRM driver which
> > happens to be muxed to the panel on boot performs link training and
> > informs vga_switcheroo of the drive current, pre-emph level, etc.
> > The other DRM driver is notified when that information is available
> > and uses it to set up its eDP output, skipping an actual AUX CH
> > handshake.
> >
> > At least i915 probes various capabilities in the DPCD without any
> > consideration that the AUX channel may currently not be available.
> > Back in the day I experimented with a read-only proxy mechanism
> > to make that work, whereby the inactive DRM driver uses the active
> > DRM driver to access the DPCD:
> >
> > https://patchwork.kernel.org/patch/7000591/
> >
> > An alternative would be to have the active DRM driver cache the
> > required portions of the DPCD for use by the inactive DRM driver.
> >
> > Note that vga_switcheroo is currently controlled via debugfs.
> > That is a historic artefact.  The kernel has since gained a
> > mux subsystem in drivers/mux/ which could be used to represent
> > the display mux in a standardized way in regular sysfs.
> >
> > Thanks,
> >
> > Lukas
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch