From: Bjorn Helgaas <bhelgaas@google.com>
To: Emmanuel Grumbach <egrumbach@gmail.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>,
Stanislaw Gruszka <sgruszka@redhat.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
John Linville <linville@tuxdriver.com>,
Roman Yepishev <roman.yepishev@gmail.com>,
"Guy, Wey-Yi" <wey-yi.w.guy@intel.com>,
Mike Miller <mike.miller@hp.com>,
iss_storagedev@hp.com, Guo-Fu Tseng <cooldavid@cooldavid.org>,
netdev@vger.kernel.org, Francois Romieu <romieu@fr.zoreil.com>,
nic_swsd@realtek.com, aacraid@adaptec.com,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org
Subject: Re: is L1 really disabled in iwlwifi
Date: Fri, 10 May 2013 16:52:57 -0600 [thread overview]
Message-ID: <20130510225257.GA10847@google.com> (raw)
In-Reply-To: <CAErSpo6OCyTy19u6Xaf=xr0TSDriwCD3n-oMc7eJyLzuJ9d60g@mail.gmail.com>
[+cc Rafael, other pci_disable_link_state() users]
On Wed, May 01, 2013 at 11:13:15AM -0600, Bjorn Helgaas wrote:
> On Wed, May 1, 2013 at 2:31 AM, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
> > [from Bjorn's mail]
> >> In Emmanuel's case, we don't get _OSC control, so
> >> pci_disable_link_state() does nothing.
> >
> > Right, but this is true with the specific log I sent to you. Is it
> > possible that another platform / BIOS, we *will* get _OSC control and
> > that pci_disable_link_state() will actually do something? In that case
> > I would prefer not to remove the call to pcie_disable_link_state().
>
> Yes, absolutely, on many platforms we will get _OSC control, and
> pci_disable_link_state() will work as expected. The problem is that
> the driver doesn't have a good way to know whether pci_disable_link()
> did anything or not.
>
> Today I think we have:
>
> 1) If the BIOS grants the OS permission to control PCIe services via
> _OSC, pci_disable_link_state() works and L1 will be disabled.
>
> 2) If the BIOS does not grant permission, pci_disable_link_state()
> does nothing and L1 may be enabled or not depending on what
> configuration the BIOS did.
>
> If the device really doesn't work reliably when L1 is enabled, we're
> currently at the mercy of the BIOS -- if the BIOS enables L1 but
> doesn't grant us permission via _OSC, L1 will remain enabled (as it is
> on your system).
I propose the following patch. Any comments?
commit cd11e3f87c4d2777cf8921c0454500c9baa54b46
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Fri May 10 15:54:35 2013 -0600
PCI/ASPM: Allow drivers to disable ASPM unconditionally
Some devices have hardware problems related to using ASPM. Drivers for
these devices use pci_disable_link_state() to prevent their device from
entering L0s or L1. But on platforms where the OS doesn't have permission
to manage ASPM, pci_disable_link_state() does nothing, and the driver has
no way to know this.
Therefore, if the BIOS enables ASPM but declines (either via the FADT
ACPI_FADT_NO_ASPM bit or the _OSC method) to allow the OS to manage it,
the device can still use ASPM and trip over the hardware issue.
This patch makes pci_disable_link_state() disable ASPM unconditionally,
regardless of whether the OS has permission to manage ASPM in general.
Reported-by: Emmanuel Grumbach <egrumbach@gmail.com>
Reference: https://lkml.kernel.org/r/CANUX_P3F5YhbZX3WGU-j1AGpbXb_T9Bis2ErhvKkFMtDvzatVQ@mail.gmail.com
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57331
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index d320df6..9ef4ab8 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -718,15 +718,11 @@ void pcie_aspm_powersave_config_link(struct pci_dev *pdev)
* pci_disable_link_state - disable pci device's link state, so the link will
* never enter specific states
*/
-static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem,
- bool force)
+static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
{
struct pci_dev *parent = pdev->bus->self;
struct pcie_link_state *link;
- if (aspm_disabled && !force)
- return;
-
if (!pci_is_pcie(pdev))
return;
@@ -757,13 +753,13 @@ static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem,
void pci_disable_link_state_locked(struct pci_dev *pdev, int state)
{
- __pci_disable_link_state(pdev, state, false, false);
+ __pci_disable_link_state(pdev, state, false);
}
EXPORT_SYMBOL(pci_disable_link_state_locked);
void pci_disable_link_state(struct pci_dev *pdev, int state)
{
- __pci_disable_link_state(pdev, state, true, false);
+ __pci_disable_link_state(pdev, state, true);
}
EXPORT_SYMBOL(pci_disable_link_state);
@@ -781,7 +777,7 @@ void pcie_clear_aspm(struct pci_bus *bus)
__pci_disable_link_state(child, PCIE_LINK_STATE_L0S |
PCIE_LINK_STATE_L1 |
PCIE_LINK_STATE_CLKPM,
- false, true);
+ false);
}
}
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Matthew Garrett
<matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>,
Stanislaw Gruszka
<sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-wireless
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
John Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
Roman Yepishev
<roman.yepishev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Guy,
Wey-Yi" <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Mike Miller <mike.miller-VXdhtT5mjnY@public.gmane.org>,
iss_storagedev-VXdhtT5mjnY@public.gmane.org,
Guo-Fu Tseng <cooldavid-eHdHF5TYP0iWVfeAwA7xHQ@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Francois Romieu <romieu-W8zweXLXuWQS+FvcfC7Uqw@public.gmane.org>,
nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org,
aacraid-ugMvIWC9OiRBDgjK7y7TUQ@public.gmane.org,
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: is L1 really disabled in iwlwifi
Date: Fri, 10 May 2013 16:52:57 -0600 [thread overview]
Message-ID: <20130510225257.GA10847@google.com> (raw)
In-Reply-To: <CAErSpo6OCyTy19u6Xaf=xr0TSDriwCD3n-oMc7eJyLzuJ9d60g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[+cc Rafael, other pci_disable_link_state() users]
On Wed, May 01, 2013 at 11:13:15AM -0600, Bjorn Helgaas wrote:
> On Wed, May 1, 2013 at 2:31 AM, Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > [from Bjorn's mail]
> >> In Emmanuel's case, we don't get _OSC control, so
> >> pci_disable_link_state() does nothing.
> >
> > Right, but this is true with the specific log I sent to you. Is it
> > possible that another platform / BIOS, we *will* get _OSC control and
> > that pci_disable_link_state() will actually do something? In that case
> > I would prefer not to remove the call to pcie_disable_link_state().
>
> Yes, absolutely, on many platforms we will get _OSC control, and
> pci_disable_link_state() will work as expected. The problem is that
> the driver doesn't have a good way to know whether pci_disable_link()
> did anything or not.
>
> Today I think we have:
>
> 1) If the BIOS grants the OS permission to control PCIe services via
> _OSC, pci_disable_link_state() works and L1 will be disabled.
>
> 2) If the BIOS does not grant permission, pci_disable_link_state()
> does nothing and L1 may be enabled or not depending on what
> configuration the BIOS did.
>
> If the device really doesn't work reliably when L1 is enabled, we're
> currently at the mercy of the BIOS -- if the BIOS enables L1 but
> doesn't grant us permission via _OSC, L1 will remain enabled (as it is
> on your system).
I propose the following patch. Any comments?
commit cd11e3f87c4d2777cf8921c0454500c9baa54b46
Author: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Date: Fri May 10 15:54:35 2013 -0600
PCI/ASPM: Allow drivers to disable ASPM unconditionally
Some devices have hardware problems related to using ASPM. Drivers for
these devices use pci_disable_link_state() to prevent their device from
entering L0s or L1. But on platforms where the OS doesn't have permission
to manage ASPM, pci_disable_link_state() does nothing, and the driver has
no way to know this.
Therefore, if the BIOS enables ASPM but declines (either via the FADT
ACPI_FADT_NO_ASPM bit or the _OSC method) to allow the OS to manage it,
the device can still use ASPM and trip over the hardware issue.
This patch makes pci_disable_link_state() disable ASPM unconditionally,
regardless of whether the OS has permission to manage ASPM in general.
Reported-by: Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reference: https://lkml.kernel.org/r/CANUX_P3F5YhbZX3WGU-j1AGpbXb_T9Bis2ErhvKkFMtDvzatVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57331
Signed-off-by: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index d320df6..9ef4ab8 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -718,15 +718,11 @@ void pcie_aspm_powersave_config_link(struct pci_dev *pdev)
* pci_disable_link_state - disable pci device's link state, so the link will
* never enter specific states
*/
-static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem,
- bool force)
+static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
{
struct pci_dev *parent = pdev->bus->self;
struct pcie_link_state *link;
- if (aspm_disabled && !force)
- return;
-
if (!pci_is_pcie(pdev))
return;
@@ -757,13 +753,13 @@ static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem,
void pci_disable_link_state_locked(struct pci_dev *pdev, int state)
{
- __pci_disable_link_state(pdev, state, false, false);
+ __pci_disable_link_state(pdev, state, false);
}
EXPORT_SYMBOL(pci_disable_link_state_locked);
void pci_disable_link_state(struct pci_dev *pdev, int state)
{
- __pci_disable_link_state(pdev, state, true, false);
+ __pci_disable_link_state(pdev, state, true);
}
EXPORT_SYMBOL(pci_disable_link_state);
@@ -781,7 +777,7 @@ void pcie_clear_aspm(struct pci_bus *bus)
__pci_disable_link_state(child, PCIE_LINK_STATE_L0S |
PCIE_LINK_STATE_L1 |
PCIE_LINK_STATE_CLKPM,
- false, true);
+ false);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-05-10 22:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 8:41 is L1 really disabled in iwlwifi Emmanuel Grumbach
2013-03-04 13:44 ` John W. Linville
2013-03-04 13:49 ` Stanislaw Gruszka
2013-03-04 14:57 ` Emmanuel Grumbach
2013-03-04 15:11 ` John W. Linville
2013-03-04 15:48 ` Stanislaw Gruszka
2013-03-04 17:58 ` Emmanuel Grumbach
2013-03-17 15:59 ` Roman Yepishev
2013-03-29 18:24 ` Bjorn Helgaas
2013-03-30 18:38 ` Emmanuel Grumbach
2013-03-30 21:26 ` Bjorn Helgaas
2013-04-02 11:10 ` Emmanuel Grumbach
2013-04-02 11:12 ` Emmanuel Grumbach
2013-04-07 12:23 ` Emmanuel Grumbach
2013-04-08 16:28 ` Bjorn Helgaas
2013-04-09 5:29 ` Emmanuel Grumbach
2013-04-30 10:57 ` Emmanuel Grumbach
2013-04-30 22:45 ` Bjorn Helgaas
2013-04-30 22:55 ` Matthew Garrett
2013-05-01 8:31 ` Emmanuel Grumbach
2013-05-01 17:13 ` Bjorn Helgaas
2013-05-10 22:52 ` Bjorn Helgaas [this message]
2013-05-10 22:52 ` Bjorn Helgaas
2013-05-11 20:26 ` Rafael J. Wysocki
2013-05-11 20:26 ` Rafael J. Wysocki
2013-05-11 20:22 ` Matthew Garrett
2013-05-11 20:22 ` Matthew Garrett
2013-05-11 20:22 ` Matthew Garrett
2013-05-16 22:55 ` Bjorn Helgaas
2013-05-17 5:49 ` Emmanuel Grumbach
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=20130510225257.GA10847@google.com \
--to=bhelgaas@google.com \
--cc=aacraid@adaptec.com \
--cc=cooldavid@cooldavid.org \
--cc=egrumbach@gmail.com \
--cc=iss_storagedev@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=matthew.garrett@nebula.com \
--cc=mike.miller@hp.com \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=rjw@sisk.pl \
--cc=roman.yepishev@gmail.com \
--cc=romieu@fr.zoreil.com \
--cc=sgruszka@redhat.com \
--cc=wey-yi.w.guy@intel.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.