[PATCH v2 00/22] Enable gpu switching on the MacBook Pro

Lukas Wunner lukas at wunner.de
Tue Aug 25 00:36:47 PDT 2015

Hi Dave,

as requested I've pushed the MacBook Pro GPU switching stuff to GitHub
to ease browsing/reviewing, latest branch is gmux-v5:

(I had applied for a freedesktop.org account in April with bug 89906
but it's still pending, hence GitHub.)

I've overhauled locking once more because previously all EDID reads
were serialized even on machines which don't use vga_switcheroo at all.
Seems it's impossible to fix this with mutexes and still be race-free
and deadlock-free, so I've changed vgasr_mutex to an rwlock:

There are a number of vga_switcheroo functions added by Takashi Iwai
and yourself which don't lock anything at all, I believe this was in
part to avoid deadlocks (vga_switcheroo_runtime_resume_hdmi_audio locks
vgasr_mutex, wakes up the GPU with vga_switcheroo_runtime_resume
which locks vgasr_mutex once again). After changing vgasr_mutex to an
rwlock we can safely use locking in those functions as well:

With this change, on machines which don't use vga_switcheroo, the
overhead in drm_get_edid() is exactly 1 read_lock + 1 read_unlock
and EDID reads can happen in parallel. Thierry Reding and Alex Deucher
are in favor of adding a separate drm_get_edid_switcheroo() and changing
the relevant drivers (i915, nouveau, radeon, amdgpu) to use that in lieu
of drm_get_edid() so that drivers which don't use vga_switcheroo avoid
the lock_ddc/unlock_ddc calls. Performance-wise these additional calls
should be negligible, so I think the motivation can only be better
readability/clarity. One should also keep in mind that drivers which
don't use vga_switcheroo currently might do so in the future, e.g.
if mobile GPUs use a big.LITTLE concept like ARM CPUs already do.

Best regards,


More information about the dri-devel mailing list