> > Read the spec, and the above, and realise that the "isa" 
> > bus address space is NOT mapped through the bridge.
> 
> We've been doing this sort of thing on SPARCs for years.  
> Here's the layout from the Taco in my office:

But this is a *REAL* ISA bridge isn't it?

The "PCI to ISA bridge" in the VT8231 is there because it looks,
to legacy systems, a lot like an ISA bus. On a PC, port 3f8 is
magically (actually magically mapped via fixed MTRR) the COM1
serial port.

This isn't the case on PowerPC anyway (no distinction between
IO and memory in the memory map, no inb/outb type IO instructions)
and because the bridge isn't a bridge but a PCI device, the ISA
bus mapping does not apply.

There is no translation to be made from the ISA bus, it is handled
by it's parent node. Linux handles it properly already, which is
why it's confusing that a patch was created to falsify this data
(which turned out to be a crazy, wrong set of addresses anyway!)

The ONLY reason you want a ranges property is to find the IO offset
for the "reg" property. In this case, it's 0xFE00000 + 0x2F8 for
the serial port, since that is where the PCI I/O map is mapped (and
how the VT8231 requests it). There is no ISA bus mapping, it's
directly on the PCI bus and internally bridged, no external
influence.

> > In theory you should see that ranges is not present, or empty 
> > property, and back up the tree to the parent bus for the 
> I/O space. In 
> > this case it's the PCI0 controller on the Discovery II 
> > (/pci@4000000/isa@C). And in the output you'll see, the PCI 
> IO range is set as 0xFE000000.
> 
> How are you supposed to do that?  PCI has:
> 
>         #address-cells:  00000003
>         #size-cells:  00000002
> 
> The ISA bindings are:
> 
>             #size-cells:  00000001
>             #address-cells:  00000002
> 
> The formats are completely different.  How are you supposed 
> to map "isa"  bus addresses to PCI addresses without a properly
> defined "ranges" property?

The OS should be parsing OpenFirmware addresses and normalizing
them so it can use them. You can store addresses as 64bit or
32bit at any place on the tree (64bit even on a 32bit machine)
and for ranges there are flags as well as addresses. For PCI
and ISA, yes they are slightly different. But for each cell size
and address size the code in the OS should know which and how
to extract it in order to provide a real address (after all
encode-int values are not the same as an "unsigned long" in
memory and SOME decoding needs doing anyway).

The ways to do that are ALL specified in the OF spec.

> 
> Here's a child device on that machine:
> 
>             Node 0xf007b938
>                 interrupt-map:  
> 00000000.0000005c.00000001.f005f8f8.0000002f
>                 interrupts:  00000001
>                 #interrupt-cells:  00000001
>                 interrupt-map-mask:  00000000.000000ff.00000003
>                 reg:  00000000.00000320.00000002
>                 device_type:  'i2c'
>                 compatible: 'pcf8584'
>                 #size-cells:  00000000
>                 #address-cells:  00000002
>                 name:  'i2c'
> 
> What does one on your machine look like?

ok ls /pci/isa
serial@i2F8
8042@i60
keyboard@i60
rtc@i70
timer@i40
fdc@i3F0
lpt@i3BC
ok cd /pci/isa/rtc
ok .properties
name                  "rtc"
device_type           "rtc"
reg                   i70:2
interrupts            [0x8 bytes]
        [000] 00000008 00000000

clock-frequency       0x0 (0)
compatible            "ds1385-rtc"
ok cd /pci/isa/serial
ok .properties
name                  "serial"
device_type           "serial"
reg                   i2F8:8
interrupts            [0x8 bytes]
        [000] 00000003 00000000

clock-frequency       0x1C2000 (1843200)
compatible            "pnpPNP,501"

-- 
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations