Re: Reverting old hack

[Yoichi Yuasa <yuasa@linux-mips.org>]

Hi Bjorn,

On Sun, 21 Feb 2010 22:07:37 -0700
Bjorn Helgaas <bjorn.helgaas@hp.com> 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@linux-mips.org> 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@hp.com>
> 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@hp.com>
> 
> 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	= &gt64xxx_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