lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180502074455.GA17650@wunner.de>
Date:   Wed, 2 May 2018 09:44:55 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     Kai Heng Feng <kai.heng.feng@...onical.com>
Cc:     Pali Rohár <pali.rohar@...il.com>,
        Takashi Iwai <tiwai@...e.de>, mjg59@...f.ucam.org,
        dvhart@...radead.org, andy@...radead.org,
        Mario Limonciello <mario.limonciello@...l.com>,
        alsa-devel@...a-project.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        platform-driver-x86@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH v4 3/3] ALSA: hda: Disabled unused audio
 controller for Dell platforms with Switchable Graphics

On Thu, Apr 26, 2018 at 03:52:08PM +0800, Kai Heng Feng wrote:
> > On Apr 25, 2018, at 5:13 AM, Lukas Wunner <lukas@...ner.de> wrote:
> > On Mon, Apr 23, 2018 at 04:18:35PM +0800, Kai Heng Feng wrote:
> > > 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.
> 
> Looks like I hit a new bug: the discrete GFX and its audio controller
> never enters to D3.
> The GFX can enter to D3 with my prosed patch.

Can you find out why?  Does the HDA controller have a codec as child
device that doesn't runtime suspend, perhaps because it failed to
initialize correctly?  If a codec device fails to runtime suspend,
the HDA controller (as parent) and by extension the GPU (via the
device link) are also kept runtime active.

Do you see anything in dmesg when the AMD HDA controller probes?
If you look in /sys/bus/pci/devices/0000:01:00.1/power/, does the
HDA controller have active kids and what is its usage count?


> > 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?
> 
> Yes this is the intention.

Could you add this information to the commit message then?

Thanks,

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ