| Message ID | 20200727205112.27698-1-ddadap@nvidia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | vga-switcheroo: initial dynamic mux switch support | expand |
On Mon, Jul 27, 2020 at 03:51:06PM -0500, Daniel Dadap wrote: > Changes to allow vga-switcheroo to switch the mux while modesetting > clients remain active. There is existing support for switching the > mux without checking can_switch; however, this support also does not > reprobe after the mux switch is complete. This patch series adds a new > type of switch event which switches immediately while still calling > client driver callbacks, and updates the i915 DRM-KMS driver to reprobe > eDP outputs after switching the mux to an i915-driven GPU, and to avoid > using eDP links (which i915 always assumes to be connected) while the > mux is switched away. So before digging into the details I think the big issue we need to solve first is locking. And current vga-switcheroo is already broken in that regard (there's some fixme comments in drivers about it), but I never cared because it was full device switch only, initiated by users. But you now add vgaswitcheroo to modeset code, and runtime switching, I don't think we can ignore locking here anymore. Also, it's classic abba deadlock design: i915 modeset code calls your new functions in vgaswitcheroo, and vgaswitcheroo calls into modeset code to shut down stuff. This doesn't work (you get away with it by omitting locking in some places, like the current code). One totally nuts idea I've had is to protect vgaswitcheroo output state with a drm_modeset_lock. That supports full graph locking, which means it doesn't matter where we start: nouveau, i915, vgaswitcheroo. So could work out neatly. Problem: That still leaves the loop for the device switching, which is all tangled up here, so either we make this completely separate, or we figure out a plan how make this work for device switching too. And the additional problem is that drm_modeset_lock is already a highly entrenched lock, I'm not sure whether we can also support the device switching with that approach: The device locking we'd need would need to be an outermost lock, or at least fairly big, whereas drm_modeset_lock is kinda a level below. Or I'm making a mess here (it is already one after all). Also, where's the other side? I know the other side you care about is in the nvidia blob driver, but that doesn't count for upstream. We need that code in nouveau for review and merging. Cheers, Daniel > > Daniel Dadap (6): > vga-switcheroo: add new "immediate" switch event type > vga-switcheroo: Add a way to test for the active client > vga-switcheroo: notify clients of pending/completed switch events > i915: implement vga-switcheroo reprobe() callback > i915: fail atomic commit when muxed away > i915: bail out of eDP link training while mux-switched away > > drivers/gpu/drm/i915/display/intel_display.c | 7 + > .../drm/i915/display/intel_dp_link_training.c | 9 ++ > drivers/gpu/drm/i915/i915_switcheroo.c | 27 +++- > drivers/gpu/vga/vga_switcheroo.c | 153 ++++++++++++++---- > include/linux/vga_switcheroo.h | 20 +++ > 5 files changed, 185 insertions(+), 31 deletions(-) > > -- > 2.18.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx