On 4/3/20 2:16 AM, Daniel Vetter wrote:
On Fri, Apr 3, 2020 at 8:54 AM Daniel Dadap <ddadap@xxxxxxxxxx> wrote:
On 4/2/20 6:39 AM, Lukas Wunner wrote:
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
Okay. I misunderstood. When you said that vga-switcheroo could switch
individual outputs and do so without powering down the
switched-away-from GPU, I took that to mean that this feature had
already been implemented somewhere, despite appearances to the contrary
upstream. I agree that adding per-output switching support to
vga-switcheroo would be a sensible path.
Does this sound like a sensible high-level design?
* vga-switcheroo-capable GPU drivers can register muxable outputs.
* Each GPU driver must register each unique muxable output with the same
identifier. The outputs will be registered together with individual
devices they can be muxed to, in order to support e.g. muxing between
different GPU devices driven by the same vendor. (I'm not aware of any
designs that actually support this, but it seems reasonable to design
for.) The output identifier may be platform-specific (e.g. ACPI handle,
simple index). For example, two GPU drivers may each register an
internal panel with identifier "0" and an external port with identifier "1".
* For each output that was registered with more than one device,
vga-switcheroo will expose a sysfs file listing the devices that output
can be muxed to, and a sysfs file allowing the selection of a particular
device. Perhaps these could be the same file (e.g., on reading it prints
a list with an indicator to mark the currently selected device, write a
device ID to switch to that device).
I think this would allow flexibility across N muxable outputs that can
each be switched to one of M GPU devices, without requiring that each of
the outputs be switchable to all M possible GPUs.
In addition to the above mechanism for advertising the switchability of
individual outputs and providing an interface, the following would also
be needed to support PSR:
* A new callback for GPU drivers so vga-switcheroo can tell them an
output is being switched to a GPU.
* vga-switcheroo can call this callback for all devices once before
switching the mux, and then again after the mux switch is complete. A
parameter of the callback would indicate whether the mux switch is
pending, completed, or failed, allowing GPU drivers to do any necessary
pre-switch setup, post-switch cleanup, or failed-switch recovery in
response to events from vga-switcheroo.
* Maybe a similar callback for mux handlers so vga-switcheroo can signal
pre- and post-switch events to the handler driver. The PSR designs I'm
aware of are GPU-driven, but I can imagine a design that is driven by
some component other than a GPU, in which case it would make sense for
the mux handler to drive PSR. I suppose this could be left out for now
and then added later if such a design emerges.
* It would probably be good to let userspace drive the pre/switch/post
operations independently, e.g. so that userspace can prepare the first
frame for presentation on the switched-to GPU before PSR is disabled.
Now, I'm not sure if it makes more sense to also implement the AUX
channel proxying that Lukas had prototyped a while back, or to update
i915 and any other vga-switcheroo-compatible drivers that assume that
eDP is always connected to allow for the possibility of eDP being
disconnected due to being muxed away. I personally think disconnecting
the eDP output makes more sense, since it more accurately reflects
reality than proxying the AUX channel through to the GPU that's muxed
in, but if there's another reason the AUX proxying makes more sense, we
could plan on making that work (on a per-output basis, since I think
e.g. regular DP for external connectors wouldn't need this) as well.
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
