Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5128018ybe; Tue, 17 Sep 2019 03:07:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqw/Q/iV9M2DTpkzKF+Ar4zyMJ6RT3IH6j9ICvUoHZIRG7F5iHiU2vJnVxxXVp0kTnHfSa3l X-Received: by 2002:a05:6402:78b:: with SMTP id d11mr1689611edy.14.1568714869953; Tue, 17 Sep 2019 03:07:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568714869; cv=none; d=google.com; s=arc-20160816; b=Q8InE+VPMRvQ2ngo2JE1Q80Fdf1FeZIraIBjeAoyjVIpcUVjKYx7EXZ2WzYdpM8ux+ 1o4kQgTXUwVa3eV3R52EqB+CxjfLjK9596YrcDbnOEPpa2O3LkixhON/3bEuqKS7kgCW nllNfOiRFDBnYlBLDKkKDpCjftVx8/EhDn+HW62oQv4KR2rbvvm0rjDJ22927WH4sIru Jb+DTmdiA2MOPHS8pY3BYRDo2cPpivTd6tWQZyX6nUd4MiTWLKq7E1ptyRMuOTByiypy fr0LqVZbxbr940NFCP9y6/Nz9G+5rjpgZhsPUftuRjJro4fDoI6pJsty8Xk7IR2QvneV y3Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=7NMTOlZG+wcF+9sEed+RRYQ56hmqi9j6Enu+KnyD4Yw=; b=VRkqnUuAsugCfsv9CLvCmIplG98/Wf5LUeXyJO7UsqSIq2sqeBGiSXG4/EPOa5464D 4GMRImeyuxsJ74UU1n/+VJi4rXmDR+DOdpvs1RP5pBYDVZGNg38Ww+mXiSZDSP9aHyl5 24ejAw9Ns83kUYAn0kvArDXgb5tEXIgMG3rutSlSXMn95ydyJ8v5NlortpAc4oRyombG 3MUoTRLwhXMFXWyUiP1bTR9XxlORjcilh6orrMTX85yFBJQ0t8c3RXljT15UO+EoWL/r dOF59WFu8LuQ/HFtiXiLvxVKS/sTOq1DhnCwm3J2Z3tmpDkI2tYXbEXFNDx6j4QGFQ97 jHIw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u27si578732ejb.172.2019.09.17.03.07.27; Tue, 17 Sep 2019 03:07:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728134AbfIQJhG convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Sep 2019 05:37:06 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:50332 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726191AbfIQJhF (ORCPT ); Tue, 17 Sep 2019 05:37:05 -0400 Received: from mail-ot1-f70.google.com ([209.85.210.70]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iA9ux-0006ry-Ra for linux-kernel@vger.kernel.org; Tue, 17 Sep 2019 09:37:04 +0000 Received: by mail-ot1-f70.google.com with SMTP id g5so1408770otp.22 for ; Tue, 17 Sep 2019 02:37:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EIbijquzMtQBr8kkr1tOGfR+o3tuxAs9+vpk/bBLO3Q=; b=SHOTCyf/eO4g1OvJJIW00ojChWBNNBAtoUv7dVQMh7sa1KcFuMKsXwWvGmn63yVEOB jxH94snzFLIYWeAW70wyovifyb+87PvvB88g6CZvEQCYrfCJJTXc++0Xw1guUTIGLdsQ AO/KFGxNFXggII4Oe/h7A1CgAB1S5o2+/ehEc2vXQVnyNKzSruEgJjWa9/3a2iarLv90 X8ROtwcGSkdgdx4WVT3YVYZYRSMTk1XvOM4BUNn3ceFY6jAMdlX7oNO/HdsX0yHEdcML aQqRNh4a0+/MncSwS/FCL9Wq7isElpR6GVNSbUlpw5oYwpxNtFg91yqGHLcUQeStyX3m /YuQ== X-Gm-Message-State: APjAAAU+xrkqJY6FMp8rQBjbeoh16sQ5BGVDT7f0yPV8Fof04fqWk0ei 8tCTjV1UeGN+0S1V52dCe3sMDPxsFNmDV/B7DFMdvCkVN6fUqCy+DnV5xb9BlVuBdJN84K1R4vX 8XRn5mav7qM3G604lJqX6wZk6JLZCDBOfnRDO3OQK3yc2WlhKvQ6IEQMf0A== X-Received: by 2002:a05:6830:2306:: with SMTP id u6mr2117283ote.0.1568713022837; Tue, 17 Sep 2019 02:37:02 -0700 (PDT) X-Received: by 2002:a05:6830:2306:: with SMTP id u6mr2117270ote.0.1568713022472; Tue, 17 Sep 2019 02:37:02 -0700 (PDT) MIME-Version: 1.0 References: <20190827134756.10807-2-kai.heng.feng@canonical.com> <20190828180128.1732-1-kai.heng.feng@canonical.com> <20190905213509.GI103977@google.com> In-Reply-To: <20190905213509.GI103977@google.com> From: Kai-Heng Feng Date: Tue, 17 Sep 2019 11:36:51 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound To: Bjorn Helgaas Cc: tiwai@suse.com, Linux PCI , alsa-devel@alsa-project.org, LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn, On Thu, Sep 5, 2019 at 11:35 PM Bjorn Helgaas wrote: > > On Thu, Aug 29, 2019 at 02:01:28AM +0800, Kai-Heng Feng wrote: > > It's a common practice to let dGPU unbound and use PCI platform power > > management to disable its power through _OFF method of power resource, > > which is listed by _PR3. > > When the dGPU comes with an HDA function, the HDA won't be suspended if > > the dGPU is unbound, so the power resource can't be turned off. > > I'm not involved in applying this patch, but from the peanut gallery: > > - The above looks like it might be two paragraphs missing a blank > line between? Or maybe it's one paragraph that needs to be > rewrapped? I think it can be both. I'll rephrase it. > > - I can't parse the first sentence. I guess "dGPU" and "HDA" are > hardware devices, but I don't know what "unbound" means. Is that > something to do with a driver being bound to the dGPU? Or is it > some connection between the dGPU and the HDA? Yes, "unbound" in this context means the dGPU isn't bound to a driver. > > - "PCI platform power management" is still confusing -- I think we > either have "PCI power management" that uses the PCI PM Capability > (i.e., writing PCI_PM_CTRL as in pci_raw_set_power_state()) OR we > have "platform power management" that uses some other method, > typically ACPI. Since you refer to _OFF and _PR3, I guess you're > referring to platform power management here. Yes, I'll make it clearer in next version. It's indeed referring to platform power management. > > - "It's common practice to let dGPU unbound" -- does that refer to > some programming technique common in drivers, or some user-level > thing like unloading a driver, or ...? My guess is it probably > means "unbind the driver from the dGPU" but I still don't know > what makes it common practice. Yes it means keep driver for dGPU unloaded. It's a common practice since the proprietary nvidia.ko doesn't support runtime power management, so when users are using integrated GPU, unload the dGPU driver can make PCI core use platform power management to disable the power source to save power. > > This probably all makes perfect sense to the graphics cognoscenti, but > for the rest of us there are a lot of dots here that are not > connected. Will send a v2 with clearer description. Kai-Heng > > > Commit 37a3a98ef601 ("ALSA: hda - Enable runtime PM only for > > discrete GPU") only allows HDA to be runtime-suspended once GPU is > > bound, to keep APU's HDA working. > > > > However, HDA on dGPU isn't that useful if dGPU is unbound. So let's > > relax the runtime suspend requirement for dGPU's HDA function, to save > > lots of power. > > > > BugLink: https://bugs.launchpad.net/bugs/1840835 > > Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers”) > > Signed-off-by: Kai-Heng Feng > > --- > > v2: > > - Change wording. > > - Rebase to Tiwai's branch. > > > > sound/pci/hda/hda_intel.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > > index 91e71be42fa4..c3654d22795a 100644 > > --- a/sound/pci/hda/hda_intel.c > > +++ b/sound/pci/hda/hda_intel.c > > @@ -1284,7 +1284,11 @@ static void init_vga_switcheroo(struct azx *chip) > > dev_info(chip->card->dev, > > "Handle vga_switcheroo audio client\n"); > > hda->use_vga_switcheroo = 1; > > - chip->bus.keep_power = 1; /* cleared in either gpu_bound op or codec probe */ > > + > > + /* cleared in either gpu_bound op or codec probe, or when its > > + * root port has _PR3 (i.e. dGPU). > > + */ > > + chip->bus.keep_power = !pci_pr3_present(p); > > chip->driver_caps |= AZX_DCAPS_PM_RUNTIME; > > pci_dev_put(p); > > } > > -- > > 2.17.1 > >