[alsa-devel] HDA controller w/o CLKSTOP and EPSS support

prg at cooco.de prg at cooco.de
Thu Jun 21 00:28:37 CEST 2018


On Wed, 20 Jun 2018 12:14:32 +0200, Takashi Iwai <tiwai at 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?

Kind regards
Henning


More information about the Alsa-devel mailing list