Messages in this thread | | | Date | Thu, 28 Jan 1999 21:54:12 +0100 | From | Martin Mares <> | Subject | Re: kmalloc |
| |
Hello,
> 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/
| |