On Tue, 10 Jul 2018 13:11:20 +0200, jimqu wrote: > > > > On 2018å¹´07æ??10æ?¥ 17:50, Takashi Iwai wrote: > > On Tue, 10 Jul 2018 11:13:27 +0200, > > jimqu wrote: > >> > >> > >> On 2018å¹´07æ??10æ?¥ 16:01, Takashi Iwai wrote: > >>> On Tue, 10 Jul 2018 09:44:42 +0200, > >>> Qu, Jim wrote: > >>>> Hi Takashi, > >>>> > >>>> I am not expert in audio driver, so I just update some test result, please help triage the issue. > >>>> > >>>> With audio runtime pm: > >>> What does this mean? Is it the stock 4.17.x (or 4.18-rc)? > >>> Please clarify your test environment at first: which kernel, which > >>> hardware setup. > >>> > >> This is v4.15 which backport Lukas' patches and also one bug fix > >> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd. > >> The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX > >> platform. In generic, dGPU will always be suspended. > > Ah, so it's AMD+AMD, not Intel+AMD combo. Now I understand the > > situation better, thanks. > > > >>>> 1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm. > >>>> 2. cat /proc/asound/card0/eld* can get nothing. > >>>> > >>>> Without audio runtime pm: > >>>> 1. pactl can get available audio output/sink > >>>> 2. can get eld info from eld#0.1 > >>>> > >>>> IMO, the issue should be: > >>>> > >>>> Current operations like HDMI hotplug in/out, pactl command, they do > >>>> not access audio HW, so the audio could not resume back at this > >>>> period. > >>> Sorry, not understood. Why they don't access the audio hardware? > >> This is my guess, since I do not get azx_runtime_resume() print info > >> which I added. it maybe access HW during this period, but do not > >> trigger audio resume progress. > >> <https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume> > >>>> Therefore, upper software could not get HDMI ELD info, can select a available card/output sink. > >>>> I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question. > >>> As long as it's i915 and HD-audio, the hotplug and ELD info transfer > >>> doesn't trigger the runtime PM since it's done via the direct > >>> callback. And ELD value is cached in HD-audio side. > >> Yeah, I have reviewed these code, it constructs ELD after reading > >> EDID, and write them into HW buffer when set display mode. > > If the controller chip supports "wake-enable" feature (HD-audio WAKEEN > > register), it could be woken up at unsolicited event even during the > > link power down. But, your report implies that AMD controller doesn't > > do this, or something missing there. That's the likely cause of the > > missing hotplug event. > > Is there any method to confirm it? The driver always sets WAKEEN bit, see azx_runtime_suspend() in hda_intel.c. If it still doesn't behave as expected, it means that the feature isn't supported on that chip :) > > So, if my understanding is right, the situation won't be different > > even if you have a single AMD GPU. And possibly a side-effect of the > > latest fix to force link-down for AMD GPU. Need to check it... > > Before Lukas' patches, it is relative with dGPU, because audio power > is controlled by vgaswitchreroo and GFX driver, but now it won't. Right, and this is the correct behavior. > revert the fix of amdgpu suspend issue, audio issue also can be observed. Did you check the behavior with the single AMD GPU hardware? If confirmed, we can forget about vga_switcheroo. Takashi
