Re: Reverting old hack

[Ralf Baechle <ralf@linux-mips.org>]

On Sun, Feb 21, 2010 at 10:07:37PM -0700, Bjorn Helgaas 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.

It's a while since I last looked into this but here's how things afair
are working on a MIPS-based Cobalt system.

The system is based on a MIPS processor and a GT-64111 system controller.
Addresses within a certain CPU address range are passed to the PCI bus as
I/O cycles without address cycles.  Since memory is starting at CPU address
zero (and has to because of the processors used), that address window has
to get mapped somewhere else.  So a CPU access to some virtual address gets
translated to physical address 0xf00001f0.  The GT-64111 passes this to the
PCI bus as I/O port address 0xf00001f0.  Finally the VT82C586 chip which
only decodes the low 16 bits drops treats this as an I/O port space address
0x1f0.

  Ralf