All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	"David E. Box" <david.e.box@linux.intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Len Brown <len.brown@intel.com>,
	Linux PCI <linux-pci@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI: Disable PTM during suspend on Intel PCI bridges
Date: Mon, 16 Nov 2020 18:53:09 +0100	[thread overview]
Message-ID: <CAJZ5v0gwSe=o_Ta0MR6XTn4BmHjs=ewTVJHe6OTp18ho+5h1Eg@mail.gmail.com> (raw)
In-Reply-To: <20201007171024.GA3252529@bjorn-Precision-5520>

On Wed, Oct 7, 2020 at 7:10 PM Bjorn Helgaas <helgaas@kernel.org> 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 <david.e.box@linux.intel.com> 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?

  reply	other threads:[~2020-11-16 17:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 16:48 [PATCH] PCI: Disable PTM during suspend on Intel PCI bridges David E. Box
2020-10-07 16:53 ` Rafael J. Wysocki
2020-10-07 17:10   ` Bjorn Helgaas
2020-11-16 17:53     ` Rafael J. Wysocki [this message]
2020-11-16 19:23       ` Bjorn Helgaas
2020-11-16 20:58         ` David E. Box
2020-11-17 12:54           ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJZ5v0gwSe=o_Ta0MR6XTn4BmHjs=ewTVJHe6OTp18ho+5h1Eg@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=david.e.box@linux.intel.com \
    --cc=helgaas@kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.