Hello all, > On 01 Feb 2016, at 23:49, Lukas Wunner <lukas@xxxxxxxxx> wrote: > > Hi, > >> On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: >> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. > > This series hasn't seen any reviews or acks unfortunately. > Any takers? > > Merging this would allow fdo #61115 to be closed > (currently assigned to intel-gfx). > > FWIW this series has in the meantime been tested by more folks: > > Tested-by: Pierre Moreau <pierre.morrow@xxxxxxx> > [MBP 5,3 2009 nvidia MCP79 + G96 pre-retina 15"] > Tested-by: Paul Hordiienko <pvt.gord@xxxxxxxxx> > [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina 15"] > Tested-by: William Brown <william@xxxxxxxxxxxxxxxx> > [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] > Tested-by: Lukas Wunner <lukas@xxxxxxxxx> > [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] > > On the latter three models it worked fine. On Pierre Moreau's machine > the discrete nvidia G96 locks up when woken. This happened in the past > as well but not on the first wake but only on the 10th or so. Since it > works fine on the GT216 and GK107, I'm guessing we've got a regression > in the wakeup code for the G96 which is somehow triggered by this patch > set (more specifically: triggered by being able to retrieve the proper > panel resolution and configure a crtc). It needs to be fixed but isn't > a showstopper for this series IMHO. (Arguably being able to retrieve > EDID but then locking up on switching isn't really worse than not being > able to retrieve EDID in the first place.) I would say it is slightly worse, since the only "downside" of not retrieving the EDID means TTY is set to a default resolution rather than the screen resolution, but this is fixed when starting X. On the other hand, since DRI_PRIME works fine on the laptop, there isn't much reason to switch between cards. I'll have a look at the resume this week, now that FOSDEM is off my todo list. Regards, Pierre > > Thanks, > > Lukas > >> >> The main obstacle on these machines is that the panel mode in VBIOS >> is bogus. Fortunately gmux can switch DDC independently from the >> display, thereby allowing the inactive GPU to probe the panel's EDID. >> >> In short, vga_switcheroo and apple-gmux are amended with hooks to >> switch DDC, DRM core is amended with a drm_get_edid_switcheroo() helper, >> and relevant drivers are amended to call that for LVDS outputs. >> >> The retina MacBook Pro (2012 - present) uses eDP and cannot switch >> AUX independently from the main link. The main obstacle there is link >> training, I'm currently working on this, it will be addressed in a >> future patch set. >> >> This series is also reviewable on GitHub: >> https://github.com/l1k/linux/commits/mbp_switcheroo_v5 >> >> Changes: >> >> * New patch [01/12]: vga_switcheroo handler flags >> Alex Deucher asked if this series might regress on non-Apple laptops. >> To address this concern, I let handlers declare their capabilities in >> a bitmask. DRM drivers call drm_get_edid_switcheroo() only if the >> handler has set the VGA_SWITCHEROO_CAN_SWITCH_DDC flag. >> Currently just one other flag is defined which is used on retinas. >> >> * Changed patch [02/12]: vga_switcheroo DDC locking >> Rename ddc_lock to mux_hw_lock, suggested by Daniel Vetter. >> >> * New patch [03/12]: track switch state of apple-gmux >> Fixes a bug in previous versions of this series which occurred if >> the system was suspended while DDC was temporarily switched: >> On resume DDC was switched to the wrong GPU. >> >> * New patches [09/12 - 12/12]: deferred probing >> Previously I used connector reprobing if the inactive GPU's driver >> loaded before gmux. I've ditched that in favor of deferred driver >> probing, which is much simpler. Thanks to Daniel Vetter for the >> suggestion. >> >> Caution: Patch [09/12] depends on a new acpi_dev_present() API which >> will land in 4.5 via Rafael J. Wysocki's tree. >> >> I would particularly be interested in feedback on the handler flags >> patch [01/12]. I'm not 100% happy with the number of characters >> required to query the flags (e.g.: if (vga_switcheroo_handler_flags() & >> VGA_SWITCHEROO_CAN_SWITCH_DDC)), but failed to come up with something >> shorter. Thierry Reding used a struct of bools instead of a bitmask >> for his recent drm_dp_link_caps patches. Maybe use that instead? >> http://lists.freedesktop.org/archives/dri-devel/2015-December/097025.html >> >> Thanks, >> >> Lukas >> >> >> Lukas Wunner (12): >> vga_switcheroo: Add handler flags infrastructure >> vga_switcheroo: Add support for switching only the DDC >> apple-gmux: Track switch state >> apple-gmux: Add switch_ddc support >> drm/edid: Switch DDC when reading the EDID >> drm/i915: Switch DDC when reading the EDID >> drm/nouveau: Switch DDC when reading the EDID >> drm/radeon: Switch DDC when reading the EDID >> apple-gmux: Add helper for presence detect >> drm/i915: Defer probe if gmux is present but its driver isn't >> drm/nouveau: Defer probe if gmux is present but its driver isn't >> drm/radeon: Defer probe if gmux is present but its driver isn't >> >> Documentation/DocBook/gpu.tmpl | 5 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 3 +- >> drivers/gpu/drm/drm_edid.c | 26 +++++ >> drivers/gpu/drm/i915/i915_drv.c | 12 +++ >> drivers/gpu/drm/i915/intel_lvds.c | 8 +- >> drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +- >> drivers/gpu/drm/nouveau/nouveau_connector.c | 21 +++- >> drivers/gpu/drm/nouveau/nouveau_drm.c | 11 +++ >> drivers/gpu/drm/radeon/radeon_atpx_handler.c | 3 +- >> drivers/gpu/drm/radeon/radeon_connectors.c | 6 ++ >> drivers/gpu/drm/radeon/radeon_drv.c | 11 +++ >> drivers/gpu/vga/vga_switcheroo.c | 119 ++++++++++++++++++++++- >> drivers/platform/x86/apple-gmux.c | 111 ++++++++++++++++----- >> include/drm/drm_crtc.h | 2 + >> include/linux/apple-gmux.h | 39 ++++++++ >> include/linux/vga_switcheroo.h | 36 ++++++- >> 16 files changed, 382 insertions(+), 33 deletions(-) >> create mode 100644 include/linux/apple-gmux.h >> >> -- >> 1.8.5.2 (Apple Git-48) >> -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
