From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Subject: Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports Date: Mon, 1 Apr 2013 14:53:12 -0600 Message-ID: References: <2282655.IicBMMa6jN@vostro.rjw.lan> <1378320.ernsY1JWPv@vostro.rjw.lan> <3943547.m5K1tfygWn@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from mail-oa0-f53.google.com ([209.85.219.53]:43124 "EHLO mail-oa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757146Ab3DAUxc (ORCPT ); Mon, 1 Apr 2013 16:53:32 -0400 Received: by mail-oa0-f53.google.com with SMTP id m17so2314303oag.40 for ; Mon, 01 Apr 2013 13:53:32 -0700 (PDT) In-Reply-To: <3943547.m5K1tfygWn@vostro.rjw.lan> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: "Rafael J. Wysocki" Cc: Martin Mokrejs , ACPI Devel Maling List , Len Brown , Matthew Garrett , Sarah Sharp , LKML , "linux-pci@vger.kernel.org" , Zheng Yan On Mon, Apr 1, 2013 at 2:51 PM, Rafael J. Wysocki wrote: > On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote: >> [+cc Zheng, who added this with 71a83bd727] >> >> On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki wrote: >> > From: Rafael J. Wysocki >> > >> > The runtime PM of PCIe ports turns out to be quite fragile, as in >> > some cases things work while in some other cases they don't and we >> > don't seem to have a good way to determine whether or not they are >> > going to work in advance. >> >> Do you have any references to problems encountered when enabling >> runtime PM for PCIe ports? That information will be useful to anybody >> who wants to take another crack at getting this working. > > Well, bug 53811 is one example and problems recently reported by > Martin are another. Do you want me to dig deeper? OK, I got this one: https://bugzilla.kernel.org/show_bug.cgi?id=53811 Martin has reported a lot of problems lately, and I don't know which are related to runtime PM for PCIe ports. I was hoping for a couple URLs to put in the changelog so that when somebody gets the itch to make this work, they have some useful info to start from. If you point me at a specific message, I'll dig up an archive URL for it. Otherwise, I'm afraid we'll just oscillate between "enable PM, find bug, disable PM, enable PM, find same bug, disable PM, etc..." Bjorn >> > For this reason, avoid enabling runtime PM for PCIe ports by >> > keeping their runtime PM reference counters always above 0 for the >> > time being. >> > >> > Signed-off-by: Rafael J. Wysocki >> > --- >> > >> > This version also removes the no longer necessary (and empty anyway) >> > port_runtime_pm_black_list[] table. >> > >> > Thanks, >> > Rafael >> > >> > --- >> > drivers/pci/pcie/portdrv_pci.c | 13 ------------- >> > 1 file changed, 13 deletions(-) >> > >> > Index: linux-pm/drivers/pci/pcie/portdrv_pci.c >> > =================================================================== >> > --- linux-pm.orig/drivers/pci/pcie/portdrv_pci.c >> > +++ linux-pm/drivers/pci/pcie/portdrv_pci.c >> > @@ -185,14 +185,6 @@ static const struct dev_pm_ops pcie_port >> > #endif /* !PM */ >> > >> > /* >> > - * PCIe port runtime suspend is broken for some chipsets, so use a >> > - * black list to disable runtime PM for these chipsets. >> > - */ >> > -static const struct pci_device_id port_runtime_pm_black_list[] = { >> > - { /* end: all zeroes */ } >> > -}; >> > - >> > -/* >> > * pcie_portdrv_probe - Probe PCI-Express port devices >> > * @dev: PCI-Express port device being probed >> > * >> > @@ -225,16 +217,11 @@ static int pcie_portdrv_probe(struct pci >> > * it by default. >> > */ >> > dev->d3cold_allowed = false; >> > - if (!pci_match_id(port_runtime_pm_black_list, dev)) >> > - pm_runtime_put_noidle(&dev->dev); >> > - >> > return 0; >> > } >> > >> > static void pcie_portdrv_remove(struct pci_dev *dev) >> > { >> > - if (!pci_match_id(port_runtime_pm_black_list, dev)) >> > - pm_runtime_get_noresume(&dev->dev); >> > pcie_port_device_remove(dev); >> > pci_disable_device(dev); >> > } >> > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center.