RFC: [MIPS] BCM1480/BCM1480HT remove io_offset

RFC: [MIPS] BCM1480/BCM1480HT remove io_offset

[Bjorn Helgaas]

BCM1480 and BCM1480HT currently offset the Linux ioport space from the
PCI ioport addresses, e.g., for BCM1480, device I/O resources from the CPU
perspective are in the range [io 0x2c000000-0x2dffffff] (these would appear
in /proc/ioports) and are converted by the PCI controller to the PCI range
[io 0x0-0x1fffff].
    
It should be simpler to remove this io_offset and adjust the controller's
io_map_base correspondingly.  For BCM1480, this would change this:
    
    [CPU io 0x2c000000-0x2dffffff] -> [PCI io 0x0-0x1ffffff]
    bcm1480_controller.io_offset = 0x2c000000
    bcm1480_controller.io_map_base = 0 (physical)
    mips_io_port_base = 0 (physical)
    
to this:
    
    [CPU io 0x0-0x1ffffff] -> [PCI io 0x0-0x1ffffff]
    bcm1480_controller.io_offset = 0
    bcm1480_controller.io_map_base = 0x2c000000 (physical)
    mips_io_port_base = 0x2c000000 (physical)
    
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

diff --git a/arch/mips/pci/pci-bcm1480.c b/arch/mips/pci/pci-bcm1480.c
index 6f5e24c..74585cb 100644
--- a/arch/mips/pci/pci-bcm1480.c
+++ b/arch/mips/pci/pci-bcm1480.c
@@ -185,8 +185,8 @@ static struct resource bcm1480_mem_resource = {
 
 static struct resource bcm1480_io_resource = {
 	.name	= "BCM1480 PCI I/O",
-	.start	= A_BCM1480_PHYS_PCI_IO_MATCH_BYTES,
-	.end	= A_BCM1480_PHYS_PCI_IO_MATCH_BYTES + 0x1ffffffUL,
+	.start	= 0,
+	.end	= 0x1ffffffUL,
 	.flags	= IORESOURCE_IO,
 };
 
@@ -194,7 +194,6 @@ struct pci_controller bcm1480_controller = {
 	.pci_ops	= &bcm1480_pci_ops,
 	.mem_resource	= &bcm1480_mem_resource,
 	.io_resource	= &bcm1480_io_resource,
-	.io_offset      = A_BCM1480_PHYS_PCI_IO_MATCH_BYTES,
 };
 
 
@@ -251,7 +250,6 @@ static int __init bcm1480_pcibios_init(void)
 
 	bcm1480_controller.io_map_base = (unsigned long)
 		ioremap(A_BCM1480_PHYS_PCI_IO_MATCH_BYTES, 65536);
-	bcm1480_controller.io_map_base -= bcm1480_controller.io_offset;
 	set_io_port_base(bcm1480_controller.io_map_base);
 
 	register_pci_controller(&bcm1480_controller);
diff --git a/arch/mips/pci/pci-bcm1480ht.c b/arch/mips/pci/pci-bcm1480ht.c
index 50cc6e9..0fd0222 100644
--- a/arch/mips/pci/pci-bcm1480ht.c
+++ b/arch/mips/pci/pci-bcm1480ht.c
@@ -180,8 +180,8 @@ static struct resource bcm1480ht_mem_resource = {
 
 static struct resource bcm1480ht_io_resource = {
 	.name	= "BCM1480 HT I/O",
-	.start	= A_BCM1480_PHYS_HT_IO_MATCH_BYTES,
-	.end	= A_BCM1480_PHYS_HT_IO_MATCH_BYTES + 0x01ffffffUL,
+	.start	= 0,
+	.end	= 0x01ffffffUL,
 	.flags	= IORESOURCE_IO,
 };
 
@@ -191,7 +191,6 @@ struct pci_controller bcm1480ht_controller = {
 	.io_resource	= &bcm1480ht_io_resource,
 	.index		= 1,
 	.get_busno	= bcm1480ht_pcibios_get_busno,
-	.io_offset      = A_BCM1480_PHYS_HT_IO_MATCH_BYTES,
 };
 
 static int __init bcm1480ht_pcibios_init(void)
@@ -206,7 +205,6 @@ static int __init bcm1480ht_pcibios_init(void)
 			4 * 1024 * 1024);
 	bcm1480ht_controller.io_map_base = (unsigned long)
 		ioremap(A_BCM1480_PHYS_HT_IO_MATCH_BYTES, 65536);
-	bcm1480ht_controller.io_map_base -= bcm1480ht_controller.io_offset;
 
 	register_pci_controller(&bcm1480ht_controller);
 

Re: RFC: [MIPS] BCM1480/BCM1480HT remove io_offset

[Thomas Bogendoerfer]

On Wed, Feb 24, 2010 at 01:38:41PM -0700, Bjorn Helgaas wrote:
> BCM1480 and BCM1480HT currently offset the Linux ioport space from the

BCM1480 and BCM1480HT are two hoses on the same chip. Since there is
only one PCI IO port range, it's probably not a good idea to let
both busses use the same IO port range. But maybe I'm overlooking
something.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: RFC: [MIPS] BCM1480/BCM1480HT remove io_offset

[Bjorn Helgaas]

On Wednesday 24 February 2010 03:10:53 pm Thomas Bogendoerfer wrote:
> On Wed, Feb 24, 2010 at 01:38:41PM -0700, Bjorn Helgaas wrote:
> > BCM1480 and BCM1480HT currently offset the Linux ioport space from the
> 
> BCM1480 and BCM1480HT are two hoses on the same chip. Since there is
> only one PCI IO port range, it's probably not a good idea to let
> both busses use the same IO port range. But maybe I'm overlooking
> something.

Oh, I didn't realize these were two parts of the same system.  Guess I
should have realized that from the Makefile, which selects both for
CONFIG_SIBYTE_BCM1x80.  In that case, you definitely don't want the
same I/O port range for both.

Are there registers to control the CPU-to-PCI address translation, or
is it just fixed at:

  PCI ioport = CPU addr - 0x2C000000 (for BCM1480) and
  PCI ioport = CPU addr - 0xDC000000 (for BCM1480HT)?

If you can control the translation, you could define nice CPU-side
I/O port ranges like we do on ia64, e.g.,

  [0x0000000-0x0ffffff] for BCM1480
  [0x1000000-0x1ffffff] for BCM1480HT

That would also allow you to make inb() and friends work on both
hoses by replacing "mips_io_port_base + port" with something like
__ia64_mk_io_addr().

I guess you could do the same thing even if you can't control the
translation, but the ranges would be a little uglier because they
both have to be relative to the same base, e.g.,

  [0x0000000-0x0ffffff] for BCM1480
  [0xb000000-0xbffffff] for BCM1480HT

Bjorn

P.S.  The only reason I even looked at this was because I want to
remove the IORESOURCE_PCI_FIXED check from pcibios_fixup_device_resources(),
and BCM1480 will see a change because it has non-zero io_offset.

However, I *think* that change (independent of this BCM1480xx kibitzing)
will actually improve legacy IDE support.  Before, pci_setup_device()
would leave things like 0x1f0 in legacy-mode IDE device resources, and
pcibios_fixup_device_resources() would leave them alone instead of
converting them to CPU addresses like 0x2c0001f0.

After the IORESOURCE_PCI_FIXED removal, pcibios_fixup_device_resources()
will do the conversion, which I think is the correct thing on BCM1480xx.

Re: RFC: [MIPS] BCM1480/BCM1480HT remove io_offset

[Bjorn Helgaas]

On Wed, 2010-02-24 at 16:30 -0700, Bjorn Helgaas wrote:
> Are there registers to control the CPU-to-PCI address translation, or
> is it just fixed at:
> 
>   PCI ioport = CPU addr - 0x2C000000 (for BCM1480) and
>   PCI ioport = CPU addr - 0xDC000000 (for BCM1480HT)?
> 
> If you can control the translation, you could define nice CPU-side
> I/O port ranges like we do on ia64, e.g.,
> 
>   [0x0000000-0x0ffffff] for BCM1480
>   [0x1000000-0x1ffffff] for BCM1480HT
> 
> That would also allow you to make inb() and friends work on both
> hoses by replacing "mips_io_port_base + port" with something like
> __ia64_mk_io_addr().
> 
> I guess you could do the same thing even if you can't control the
> translation, but the ranges would be a little uglier because they
> both have to be relative to the same base, e.g.,
> 
>   [0x0000000-0x0ffffff] for BCM1480
>   [0xb000000-0xbffffff] for BCM1480HT

Actually, you should be able to make this work with CPU I/O resources of
your choice even if you can't control the translation.  It just requires
a little more indirection, like most computer science problems :-)  On
ia64, we map multiple I/O port spaces with arbitrary translations into a
0xSPPPPPP scheme (S = space number, PPPPPP = port number).

But my main concern is just making sure that my IORESOURCE_PCI_FIXED
change didn't break BCM1480, and I don't think it will.

Bjorn

Re: RFC: [MIPS] BCM1480/BCM1480HT remove io_offset

[Ralf Baechle]

On Wed, Feb 24, 2010 at 08:45:02PM -0700, Bjorn Helgaas wrote:

> Actually, you should be able to make this work with CPU I/O resources of
> your choice even if you can't control the translation.  It just requires
> a little more indirection, like most computer science problems :-)  On
> ia64, we map multiple I/O port spaces with arbitrary translations into a
> 0xSPPPPPP scheme (S = space number, PPPPPP = port number).
> 
> But my main concern is just making sure that my IORESOURCE_PCI_FIXED
> change didn't break BCM1480, and I don't think it will.

The whole IORESOURCE_PCI_FIXED thing was created for Cobalt only and is
needed due to the discontinuity of the port address space with legacy I/O
ports in the range of 0..0x1000 and the rest starting off from 0x10000000.
No other system has such a lobotomized system controller.

  Ralf