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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox