Hi Bjorn, On Sun, 21 Feb 2010 22:07:37 -0700 Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > On Sat, 2010-02-20 at 21:18 +0900, Yoichi Yuasa wrote: > > Hi Ralf, > > > > On Sat, 20 Feb 2010 12:31:34 +0100 > > Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote: > > > > > Below 9f7670e4ddd940d95e48997c2da51614e5fde2cf, an old hack which I > > > committed in December '07 I think mostly for Cobalt machines. This is > > > now getting in the way - in fact the whole loop in > > > pcibios_fixup_device_resources() may have to go. So I wonder if this > > > old hack is still necessary. Only testing can answer so I'm going to > > > put a patch to revert this into the -queue tree for 2.6.34. > > > > It is still necessary for Cobalt. > > I got the following IDE resource errors. > > > > pata_via 0000:00:09.1: BAR 0: can't reserve [io 0xf00001f0-0xf00001f7] > > pata_via 0000:00:09.1: failed to request/iomap BARs for port 0 (errno=-16) > > pata_via 0000:00:09.1: BAR 2: can't reserve [io 0xf0000170-0xf0000177] > > pata_via 0000:00:09.1: failed to request/iomap BARs for port 1 (errno=-16) > > pata_via 0000:00:09.1: no available native port > > I think Cobalt needs something like the patch below, because I think in > your working system, pata_via is using I/O port 0x1f0, not 0xf00001f0. > That means the the port the driver sees in the pci_dev resource is > identical to the port number that appears on the PCI bus, so there is no > io_offset. > > There are a few other places that may set non-zero io_offset values: > bcm1480, bcm1480ht. txx9_alloc_pci_controller(), bridge_probe(), and > octeon_pcie_setup(). I don't know whether they have similar issues. > > > > commit 7378269220d477118257d898bec9173743675f5e > Author: Bjorn Helgaas <bjorn.helgaas@xxxxxx> > Date: Sat Feb 20 07:52:29 2010 -0700 > > [MIPS] remove Cobalt I/O space offset > > On Cobalt, "inb(x)" produces an I/O port access to port "x" on the PCI > bus, which means the io_offset is zero and CPU (resource) addresses are > identical to PCI bus addresses. Correcting this means we can remove > the IORESOURCE_PCI_FIXED check from pcibios_fixup_device_resources(). > > The io_map_base is used internally by pci_iomap(), inb(), and other I/O > port access functions to generate an MMIO access to the address that > produces the desired I/O port PCI transaction. > > [Cobalt plat_mem_setup() does this: > set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); > rather than using cobalt_pci_controller.io_map_base, but the value's > the same, and I don't know enough to clean that up.] > > See http://lkml.org/lkml/2007/7/29/27 > > Signed-off-by: Bjorn Helgaas <bjorn.helgaas@xxxxxx> > > diff --git a/arch/mips/cobalt/pci.c b/arch/mips/cobalt/pci.c > index cfce7af..84aa205 100644 > --- a/arch/mips/cobalt/pci.c > +++ b/arch/mips/cobalt/pci.c > @@ -34,7 +34,6 @@ static struct pci_controller cobalt_pci_controller = { > .pci_ops = >64xxx_pci0_ops, > .mem_resource = &cobalt_mem_resource, > .io_resource = &cobalt_io_resource, > - .io_offset = 0 - GT_DEF_PCI0_IO_BASE, > .io_map_base = CKSEG1ADDR(GT_DEF_PCI0_IO_BASE), > }; io_offset is necessary for DEC tulip on Cobalt. It doesn't work when this patch is applied. Yoichi
