[cc += dri-devel, cc -= alsa-devel] On Wed, Jun 20, 2018 at 10:28:37PM +0000, prg@xxxxxxxx wrote: > On Wed, 20 Jun 2018 12:14:32 +0200, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
