From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BD76C3A5A3 for ; Tue, 27 Aug 2019 22:40:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AAF5F217F5 for ; Tue, 27 Aug 2019 22:40:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lekensteyn.nl header.i=@lekensteyn.nl header.b="MGqMIq0T" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726342AbfH0WkA (ORCPT ); Tue, 27 Aug 2019 18:40:00 -0400 Received: from lekensteyn.nl ([178.21.112.251]:58661 "EHLO lekensteyn.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbfH0WkA (ORCPT ); Tue, 27 Aug 2019 18:40:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=W755SOjG26JPvvqPajc576xDrzJZD3HASrkXEzOzrLI=; b=MGqMIq0TngzkjMrWN5ZznKdYTGRhaljhOyJFFa+R6hRDSBkhAifGf90vBV7+/zirmtsd3rsBO7SNclUcIx4Ll+F04TZC+iFvDmAoaACRWQHBYBgEZLtyWil+tRQAHg8XJbBxWywM2XkqUw4d9tkv/vzoVzu/uhwNF+mn1UrtZBwxqfo15hEPadoZ5cHaV731KoG5hJUWNqx3k+44s1x3UbPVj0B9O9n05yQtgvFYhx6wZEE7DIb6UomxHiUuML0NEXDEzmHBZLQ1TKArcthzqo5Sg5EAlCehV9qcbpKL+pryg5irvWfM/IcTpr+iChvGGYkX2FQdT2psvHeRGqGU5Q==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1i2k81-0001HF-Ng; Wed, 28 Aug 2019 00:39:54 +0200 Date: Tue, 27 Aug 2019 23:39:51 +0100 From: Peter Wu To: Bjorn Helgaas Cc: Kai-Heng Feng , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Mika Westerberg , Dave Airlie Subject: Re: [PATCH 1/2] PCI: Add a helper to check Power Resource Requirements _PR3 existence Message-ID: <20190827223951.GA27744@al> References: <20190827134756.10807-1-kai.heng.feng@canonical.com> <0379E973-651A-442C-AF74-51702388F55D@canonical.com> <20190827221321.GA9987@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190827221321.GA9987@google.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 27, 2019 at 05:13:21PM -0500, Bjorn Helgaas wrote: > [+cc Peter, Mika, Dave] > > https://lore.kernel.org/r/20190827134756.10807-1-kai.heng.feng@canonical.com > > On Wed, Aug 28, 2019 at 12:58:28AM +0800, Kai-Heng Feng wrote: > > at 23:25, Takashi Iwai wrote: > > > On Tue, 27 Aug 2019 15:47:55 +0200, > > > Kai-Heng Feng wrote: > > > > A driver may want to know the existence of _PR3, to choose different > > > > runtime suspend behavior. A user will be add in next patch. > > > > > > > > This is mostly the same as nouveau_pr3_present(). > > > > > > Then it'd be nice to clean up the nouveau part, too? > > > > nouveau_pr3_present() may call pci_d3cold_disable(), and my intention is to > > only check the presence of _PR3 (i.e. a dGPU) without touching anything. > > It looks like Peter added that code with 279cf3f23870 > ("drm/nouveau/acpi: use DSM if bridge does not support D3cold"). > > I don't understand the larger picture, but it is somewhat surprising > that nouveau_pr3_present() *looks* like a simple predicate with no > side-effects, but in fact it disables the use of D3cold in some cases. The reason for disabling _PR3 from that point on is because mixing the ACPI firmware code that uses power resources (_PR3) with the legacy _DSM/_PS0/_PS3 methods to manage power states could break as that combination is unlikely to be supported nor tested by firmware authors. If a user sets /sys/bus/pci/devices/.../d3cold_allowed to 0, then the pci_d3cold_disable call ensures that this action is remembered and prevents power resources from being used again. For example, compare this power resource _OFF code: https://github.com/Lekensteyn/acpi-stuff/blob/b55f6bdb/dsl/Clevo_P651RA/ssdt3.dsl#L454-L471 with this legacy _PS0/_PS3 code: https://github.com/Lekensteyn/acpi-stuff/blob/b55f6bdb/dsl/Clevo_P651RA/ssdt7.dsl#L113-L142 The power resource code checks the "MSD3" variable to check whether a transition to OFF is required while the legacy _PS3 checks "DGPS". The sequence PG00._OFF followed by _DSM (to to change "OPCE") and _PS3 might trigger some device-specific code twice and could lead to lockups (infinite loops polling for power state) or worse. I am not sure if I have ever tested this scenario however. > If the disable were moved to the caller, Kai-Heng's new interface > could be used both places. Moving the pci_d3cold_disable call to the caller looks reasonable to me. After the first patch gets merged, nouveau could use something like: *has_pr3 = pci_pr3_present(pdev); if (*has_pr3 && !pdev->bridge_d3) { /* * ... */ pci_d3cold_disable(pdev); *has_pr3 = false; } For the 1/2 patch, Reviewed-by: Peter Wu -- Kind regards, Peter Wu https://lekensteyn.nl