Now the kernel is trying to figure out which mechanism it should use
to directly (as apposed to the memory mapped way?) access the PCI
configuration space. Apparently, in the 2.0 and 2.1 specs which I
haven't been able to find describe a deprecated second mechanism, and
the kernel has to try to figure out which one to use. Anyway, it's
calling a function called pci_check_type1, the 2.6.22.9 version is
below, which is messing around with the CONFIG_ADDRESS and CONFIG_DATA
locations I mentioned before. I can't seem to figure out how it's
supposed to work. What would make sense is if the outb was after the
outl. Then, the outb would be passed to the underlying IO ports and
dropped or something if the config addresses worked this way, and if not
it would clobber part of the 0x80000000. Instead, I think they've pretty
much set up a test that can't fail. The only thing I can think of is
that this somehow differentiates it from the second mysterious method I
have yet to locate. Has anyone seen this before, know what's going on,
or know what that second mechanism is?
PS. I see my clone finished, so I'll poke at that after dinner.
Gabe
static int __init pci_check_type1(void)
{
unsigned long flags;
unsigned int tmp;
int works = 0;
local_irq_save(flags);
outb(0x01, 0xCFB);
tmp = inl(0xCF8);
outl(0x80000000, 0xCF8);
if (inl(0xCF8) == 0x80000000 && pci_sanity_check(&pci_direct_conf1)) {
works = 1;
}
outl(tmp, 0xCF8);
local_irq_restore(flags);
return works;
}
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
