Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3268518pxb; Mon, 16 Nov 2020 09:56:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJwIQ3jeb+Qgg6ZlZj+/jm7DiJflVHpfauvxKroheA4jjvCtOC33nsyjd7TsE+50in5hDHJZ X-Received: by 2002:a17:906:14d1:: with SMTP id y17mr16021232ejc.15.1605549390697; Mon, 16 Nov 2020 09:56:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605549390; cv=none; d=google.com; s=arc-20160816; b=y8urpxP/RE+dlKE5LJQ6NQmPOPPzhh6ajkkEt/TNnmQsvuKLfQ3uN5ScJilEJgwlLv IOjowyWvT9iyMf3j8F1W01HSTU9mdg/sokc6dL+pdajwaTEsu7FTScEBZcpYoKGPmKaX AbqGlw38rMtsuVWRMAalFwnznrvyzbDXGSDVkTc1Mf4/+kH3odcjkYjnuprgOJ3wGTB5 2V0x06J7br9dWse8OdNLT4IrjVYhO2Kyd/XnbRrlmIuKBvKZkaGFm2ozUssk4rLRQtch A5SwuAwfLSXJNf93C6/U5lVLMQYY3n9dsc+NPJyUC4dSWm/Igof+bYSBHgE18Od96Op9 PkpQ== 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=l7+Z3mrIb8Sp0oVQFXi8OYd9zBdaHaRXhlQ8/Dy+0xg=; b=nNtzXqKUu0tfaN2r8xhYoOqIELK2h5Q/NgFFikOUxDVXvJM7nW5swkc8xozEVCLbrg n2KJpKFTHHwJ2+7rQ9wWxPW3HL2op8CBGADCf4vVBWj0b/vDrH0ON9BySErqUp0QbY5w 7TcPh0dwYG031f7i1LYFu7CdjXztHtarbnFoAvcAM0ETGF6DGj1lEmw9SNRzh56e5xw8 s03mR3VlzxWT5pr3ZOyKoYXV2HueotSCsbk36hFtqGlpWybrvtvi2duISH6PakwnnWBY aU0TWWOjXokBC5ye3aLUvVP+qWkvHHB7uwrxOcNhOK8lghxVpKepS5zi/akCSA7Y9yho jA6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w7si6232236ejn.180.2020.11.16.09.56.07; Mon, 16 Nov 2020 09:56:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S2388168AbgKPRxW (ORCPT + 99 others); Mon, 16 Nov 2020 12:53:22 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:43406 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732758AbgKPRxV (ORCPT ); Mon, 16 Nov 2020 12:53:21 -0500 Received: by mail-ot1-f66.google.com with SMTP id y22so16846139oti.10; Mon, 16 Nov 2020 09:53:20 -0800 (PST) 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; bh=l7+Z3mrIb8Sp0oVQFXi8OYd9zBdaHaRXhlQ8/Dy+0xg=; b=Ryru2wbXXLNUWNAzbJoowtDcA3rIoCtvzq+d6RI51iTi9x2HN6U51B8sjI8SL5C1X5 4RL5QcRY0gHZY4tGfn4/Ql+EcEv0ke95qdMfCLM5gc+nYXBbtjH+yWPqQIjbzyiEIrg9 GOWe+a2N569WEYeufSuXIYC5ykHkA+jLYD1Fo1bk7Oe4n1z5xEJ2BuWNUVOgfUT/yXjx 81veXU1KG626WOauEgLizN+B78Iulj5KWrMLt5/uIJjFblb4HVwiOhZtY64d8hfNd9R2 KgbFN7eIuvBouIGrIKGaXhN1xZOkW6nILqlbNjiVBbzn8b7YCcP/pxuelus4CzKm8POC XlsQ== X-Gm-Message-State: AOAM532EgA8GbM0IRe/DUGQB8jJSwfxwz/O6AXthgplbzr4Owb2qFzX1 ttT6oBgwwmlYnhT3QJiLIA1NaSZ9pvQUU/yGs9k= X-Received: by 2002:a9d:171a:: with SMTP id i26mr345705ota.260.1605549200640; Mon, 16 Nov 2020 09:53:20 -0800 (PST) MIME-Version: 1.0 References: <20201007171024.GA3252529@bjorn-Precision-5520> In-Reply-To: <20201007171024.GA3252529@bjorn-Precision-5520> From: "Rafael J. Wysocki" Date: Mon, 16 Nov 2020 18:53:09 +0100 Message-ID: Subject: Re: [PATCH] PCI: Disable PTM during suspend on Intel PCI bridges To: Bjorn Helgaas Cc: "Rafael J. Wysocki" , "David E. Box" , Bjorn Helgaas , Len Brown , Linux PCI , Linux PM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 7, 2020 at 7:10 PM Bjorn Helgaas wrote: > > On Wed, Oct 07, 2020 at 06:53:16PM +0200, Rafael J. Wysocki wrote: > > On Wed, Oct 7, 2020 at 6:49 PM David E. Box wrote: > > > > > > On Intel Platform Controller Hubs (PCH) since Cannon Lake, the Precision > > > Time Measurement (PTM) capability can prevent PCIe root ports from power > > > gating during suspend-to-idle, causing increased power consumption on > > > systems that suspend using Low Power S0 Idle [1]. The issue is yet to be > > > root caused but believed to be coming from a race condition in the suspend > > > flow as the incidence rate varies for different platforms on Linux but the > > > issue does not occur at all in other operating systems. For now, disable > > > the feature on suspend on all Intel root ports and enable again on resume. > > > > IMV it should also be noted that there is no particular reason why PTM > > would need to be enabled while the whole system is suspended. At > > least it doesn't seem to be particularly useful in that state. > > Is this a hardware erratum? If not, and this is working as designed, > it sounds like we'd need to apply this quirk to every device that > supports PTM. That's not really practical. Why not? It looks like the capability should be saved by pci_save_state() (it isn't ATM, which appears to be a mistake) and restored by pci_restore_state(), so if that is implemented, the saving can be combined with the disabling in principle. > The bugzilla says "there is no erratum as this does not affect > Windows," but that doesn't answer the question. What I want to know > is whether this is a *hardware* defect and whether it will be fixed in > future hardware. I cannot answer this question, sorry. ATM we only know that certain SoCs may not enter the deepest idle state if PTM is enabled on some PCIe root ports during suspend. Disabling PTM on those ports while suspending helps and hence the patch. It doesn't appear to qualify as a "hardware defect". > If it's a "wont-fix" hardware issue, we can just disable PTM > completely on Intel hardware and we won't have to worry about it > during suspend. I'm not following the logic here, sorry again. First of all, there are systems that never suspend, so why would they be affected by the remedy (whatever it is)? Second, it is not about the suspend failing entirely. It's about being able to make the system draw less power while suspended. Generally, if someone said "I can make the system draw less power while suspended if I disable PCIe feature X during suspend", would you disregard that?