[PATCH v2.1 3/3] drm/edid: Switch DDC when reading the EDID

[Lukas Wunner]

Hi Jani,

On Tue, Aug 18, 2015 at 10:02:43AM +0300, Jani Nikula wrote:
> On Fri, 14 Aug 2015, Lukas Wunner <lukas at wunner.de> wrote:
> > Originally by Seth Forshee <seth.forshee at canonical.com>, 2012-10-04:
> > Some dual graphics machines support muxing the DDC separately from the
> > display, so make use of this functionality when reading the EDID on the
> > inactive GPU. Also serialize drm_get_edid() with a mutex to avoid races
> > on the DDC mux state.
> 
> At a glance, all the referenced bugs have LVDS displays.

For the original reporters of the bugs that's true, but another user
jumped on the bandwagon who has a retina and that one uses eDP:
https://bugzilla.kernel.org/show_bug.cgi?id=88861#c7

The pre-retinas with dual GPUs (produced 2008-2013) used LVDS.
The retinas (2012-present) use eDP. (Because the dotclock required
for 2880x1800 (337750 kHz) is not supported by LVDS even with dual
channels, max is 224 MHz.)


> Is this supposed to work for eDP as well?

The 3 patches I've posted with v2.1 enable GPU switching only on LVDS,
and only under certain circumstances. (apple-gmux must register before
the inactive GPU's driver and the inactive GPU may not be an Nvidia.)

The 22 patches I've posted with v2 enable GPU switching on LVDS under
any circumstances and also contain experimental commits that preview
how we're tackling eDP support.


> How about muxing and locking of DPCD access?

Muxing the AUX channel separately from the main link is apparently
unsupported by the gmux controller. See the cover letter of v2 for
details (scroll down to "The long journey towards retina support"):
http://lists.freedesktop.org/archives/dri-devel/2015-August/088156.html

I'm trying to solve this by emulating muxing in software: Read access
to the DPCD is proxied via the active GPU. However the drivers also
try to write to the DPCD and abort link training if the write fails,
so in those situations I check if the contents of DPCD match with
what the driver wants to write, and if so, signal success without
writing anything. E.g. nouveau tries to configure 4 lanes at 270000
and i915 configures the same, so no point in writing to DPCD.
Daniel expressed concerns that the inactive GPU might actually write
to DPCD but there's no code let it do that (deliberately so as it
would be unsafe):
http://lists.freedesktop.org/archives/dri-devel/2015-August/088154.html
http://lists.freedesktop.org/archives/dri-devel/2015-July/088173.html


Best regards,

Lukas