On Fri, Apr 3, 2020 at 8:54 AM Daniel Dadap <ddadap@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
