Re: dmesg and ofctl -p output as instructed

Hi,

I think I now understand what this [1] code is trying to do.  In the usual
case, we will take an interrupt value, and map it up through the OFW tree,
altering as needed based on: if it's behind a PCI bridges; the interrupt
maps of its parents.

It looks like the OFW on the E250/E450 (and others?) sets things up
differently, so we don't need to do any mapping for the built-in devices.
Also, note that we always call OF_mapintr() for PCI devices, but only call
it for EBUS devices if the ebus node had no "interrupt-map" property [2].

We can see the difference with the fully-specified interrupts for built-in
devices on the E250 [3], E450, and compare them with the U60 [4]:

EBUS:
  E250/E450:
  /pci@1f,4000/ebus@1/se@14,400000
  interrupts              0000002b ........ ........ ........   ...+

  U60:
  /pci@1f,4000/ebus@1
  interrupt-map           00000014 00200000 00000001 f005fd74   ..... .........t
    ...
  /pci@1f,4000/ebus@1/se@14,400000
  interrupts              00000001 ........ ........ ........   ....

PCI interrupts for built-in devices:
  E250:
  /pci@1f,4000/network@1,1
  interrupts              00000021 ........ ........ ........   ...!
  /pci@1f,4000/scsi@3
  interrupts              00000020 ........ ........ ........   ...

  E450:
  /pci/network@1,1
  interrupts              000007e1 ........ ........ ........   ....
  /pci/scsi@3
  interrupts              000007e0 ........ ........ ........   ....

  U60:
  /pci@1f,4000/scsi@3
  interrupts              00000001 ........ ........ ........   ....

Add-in PCI devices:
  E250
  /pci@1f,4000/TSI,gfxp@5
  interrupts              00000001 ........ ........ ........   ....
  /pci@1f,2000/pci@1/SUNW,qfe@0,1
  interrupts              00000002 ........ ........ ........   ....

  E450:
  /pci/TSI,gfxp@4
  interrupts              00000001 ........ ........ ........   ....

  U60:
  /pci@1f,4000/pci@2/SUNW,qfe@0,1
  interrupts              00000002 ........ ........ ........   ....

Also, note that these machines have psycho PCI controllers, and we treat
psycho0/psycho1 specially by testing against its known IGN (0x7c0):

  psycho0: SUNW,psycho: impl 0, version 4: ign 7c0 bus range 0 to 0; PCI bus 0

but other PCI controllers also use IGN 0x7c0 (V240 example):

  schizo0 at mainbus0: addr 4000ff00000: Tomatillo, version 0, ign 7c0, bus B 0 to 0

So, I guess that the code has to stay so that we can handle the E250/E450
correctly, but we need to guard it with an extra test for the PCI controller
type at least.  Maybe we should test explicitly for E250/E450 too, but I'm
not certain that that is a good idea.

J

[1] OF_mapintr()
  http://nxr.netbsd.org/xref/src/sys/arch/sparc64/sparc64/ofw_machdep.c#741

[2] ebus_find_ino()
  http://nxr.netbsd.org/xref/src/sys/arch/sparc64/dev/ebus.c#314

[3] E250 ofctl -p:
  http://www.coris.org.uk/jdc/Notes/Sun/E250-ofctl.html

[4] U60 ofctl -p:
  http://www.coris.org.uk/jdc/Notes/Sun/U60-ofctl.html
-- 
   My other computer runs NetBSD too   -         http://www.netbsd.org/