> Indeed, but I'm probably too stupid and I would like to understand what
> the following code on the Alpha means (in arch/alpha/kernel/bios32.c,
> but there is something similar in Sparc64):
>
> pcibios_write_config_dword(bus->number, dev->devfn,
> off, base);
> new_io_reset(dev, off, orig_base);
>
> handle = PCI_HANDLE(bus->number) | base;
> dev->base_address[idx] = handle;
>
> Obviously, unless the code is needlessly obfuscated, dev->base_address
> will _not_ have the same value as the base register in the PCI
> configuration space. Shouldn't it be the same on PreP, where to access the
> MMIO at address 0x123456, the physical address is 0xC0123456 since the bridge
> subtracts 0xc0000000 from the address appearing on the CPU pins ?
This is exactly the reason why do we have dev->base_address[] and the
drivers use it instead of reading the addresses from the configuration space.
dev->base_address[] should contain addresses suitable as an argument to
ioremap() [after stripping off the region type in lower bits] and as a
file offset in /dev/mem.
> I've been trying to solve this problem but never got a clear answer. I had
> come to the conclusion that it should be:
>
> pci_read_config_dword(dev, PCI_BASE_ADDRESS_n, &base)
>
> dev->base_address[n] = base+0xc0000000 (adjusted by pcibios_fixup())
>
> address used in driver = ioremap(dev->base_address[n])
>
> in this case, lspci -v and lspci -vb do not display the same addresses.
Yes, this is the right way to go.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "If at first you don't succeed, redefine success."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/