Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1144005iob; Wed, 4 May 2022 15:52:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMc8tHRSwMSbCCR5Qbe62hTVAaFehkV2rj+DC9FWaPW6Eny249s5Kk40LBu5xH4SymDVKU X-Received: by 2002:a17:907:7815:b0:6ce:5242:1280 with SMTP id la21-20020a170907781500b006ce52421280mr23009793ejc.217.1651704734112; Wed, 04 May 2022 15:52:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651704734; cv=none; d=google.com; s=arc-20160816; b=EJrNyyGI6GWXCGV1rS/6iX5fhJxh3Io+tNk++mbLUV44YmcW5QC9BunRzmG7VnffIH 9vpKIdKiE06Z4ntKpOth6+6rf6fDBgvFtVG4PGk80ZnwGZDMdz+dp1cPO/W06fEnfMQW SKNI9cTEy6V8sSzj6nm84T/zi3CNekgTYleFm0zL+ILW01ikQe4Zifm9aymFpivmYBpA 7cv33z/8IfBUJO8OgRyrh+LYH0ehfGwYxHNZMf1YY4NXWc+tO+ARmXAyAoGQm27zZzE5 fbS9wkaTjGe7S3G6Xw3+/Jh9d7D60CJlmgXL7NnB3Z0HHgnqU/wwvPsFIoP4appTrPdQ Tiew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=OFV/p74juyEoPxSYXHrzkAx2l6TnhNSxPpzNHi+zhs4=; b=e4PB+MekqnxM1No/Pn8xZdVnC6szuwbBbbuHaC6besK5oYFEEdtWoZtyt7Ecn1x39v ja/8NkPom991Ca+FFgWwvsRUpG6JouQAxj9s/rtx2zQgYgYdLrDBMZOTf2sJouoCz1SO qEVDFlNzbypb4t0R6CWjlCokKZHqdopv/B9/1N2Ys/PwbVxPu8eGxKz9wlTvnMjwKcId OCMtYs8kQEK7XxNMn2uQvTuesuAD3Zmum2qSpzLOzMC4MJ5ocl4nLNEABh3fOmpC32ce 7l2l1/vQnx1ujPRMRnXQwq91PaAKQtLGfQuLYb/2JrR8qGXk6lFO53xibDS7ZKHTsuDd o41w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i24-20020a1709061cd800b006e820adb218si167956ejh.673.2022.05.04.15.51.50; Wed, 04 May 2022 15:52:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359518AbiEDSB6 (ORCPT + 99 others); Wed, 4 May 2022 14:01:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377378AbiEDSAx (ORCPT ); Wed, 4 May 2022 14:00:53 -0400 Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D57F6631A; Wed, 4 May 2022 10:15:36 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id m128so3508242ybm.5; Wed, 04 May 2022 10:15:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OFV/p74juyEoPxSYXHrzkAx2l6TnhNSxPpzNHi+zhs4=; b=4+b1SFPFX4jUr8n7X41dAVG7CcgfqSCIxnhZGEjv+FtmCuDSmycDybFkrhdgaHGWEU 4QTrUmd8XHulaAZP1oVgWJh814JGp6K+D7qRLtWMbAvwKVZ96RjnL4n9x1Zgcdw8ZZuy ABd/nH8sXqXK0XE8KP+359Hewt9LfoRhl46gWAmwJlfm1qf5W9nvvwTeMgtFxR1OKSgQ EYJjerXyqkf6m9i68ubaJltVS2p0Kwl4a0n7FJTiGoI0O5gw4uO4lXvZwLe0DtUeB6yN D/KuDUO440NYwp50eVnvg2fjxLPuaLsIKVfeuXRHSH6aEWb5HJi5PIZ4oD62y4Ow4Kve WVIw== X-Gm-Message-State: AOAM530JkiU2tX7wjZDuLau/eoMpoEHmyvO/JjFNtIuCMNoEFZ/17d1a MN8yh3dvLnbiHDzAEJ9c1Nn3htugiE46rJWv/C8= X-Received: by 2002:a05:6902:187:b0:63d:9c95:edca with SMTP id t7-20020a056902018700b0063d9c95edcamr17647508ybh.81.1651684535365; Wed, 04 May 2022 10:15:35 -0700 (PDT) MIME-Version: 1.0 References: <20220504165409.GA453565@bhelgaas> In-Reply-To: <20220504165409.GA453565@bhelgaas> From: "Rafael J. Wysocki" Date: Wed, 4 May 2022 19:15:24 +0200 Message-ID: Subject: Re: [PATCH v3 4/9] PCI/PM: Rework changing power states of PCI devices To: Bjorn Helgaas Cc: Nathan Chancellor , "Rafael J. Wysocki" , Linux PCI , Linux PM , LKML , Mika Westerberg , Anders Roxell Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 4, 2022 at 7:03 PM Bjorn Helgaas wrote: > > [+cc Anders] > > On Tue, May 03, 2022 at 10:59:43AM -0700, Nathan Chancellor wrote: > > On Thu, Apr 14, 2022 at 03:11:21PM +0200, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > > > There are some issues related to changing power states of PCI > > > devices, mostly related to carrying out unnecessary actions in some > > > places, and the code is generally hard to follow. > > > > > > 1. pci_power_up() has two callers, pci_set_power_state() and > > > pci_pm_default_resume_early(). The latter updates the current > > > power state of the device right after calling pci_power_up() > > > and it restores the entire config space of the device right > > > after that, so pci_power_up() itself need not read the > > > PCI_PM_CTRL register or restore the BARs after programming the > > > device into D0 in that case. > > > > > > 2. It is generally hard to get a clear view of the pci_power_up() > > > code flow, especially in some corner cases, due to all of the > > > involved PCI_PM_CTRL register reads and writes occurring in > > > pci_platform_power_transition() and in pci_raw_set_power_state(), > > > some of which are redundant. > > > > > > 3. The transitions from low-power states to D0 and the other way > > > around are unnecessarily tangled in pci_raw_set_power_state() > > > which causes it to use a redundant local variable and makes it > > > rather hard to follow. > > > > > > To address the above shortcomings, make the following changes: > > > > > > a. Remove the code handling transitions into D0 > > > from pci_raw_set_power_state() and rename it as > > > pci_set_low_power_state(). > > > > > > b. Add the code handling transitions into D0 directly > > > to pci_power_up() and to a new wrapper function > > > pci_set_full_power_state() calling it internally that is > > > only used in pci_set_power_state(). > > > > > > c. Make pci_power_up() avoid redundant PCI_PM_CTRL register reads > > > and make it work in the same way for transitions from any > > > low-power states (transitions from D1 and D2 are handled > > > slightly differently before the change). > > > > > > d. Put the restoration of the BARs and the PCI_PM_CTRL > > > register read confirming the power state change into > > > pci_set_full_power_state() to avoid doing that in > > > pci_pm_default_resume_early() unnecessarily. > > > > > > Signed-off-by: Rafael J. Wysocki > > > Reviewed-by: Mika Westerberg > > > > This change as commit 5bffe4c611f5 ("PCI/PM: Rework changing power > > states of PCI devices") causes my AMD-based system to fail to fully > > boot. > > I dropped 5bffe4c611f5 and subsequent pci/pm patches temporarily while > this gets worked out. OK It looks like I missed something subtle that triggers on a subset of systems only.