[Intel-gfx] [PATCH 0/6] vga-switcheroo: initial dynamic mux switch support

[daniel at ffwll.ch]

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch