Muxed ATPX graphics (was: Re: HDA controller w/o CLKSTOP and EPSS support)

Muxed ATPX graphics (was: Re: HDA controller w/o CLKSTOP and EPSS support)

[Lukas Wunner]

[cc += dri-devel, cc -= alsa-devel]

On Wed, Jun 20, 2018 at 10:28:37PM +0000, prg@cooco.de wrote:
> On Wed, 20 Jun 2018 12:14:32 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> > I guess it would work with a quirk. The EPSS and CLKSTOP checks are
> > just to assure the modern codec PM, and GPU is always exceptional.
> > 
> > Supposing that it's AMD GPU, does a fix like below work?
> 
> The suggested fix restores the previous behavior: the dGPU is properly
> powered down. But this previous behavior is really broken in other
> ways, so I'm now wondering if it could work any better than that.
> 
> On kernels <4.17 and on 4.17 with that patch applied the notebook
> screen turns off completely when running things with DRI_PRIME=1 and
> only comes back a few seconds after the process ends. glxinfo is
> showing radeon instead of intel as expected, but with a blank screen,
> it's useless.
> 
> On kernel 4.17 without the patch, when the dGPU is constantly on, I can
> have intel render things with DRI_PRIME=0 and radeon with DRI_PRIME=1
> without the screen turning off. Also, switches between vt and X are now
> instant and external displays are working, which wasn't the case
> before. Why is this now working suddenly? Is the dGPU rendering all of
> the desktop when it's always on anyway? Or is the iGPU rendering the
> desktop and the dGPU could potentially be suspended when not in use, if
> it was just done the right way?
> 
> I used to accept this broken behavior and just changed the BIOS setting
> for the GPU from "switchable" to "discrete" when I wanted to actually
> use the dGPU. Initially when I reported the bug I just wanted to find a
> way to suspend the dGPU again to save power. But now that I've seen my
> notebook working like this I'd like to have both: a powered down dGPU
> when not in use and properly working DRI_PRIME.
> 
> Any ideas what's up with the current situation or should I file a new
> bug report?

You've got a muxed ATPX laptop.  We don't support runtime PM on those,
at least not yet.  Boot with radeon.runpm=0, you should then be able to
use manual power control:

https://www.kernel.org/doc/html/latest/gpu/vga-switcheroo.html#manual-switching-and-manual-power-control

My guess is that the ACPI tables toggle the mux when the discrete GPU is
powered up/down, behind the operating system's back.  So, you start a
process with DRI_PRIME=1, the discrete GPU powers up and the _S0 method
switches the mux to the discrete GPU.  But the discrete GPU's outputs
are disabled because it wasn't able to probe the EDID:

[    5.358476] [drm] Cannot find any crtc or sizes

So the panel stays dark.  Once you stop the process, the discrete GPU
runtime suspends to D3cold after 5 seconds and the panel is switched back
to the Intel GPU.

The reason the discrete GPU cannot probe the panel's EDID is because
the panel is switched to the Intel GPU on boot (when radeon loads),
the panel's DDC lines cannot be muxed separately from the main display
link (your dmesg output says "ATPX version 1, functions 0x00000007",
bit 3 isn't set, it indicates support for separate DDC switching)
and in drivers/gpu/drm/radeon/radeon_connectors.c, there's this check
in radeon_lvds_detect():

		/* don't fetch the edid from the vbios if ddc fails and runpm is
		 * enabled so we report disconnected.
		 */
		if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm != 0))
			ret = connector_status_disconnected;

If you remove this check (there's another one in radeon_dp_detect()),
the GPU might be able to retrieve a proper mode from VBIOS tables,
but then it won't runtime suspend at all because it has an active crtc.

I was planning to continue my work on runtime PM for muxed laptops
later this year, but I'm focussing on MacBook Pros, which do allow
DDC switching and don't switch the panel behind the OS's back.
Nevertheless it may be possible to improve the user experience for
your machine as well, so please open another bug and attach dmesg
output with drm.debug=0xf and an acpidump, and add me to cc.  Also,
when you use DRI_PRIME=1 and the screen goes black, please check if
the backlight stays on.  (Hold a flashlight to the screen to verify
whether something is displayed but the backlight is off.)

Meanwhile my recommendation is to use manual switching.  If my theory
is correct that the panel is switched by ACPI, you won't be able to use
the ON and OFF commands, only DIS and IGD will behave as intended.
Oh and you can't do this while X is running, only on the console.

The external HDMI and VGA ports are likely soldered to the discrete
GPU on your machine, so you'll have to switch to it whenever an external
display is attached.

Hope that helps,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel