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

[Takashi Iwai]

On Thu, 21 Jun 2018 00:28:37 +0200,
prg at cooco.de wrote:
> 
> 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?

It's a hybrid graphics, not switchable one, right?
If so, the symptom sounds like that Intel side is turned off
mistakenly just because the rendering is done in dGPU.

In anyway I think we should go forward with this patch to fix the
runtime PM in audio side.


thanks,

Takashi