From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Robert Hancock <hancockr@shaw.ca>,
Andrew Morton <akpm@linux-foundation.org>,
avuton@gmail.com, yakui.zhao@intel.com, shaohua.li@intel.com,
trenn@suse.de,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
alsa-devel@alsa-project.org
Subject: Re: a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card
Date: Wed, 27 Feb 2008 10:43:47 -0700 [thread overview]
Message-ID: <200802271043.47763.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0802141620380.6110@woody.linux-foundation.org>
On Thursday 14 February 2008 05:40:36 pm Linus Torvalds wrote:
>
> That said, if we really want to handle this, we could certainly add a
> whole new ioresource flag bit that says "allow inserting resources into
> this", and we could set that bit not just for the PnP reservations
> themselves, but in PCI bus resources too.
>
> Basically, there are two different ways of inserting a resource:
>
> - the "register this subresource" thing that "request_resource()" does,
> which just works on the one given resource and honors the BUSY bit.
>
> - the "insert this resource into the tree" (insert_resource()) that
> starts from the root and tries to find the right location. It honors
> the BUSY bit too, but we could extend it to _only_ extend into
> resources that allow it.
I guess it's time to get back to this problem.
I don't want to make PNP insert resources only at the root. That
would avoid the ALSA problem because the enclosing PCI resource is
allocated first, but it also precludes us from dealing with lots of
valid ACPI information. ACPI can describe layers of bridges and
devices behind them. It don't think we should throw away that
information just to solve this problem.
And I don't really want to add IORESOURCE_INSERT. It's probably a
useful idea, but I don't think it helps solve *this* problem. We'd
have to mark both the PCI and the PNP regions as "insert", and I
think we'd end up with the exact same situation we have today:
febf8000-febfbfff : 0000:00:1b.0 -- from pcibios_resource_survey (!busy)
febfa000-febfac00 : pnp 00:08 -- from PNP system driver (!busy)
febf8000-febfbfff : ICH HD audio -- fails; spans part of PNP region
I'm back to the quirk idea, which is still ugly but seems the most
straightforward to me. Here's my current patch (this won't apply
directly because we'd have to revert the Supermicro-specific quirk
first).
Excuse me a minute while I put on my asbestos underwear.
Bjorn
PNP: disable PNP motherboard resources that overlap PCI BARs
Some BIOSes have PNP motherboard devices with resources that
partially overlap PCI BARs. The PNP system driver claims these
motherboard resources, which prevents the normal PCI driver from
requesting them later.
This patch disables the PNP resources that conflict with PCI BARs
so they won't be claimed by the PNP system driver.
Of course, this only works if PCI devices have already been enumerated.
Currently, PCI devices are discovered before any PNP init via this path:
acpi_pci_root_init() -> acpi_pci_root_add() -> pci_acpi_scan_root() ->
pci_scan_bus_parented() -> pci_scan_child_bus() -> ...
References:
https://bugzilla.redhat.com/show_bug.cgi?id=280641
https://bugzilla.redhat.com/show_bug.cgi?id=313491
http://lkml.org/lkml/2008/1/9/449
http://thread.gmane.org/gmane.linux.acpi.devel/27312
http://lkml.org/lkml/2008/1/27/168
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work7/drivers/pnp/quirks.c
===================================================================
--- work7.orig/drivers/pnp/quirks.c 2008-02-27 10:17:40.000000000 -0700
+++ work7/drivers/pnp/quirks.c 2008-02-27 10:19:35.000000000 -0700
@@ -108,6 +108,77 @@
"pnp: SB audio device quirk - increasing port range\n");
}
+
+#include <linux/pci.h>
+
+static void quirk_system_pci_resources(struct pnp_dev *dev)
+{
+ struct pci_dev *pdev = NULL;
+ resource_size_t pnp_start, pnp_end, pci_start, pci_end;
+ int i, j;
+
+ /*
+ * Some BIOSes have PNP motherboard devices with resources that
+ * partially overlap PCI BARs. The PNP system driver claims these
+ * motherboard resources, which prevents the normal PCI driver from
+ * requesting them later.
+ *
+ * This patch disables the PNP resources that conflict with PCI BARs
+ * so they won't be claimed by the PNP system driver.
+ */
+ for_each_pci_dev(pdev) {
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM) ||
+ pci_resource_len(pdev, i) == 0)
+ continue;
+
+ pci_start = pci_resource_start(pdev, i);
+ pci_end = pci_resource_end(pdev, i);
+ for (j = 0; j < PNP_MAX_MEM; j++) {
+ if (!pnp_mem_valid(dev, j) ||
+ pnp_mem_len(dev, j) == 0)
+ continue;
+
+ pnp_start = pnp_mem_start(dev, j);
+ pnp_end = pnp_mem_end(dev, j);
+
+ /*
+ * If the PNP region doesn't overlap the PCI
+ * region at all, there's no problem.
+ */
+ if (pnp_end < pci_start || pnp_start > pci_end)
+ continue;
+
+ /*
+ * If the PNP region completely encloses (or is
+ * at least as large as) the PCI region, that's
+ * also OK. For example, this happens when the
+ * PNP device describes a bridge with PCI
+ * behind it.
+ */
+ if (pnp_start <= pci_start &&
+ pnp_end >= pci_end)
+ continue;
+
+ /*
+ * Otherwise, the PNP region overlaps *part* of
+ * the PCI region, and that might prevent a PCI
+ * driver from requesting its resources.
+ */
+ dev_warn(&dev->dev, "mem resource "
+ "(0x%llx-0x%llx) overlaps %s BAR %d "
+ "(0x%llx-0x%llx), disabling\n",
+ (unsigned long long) pnp_start,
+ (unsigned long long) pnp_end,
+ pci_name(pdev), i,
+ (unsigned long long) pci_start,
+ (unsigned long long) pci_end);
+ pnp_mem_flags(dev, j) = 0;
+ }
+ }
+ }
+}
+
/*
* PnP Quirks
* Cards or devices that need some tweaking due to incomplete resource info
@@ -128,6 +199,8 @@
{"CTL0043", quirk_sb16audio_resources},
{"CTL0044", quirk_sb16audio_resources},
{"CTL0045", quirk_sb16audio_resources},
+ {"PNP0c01", quirk_system_pci_resources},
+ {"PNP0c02", quirk_system_pci_resources},
{""}
};
next prev parent reply other threads:[~2008-02-27 17:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.Kmpf0B4W44W1VefIME7+BnfUouY@ifi.uio.no>
2008-01-27 18:17 ` Robert Hancock
2008-01-31 22:58 ` Andrew Morton
2008-02-01 0:14 ` Robert Hancock
2008-02-01 0:50 ` Linus Torvalds
2008-02-04 17:39 ` Bjorn Helgaas
2008-02-04 18:18 ` Linus Torvalds
2008-02-04 20:41 ` Bjorn Helgaas
2008-02-04 21:16 ` Linus Torvalds
2008-02-05 7:03 ` Bjorn Helgaas
2008-02-05 16:46 ` Avuton Olrich
2008-02-05 18:15 ` Linus Torvalds
2008-02-05 20:12 ` Bjorn Helgaas
2008-02-13 22:33 ` Avuton Olrich
2008-02-14 18:51 ` Bjorn Helgaas
2008-02-14 19:42 ` Linus Torvalds
2008-02-14 20:07 ` Bjorn Helgaas
2008-02-14 20:26 ` Linus Torvalds
2008-02-14 21:01 ` Bjorn Helgaas
2008-02-14 21:37 ` Linus Torvalds
2008-02-14 22:28 ` Bjorn Helgaas
2008-02-14 22:57 ` Linus Torvalds
2008-02-14 23:14 ` Linus Torvalds
2008-02-15 0:13 ` Bjorn Helgaas
2008-02-15 0:40 ` Linus Torvalds
2008-02-27 17:43 ` Bjorn Helgaas [this message]
2008-01-27 14:40 Avuton Olrich
2008-01-27 21:50 ` Linus Torvalds
2008-01-28 1:15 ` Shaohua Li
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=200802271043.47763.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=akpm@linux-foundation.org \
--cc=alsa-devel@alsa-project.org \
--cc=avuton@gmail.com \
--cc=hancockr@shaw.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=trenn@suse.de \
--cc=yakui.zhao@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®