lkml.org 
[lkml]   [2004]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Intel Alder IOAPIC fix


On Mon, 12 Jan 2004, James Bottomley wrote:
>
> So BAR0 is actually the location of the second I/O APIC's mapped address
> range (which we've already covered with a fixmap from the MP TABLE).
> I've no idea what the other four BARs all with addresses at 0xfffffc00
> are doing.
>
> The only way to prevent the current code (in arch/i386/pci/i386.c) from
> reassigning this range seems to be to set the resource start to zero.

Ok. What I think we should do is to have a special quirk for chips like
this that just _force_ the BAR values into the resource allocation table,
and ignore things like the existing BIOS-marked allocations - because
obviously the BIOS-marked ones are going to overlap.

This is where that "insert_resource()" thing comes in. Something like this
might just work as a quirk:

adler_quirk(struct pci_dev *dev)
{
int i;

for (i = 0; i < 6; i++) {
if (!pci_resource_start(dev, i))
continue;
if (!pci_resource_len(dev, i))
continue;
insert_resource(&iomem_resource, dev->resource + i);
}
}

and then make sure that the PCI layer doesn't try to re-allocate the
resource some other way (I forget - maybe it already notices when the
resource has already been inserted into the resource tree - otherwise you
might need to add the code that says "if this resource is already
inserted, don't try to reallocate it").

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.077 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site