From: David Miller <davem@davemloft.net>
To: sparclinux@vger.kernel.org
Subject: Re: Problems booting 2.6.18 on SunBlade 100/150
Date: Wed, 18 Oct 2006 20:37:42 +0000 [thread overview]
Message-ID: <20061018.133742.21927174.davem@davemloft.net> (raw)
In-Reply-To: <200401070729.56891.pkarlsen@mandriva.com>
From: "Jurij Smakov" <jurij@wooyd.org>
Date: Wed, 18 Oct 2006 12:38:38 -0700 (PDT)
> I've tried to build the patched Debian packages overnight, but the build
> failed for unrelated reasons. I'll try again tonight.
Jurij, please use this updated version of the patch
against 2.6.18, thanks.
[SPARC64]: Fix PCI memory space root resource on Hummingbird.
For Hummingbird PCI controllers, we should create the root
PCI memory space resource as the full 4GB area, and then
allocate the IOMMU DMA translation window out of there.
The old code just assumed that the IOMMU DMA translation base
to the top of the 4GB area was unusable. This is not true on
many systems such as SB100 and SB150, where the IOMMU DMA
translation window sits at 0xc0000000->0xdfffffff.
So what would happen is that any device mapped by the firmware
at the top section 0xe0000000->0xffffffff would get remapped
by Linux somewhere else leading to all kinds of problems and
boot failures.
While we're here, report more cases of OBP resource assignment
conflicts. The only truly valid ones are ROM resource conflicts.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/arch/sparc64/kernel/pci_common.c b/arch/sparc64/kernel/pci_common.c
index 7a59cc7..827ae30 100644
--- a/arch/sparc64/kernel/pci_common.c
+++ b/arch/sparc64/kernel/pci_common.c
@@ -330,19 +330,6 @@ #endif
return res;
}
-static int __init pdev_resource_collisions_expected(struct pci_dev *pdev)
-{
- if (pdev->vendor != PCI_VENDOR_ID_SUN)
- return 0;
-
- if (pdev->device = PCI_DEVICE_ID_SUN_RIO_EBUS ||
- pdev->device = PCI_DEVICE_ID_SUN_RIO_1394 ||
- pdev->device = PCI_DEVICE_ID_SUN_RIO_USB)
- return 1;
-
- return 0;
-}
-
static void __init pdev_record_assignments(struct pci_pbm_info *pbm,
struct pci_dev *pdev)
{
@@ -400,19 +387,23 @@ static void __init pdev_record_assignmen
pbm->parent->resource_adjust(pdev, res, root);
if (request_resource(root, res) < 0) {
+ int rnum;
+
/* OK, there is some conflict. But this is fine
* since we'll reassign it in the fixup pass.
*
- * We notify the user that OBP made an error if it
- * is a case we don't expect.
+ * Do not print the warning for ROM resources
+ * as such a conflict is quite common and
+ * harmless as the ROM bar is disabled.
*/
- if (!pdev_resource_collisions_expected(pdev)) {
- printk(KERN_ERR "PCI: Address space collision on region %ld "
+ rnum = (res - &pdev->resource[0]);
+ if (rnum != PCI_ROM_RESOURCE)
+ printk(KERN_ERR "PCI: Resource collision, "
+ "region %d "
"[%016lx:%016lx] of device %s\n",
- (res - &pdev->resource[0]),
+ rnum,
res->start, res->end,
pci_name(pdev));
- }
}
}
}
diff --git a/arch/sparc64/kernel/pci_sabre.c b/arch/sparc64/kernel/pci_sabre.c
index 4589185..f04c6d2 100644
--- a/arch/sparc64/kernel/pci_sabre.c
+++ b/arch/sparc64/kernel/pci_sabre.c
@@ -1196,7 +1196,7 @@ static void pbm_register_toplevel_resour
&pbm->mem_space);
}
-static void sabre_pbm_init(struct pci_controller_info *p, struct device_node *dp, u32 dma_begin)
+static void sabre_pbm_init(struct pci_controller_info *p, struct device_node *dp, u32 dma_start, u32 dma_end)
{
struct pci_pbm_info *pbm;
struct device_node *node;
@@ -1261,6 +1261,8 @@ static void sabre_pbm_init(struct pci_co
node = node->sibling;
}
if (simbas_found = 0) {
+ struct resource *rp;
+
/* No APBs underneath, probably this is a hummingbird
* system.
*/
@@ -1302,8 +1304,10 @@ static void sabre_pbm_init(struct pci_co
pbm->io_space.end = pbm->io_space.start + (1UL << 24) - 1UL;
pbm->io_space.flags = IORESOURCE_IO;
- pbm->mem_space.start = p->pbm_A.controller_regs + SABRE_MEMSPACE;
- pbm->mem_space.end = pbm->mem_space.start + (unsigned long)dma_begin - 1UL;
+ pbm->mem_space.start + (p->pbm_A.controller_regs + SABRE_MEMSPACE);
+ pbm->mem_space.end + (pbm->mem_space.start + ((1UL << 32UL) - 1UL));
pbm->mem_space.flags = IORESOURCE_MEM;
if (request_resource(&ioport_resource, &pbm->io_space) < 0) {
@@ -1315,6 +1319,17 @@ static void sabre_pbm_init(struct pci_co
prom_halt();
}
+ rp = kmalloc(sizeof(*rp), GFP_KERNEL);
+ if (!rp) {
+ prom_printf("Cannot allocate IOMMU resource.\n");
+ prom_halt();
+ }
+ rp->name = "IOMMU";
+ rp->start = pbm->mem_space.start + (unsigned long) dma_start;
+ rp->end = pbm->mem_space.start + (unsigned long) dma_end - 1UL;
+ rp->flags = IORESOURCE_BUSY;
+ request_resource(&pbm->mem_space, rp);
+
pci_register_legacy_regions(&pbm->io_space,
&pbm->mem_space);
}
@@ -1450,5 +1465,5 @@ void sabre_init(struct device_node *dp,
/*
* Look for APB underneath.
*/
- sabre_pbm_init(p, dp, vdma[0]);
+ sabre_pbm_init(p, dp, vdma[0], vdma[0] + vdma[1]);
}
next prev parent reply other threads:[~2006-10-18 20:37 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-07 6:29 Problems booting 2.6.18 on SunBlade 100/150 Per Øyvind Karlsen
2006-10-09 2:29 ` Jurij Smakov
2006-10-09 8:21 ` David Miller
2006-10-14 18:49 ` Jurij Smakov
2006-10-15 4:57 ` Jim Watson
2006-10-17 8:17 ` David Miller
2006-10-18 1:56 ` David Miller
2006-10-18 11:50 ` Jim Watson
2006-10-18 12:38 ` Jason Wever
2006-10-18 19:30 ` David Miller
2006-10-18 19:31 ` David Miller
2006-10-18 19:36 ` Per Øyvind Karlsen
2006-10-18 19:38 ` Jurij Smakov
2006-10-18 19:45 ` David Miller
2006-10-18 19:45 ` David Miller
2006-10-18 20:15 ` Per Øyvind Karlsen
2006-10-18 20:28 ` Per Øyvind Karlsen
2006-10-18 20:36 ` David Miller
2006-10-18 20:37 ` David Miller [this message]
2006-10-18 20:41 ` Per Øyvind Karlsen
2006-10-18 20:45 ` David Miller
2006-10-19 6:38 ` Jim Watson
2006-10-19 11:18 ` Per Øyvind Karlsen
2006-10-19 11:34 ` Jim Watson
2006-10-19 16:40 ` Jurij Smakov
2006-10-19 23:21 ` Riccardo Tortorici
2006-10-19 23:43 ` Jim Watson
2006-10-20 0:36 ` Riccardo Tortorici
2006-10-20 1:34 ` Jim Watson
2006-10-24 1:19 ` Jason Wever
2006-10-24 23:31 ` Per Øyvind Karlsen
2006-10-24 23:32 ` David Miller
2006-10-24 23:44 ` David Miller
2006-10-25 0:11 ` Per Øyvind Karlsen
2006-10-25 15:23 ` Per Øyvind Karlsen
2006-10-25 20:08 ` Per Øyvind Karlsen
2006-10-26 9:25 ` David Miller
2006-10-26 11:09 ` Per Øyvind Karlsen
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=20061018.133742.21927174.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=sparclinux@vger.kernel.org \
/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.