On Mon, Apr 23, 2018 at 04:18:35PM +0800, Kai Heng Feng wrote:
On Apr 23, 2018, at 4:08 PM, Pali Rohár pali.rohar@gmail.com wrote: On Monday 23 April 2018 16:04:55 Kai Heng Feng wrote:
On Apr 20, 2018, at 8:10 PM, Takashi Iwai tiwai@suse.de wrote: On Fri, 20 Apr 2018 11:44:32 +0200, Kai-Heng Feng wrote:
Now it's a typical discrete-only system. HDMI audio comes from AMD audio controller, others from Intel audio controller.
When SG is enabled, the unused AMD audio contoller still exposes its sysfs, so userspace still opens the control file and stream. If userspace tries to output sound through the stream, it hangs the system.
Hm, could you give more information about how it hangs?
Well, I should say "it hangs the userspace process" instead.
$ speaker-test -t wav -c 2 -D hw:CARD=HDMI,DEV=3 ...and it just stopped. Can't Ctrl+C to break it.
So userspace process cannot be killed at all? Then it is different bug in kernel and disabling pci device is just a workaround. Not a real fix.
I would propose to find out what happen and why it cannot be killed (probably it stuck somewhere in kernel) and fix it properly.
That's because the audio device got runtime suspended by the graphics.
In this case, if we really want to use the the discrete audio, then we also need to wake up the graphics. The discrete audio is totally useless when SG is enabled, so my approach is just to disable it.
I don't quite follow, that should be fixed by commit 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller") which landed in v4.17-rc1.
My understanding was that with SG enabled, the external DP/HDMI ports are muxed to the Intel GPU, so audio can only be streamed to external displays by the Intel HDA, not by the HDA integrated into the discrete AMD/Nvidia GPU. Audio streamed to the latter would essentially end up in a blackhole. And preventing the user from seeing such useless audio devices was the sole purpose of this commit. Am I missing something?
Thanks,
Lukas