From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Andrew Patterson <andrew.patterson@hp.com>
Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
matthew@wil.cx, bjorn.helgaas@hp.com
Subject: Re: [PATCH v2 0/6] call _OSC support during root bridge discovery
Date: Thu, 30 Oct 2008 18:08:31 +0900 [thread overview]
Message-ID: <4909798F.6010604@jp.fujitsu.com> (raw)
In-Reply-To: <20081030052746.10259.22045.stgit@bob.kio>
Andrew Patterson wrote:
> This is v2 of the "call _OSC support during root bridge discovery"
> patchset. At Bjorn Helgaas's suggestion, I have merged all the MSI
> handling patches into one patch. Kenji Kaneshige also noted that I was
> not checking aspm_disabled before setting ASPM _OSC capabilities. This
> has been fixed.
>
> Kenji also noted that the pci_msi_enable can be changed in various
> quirks after root bridge discovery, resulting in the incorrect setting
> of the MSI _OSC capability. I do not yet have a solution for this problem.
>
Unfortunately, I don't have good idea about it yet too. In addition,
I don't understand how to handle the case if a feature is supported
but disabled by OS, from the PCI firmware spec.
If we should not set _OSC capabilities when it is supported but
disabled by OS, maybe we need also consider what we should do for
OSC_EXT_PCI_CONFIG_SUPPORT and OSC_PCI_SEGMENT_GROUPS_SUPPORT
if mmconfig is disabled, as well as aspm_disabled and pci_msi_enable.
By the way, Taku Izumi plan to post some patches to reduce _OSC
evaluation for _OSC control soon. I'm appreciate it if you will try
it on your big server.
Thanks,
Kenji Kaneshige
> I still need Matthew Wilcox to sign off on the first two patches.
>
>
> I recently reported a problem where a machine with close to a 100 PCIe
> root bridges was taking half an hour to just call _OSC. The root
> cause is the AER code calling:
>
> pcie_osc_support_set(OSC_EXT_PCI_CONFIG_SUPPORT);
>
> for each bridge. The pcie_osc_support_set() function also iterates
> over each bridge, so _OSC is called a quadratic number of times.
>
> One solution to this problem would be to just move the call to
> pcie_osc_support_set() to aer_service_init(), so _OSC support is only
> called on each bridge once.
>
> Matthew Wilcox came up with a better solution. He says "Why should a
> driver be calling pcie_osc_support_set() anyway? This is something
> the PCI core should be taking care of for it."
>
> Matthew provided a patch for this solution that I massaged into the
> following patch series.
>
> It creates a new function (pci_acpi_osc_support()) which is called
> from pci_root.c before we call any other methods on the device (as
> recommended by the ACPI spec). Since we know what capabilities the
> system supports, individual modules do not now need to inform the core
> of their support for various capabilities.
>
> Some work that still needs to be done (provided by Matthew):
>
> o All the existing _OSC code should be moved from pci-acpi.c to
> pci_root.c. I also think the acpi_osc_data should be made part of
> the acpi_pci_root struct, eliminating a separate allocation.
>
> o We could also use an interface that iterates over all existing
> busses calling _OSC with new flags. Shouldn't be hard, once it's
> integrated into pci_root.c.
>
> o Further ahead, we don't actually check that the bits we asked for
> (in 'control') were actually granted to us. The PCI firmware spec
> is quite explicit about interdependencies amongst the bits.
>
> o We also need to re-evaluate _OSC when coming out of S4.
>
> This patch series duplicates currently functionality while removing
> our quadratic problem. I believe that it can be applied now while the
> above new functionality can be implemented some time in the future.
>
> This patch series applies to the linux-next branch of pci-2.6 git
> repository. I expect it will also work with linux-next.
>
> Diff stats:
>
> drivers/acpi/pci_root.c | 12 ++++++++++++
> drivers/pci/msi.c | 31 +++++++++++-------------------
> drivers/pci/pci-acpi.c | 37 +++++++++++++-----------------------
> drivers/pci/pci.c | 2 --
> drivers/pci/pci.h | 2 --
> drivers/pci/pcie/aer/aerdrv_acpi.c | 1 -
> drivers/pci/pcie/aspm.c | 27 +++++++++-----------------
> include/linux/pci-acpi.h | 14 +++-----------
> include/linux/pci.h | 14 ++++++++++++++
> 9 files changed, 62 insertions(+), 78 deletions(-)
>
> Commits:
>
> - Include missing acpi.h file in pci-acpi.h.
> - Call _OSC support during root bridge discovery.
> - PCIe ASPM _OSC support capabilities called when root bridge added.
> - PCIe AER _OSC support capabilities called when root bridge added.
> - PCI MSI _OSC support capabilities called when root bridge added.
> - Remove obsolete _OSC capability support functions.
>
next prev parent reply other threads:[~2008-10-30 9:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-30 5:27 [PATCH v2 0/6] call _OSC support during root bridge discovery Andrew Patterson
2008-10-30 5:27 ` [PATCH 1/6] PCI, ACPI: include missing acpi.h file in pci-acpi.h Andrew Patterson
2008-10-30 5:27 ` [PATCH 2/6] ACPI, PCI: call _OSC support during root bridge discovery Andrew Patterson
2008-10-30 5:28 ` [PATCH 3/6] ACPI, PCI: PCIe ASPM _OSC support capabilities called when root bridge added Andrew Patterson
2008-10-30 5:28 ` [PATCH 4/6] ACPI, PCI: PCIe AER " Andrew Patterson
2008-10-30 5:28 ` [PATCH 5/6] ACPI, PCI: PCI MSI " Andrew Patterson
2008-10-30 5:28 ` [PATCH 6/6] PCI, ACPI: remove obsolete _OSC capability support functions Andrew Patterson
2008-10-30 9:08 ` Kenji Kaneshige [this message]
2008-10-31 16:28 ` [PATCH v2 0/6] call _OSC support during root bridge discovery Andrew Patterson
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=4909798F.6010604@jp.fujitsu.com \
--to=kaneshige.kenji@jp.fujitsu.com \
--cc=andrew.patterson@hp.com \
--cc=bjorn.helgaas@hp.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
/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.