From: Meelis Roos <mroos@xxxxxxxx> Date: Tue, 1 Oct 2013 11:43:20 +0300 (EEST) >> > > That looks quite strange. I guess the kernel should map the ROM at the >> > > address OpenBoot/OF assigned to it. ( 10020000 ). >> > >> > The address you see is a raw physical I/O address, which is a concatenation >> > of the I/O window physical address for that PCI controller and the >> > PCI bus assigned address. >> > >> > This is what we store in the resource values. >> > >> > The pci_assign_resource() path must have some bug that causes the >> > resource values to be set incorrectly or similar. >> > >> > Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE) >> > before the pci_map_rom() call? >> >> [drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000 >> >> I am a little confused here. ROM addressis OK but after pci_map_rom it >> results in address that corresponds to another device? > > I read more code and tried a couple of more things. > > Using ofpci_debug=1 I get sensible output for scsi: > > PCI: scan_bus[/pci@1f,0/pci@1] bus no 2 > * /pci@1f,0/pci@1/scsi@1 > create device, devfn: 8, type: scsi-2 > class: 0x10000 device name: 0000:02:01.0 > parse addresses (40 bytes) @ fffff8003fedc1c0 > start: 1ff00002000, end: 1ff000020ff, i: 14 > start: 1ff00010000, end: 1ff0001ffff, i: 30 > adding to system ... > > adding to system refers to pci_device_add(dev, bus) and that does not > modify the PCI bus available windows in any way, at least by my reafing > of the PCI code, so the PCI code does not know the resource ranges are > now busy? I finally did some digging into this, and I think the issue is that sparc needs to do pci_claim_resource() calls over all the PCI device resources which are valid after we finish adding the PCI devices. I'll try to follow up with a patch some time next week. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
