All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Matthew Garrett <mjg@redhat.com>,
	linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pci: Rework ASPM disable code
Date: Fri, 11 Nov 2011 09:28:11 -0800	[thread overview]
Message-ID: <20111111092811.54a03027@jbarnes-desktop> (raw)
In-Reply-To: <CACna6rwxWUtfa2uz1hXVUthSpJF6SKP3V-ERt0=3oVQ2KKEo=g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

On Fri, 11 Nov 2011 10:49:02 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:

> 2011/11/10 Matthew Garrett <mjg@redhat.com>:
> > Right now we forcibly clear ASPM state on all devices if the BIOS indicates
> > that the feature isn't supported. Based on the Microsoft presentation
> > "PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
> > that this may be an error. The implication is that unless the platform
> > grants full control via _OSC, Windows will not touch any PCIe features -
> > including ASPM. In that case clearing ASPM state would be an error unless
> > the platform has granted us that control.
> >
> > This patch reworks the ASPM disabling code such that the actual clearing
> > of state is triggered by a successful handoff of PCIe control to the OS.
> > The general ASPM code undergoes some changes in order to ensure that the
> > ability to clear the bits isn't overridden by ASPM having already been
> > disabled. Further, this theoretically now allows for situations where
> > only a subset of PCIe roots hand over control, leaving the others in the
> > BIOS state.
> >
> > It's difficult to know for sure that this is the right thing to do -
> > there's zero public documentation on the interaction between all of these
> > components. But enough vendors enable ASPM on platforms and then set this
> > bit that it seems likely that they're expecting the OS to leave them alone.
> >
> > Measured to save around 5W on an idle Thinkpad X220.
> >
> > Signed-off-by: Matthew Garrett <mjg@redhat.com>
> 
> Does it make sense to CC stable? To get it into 2.6.38+?

It's a pretty serious change that affects a lot of platforms, so I'd be
nervous about sticking it in stable right away.  Maybe after some soak
time upstream and/or broad testing in distros.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2011-11-11 17:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-10 21:38 [PATCH] pci: Rework ASPM disable code Matthew Garrett
2011-11-11  9:49 ` Rafał Miłecki
2011-11-11 17:28   ` Jesse Barnes [this message]
2011-11-11 17:32     ` Greg KH
2011-11-11 17:33 ` Jesse Barnes

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=20111111092811.54a03027@jbarnes-desktop \
    --to=jbarnes@virtuousgeek.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mjg@redhat.com \
    --cc=zajec5@gmail.com \
    /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.