Device node naming for device_type pci?

[Asif Haswarey]

Hi,

This might be a very basic question but I could not find a clear answer
in the
OpenFirmware PCI Bus Binding doc.

Child node names are represented in a device-tree like so:

devname@dev#,fun  #

After looking at the pci bus-binding, I figured that the device naming
convention (ie. representation
within a device-path in a device-tree) is the same for PCI-to-PCI
bridges with device_type property = pci.

Well this does not seem to be the case on the SPARC system I am using:

/pci@1f,700000
.properties
available                81000000 00000000 00000700 00000000

0000f900 82000000 00000000 00108000

00000000 00078000 82000000 00000000

00580000 00000000 bfa80000 82000000

00000000 e0000000 00000000 00000000

reg                      00000400 0ff00000 00000000 0000b000

00000400 0fc10000 00000000 00007020

000007f6 00000000 00000000 00000100

00000400 0ff80000 00000000 00010000

ranges                   00000000 00000000 00000000 000007f6 00000000
00000000 
01000000

01000000 00000000 00000000 000007f6 01000000
00000000 
01000000

02000000 00000000 00000000 000007f7 00000000
00000001 
00000000

03000000 00000000 00000000 000007f7 00000000
00000001 
00000000

virtual-dma              c0 00 00 00 20 00 00 00 
#virtual-dma-size-cells  00000001 
#virtual-dma-addr-cells  00000001 
no-streaming-cache       
clock-frequency          03ef1480 
bus-range                00 00 00 00 00 00 00 00 
bus-parity-generated     
no-probe-list            0
compatible               pci108e,a801
                         pci108e,8001
name                     pci
device_type              pci
#address-cells           00000003 
#size-cells              00000002 
implementation#          00000023 
version#                 00000004 
portid                   0000001f 
interrupt-map            00001000 00000000 00000000 00000001 f00684c8
0000001c 
                         00001800 00000000 00000000 00000001 f00684c8
00000014 
                         00001800 00000000 00000000 00000002 f00684c8
00000015 
                         00001800 00000000 00000000 00000003 f00684c8
00000016 
                         00001800 00000000 00000000 00000004 f00684c8
00000017 
ino-bitmap               10 f0 00 00 00 1b 00 08 
interrupt-map-mask       00fff800 00000000 00000000 00000007 
#interrupt-cells         00000001 
66mhz-capable 
slot-names               00 00 00 08 50 43 49 34 00 
interrupts               00000033 
                         00000030 
                         00000031 
                         00000034 
                         00000023

If I use the first phy-hi value from the reg property, and extract the
dev# and fun# as described in the OpenFirmware
PCI Bus Binding, I get dev# = 0x00, fun# = 0x04.
So how does Sun get:
dev# = 0x1f
fun# = 0x700000 [and valid fun#s range from 0 .. 7]
Perhaps I am supposed to look at another property.
Does anyone know which one that would be?

Thanks for any help on this!

-Asif

[Tarl Neustaedter]

Asif Haswarey wrote:
[...]
> After looking at the pci bus-binding, [...]
> Well this does not seem to be the case on the SPARC system I am using:
>
> /pci@1f,700000
> .properties

[...]
> If I use the first phy-hi value from the reg property, and extract the 
> dev# and fun# as described in the OpenFirmware
> PCI Bus Binding, I get dev# = 0x00, fun# = 0x04.
> So how does Sun get:
> dev# = 0x1f
> fun# = 0x700000 [and valid fun#s range from 0 .. 7]
> Perhaps I am supposed to look at another property.
> Does anyone know which one that would be?

The unit address of a device node (and the reg property) is
defined by the *parent's* encode-unit. The root nexus on your
system translates

00000400 0ff00000 (binary form from the reg property)

into 1f,700000 (text form). See the encode-unit and decode-unit
methods in the top level "/" node. I recall this particular
pattern is from our first sun4s systems (excalibur et.al.), and
I don't recall the reason for the bits being scattered about
like that. But it's irrelevant to the pci nodes, the pci driver
itself does not need to know the translation.