[Top] [All Lists]

Re: Reverting old hack

To: Bjorn Helgaas <>
Subject: Re: Reverting old hack
From: Ralf Baechle <>
Date: Mon, 22 Feb 2010 14:28:30 +0100
Cc: Yoichi Yuasa <>,
In-reply-to: <1266815257.1959.23.camel@dc7800.home>
Original-recipient: rfc822;
References: <> <> <1266815257.1959.23.camel@dc7800.home>
User-agent: Mutt/1.5.20 (2009-08-17)
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


<Prev in Thread] Current Thread [Next in Thread>