Re: [PATCH TIP 03/14] x86/dtb: Add a device tree for CE4100
From: Mitch Bradley <hidden>
Date: 2011-02-03 21:42:49
Also in:
lkml
On 2/3/2011 10:59 AM, Grant Likely wrote:
On Thu, Jan 27, 2011 at 02:41:47PM +0530, Sebastian Andrzej Siewior wrote:quoted
* David Gibson | 2011-01-27 15:00:27 [+1000]:quoted
quoted
+ >; + + i2c-controller@15a00,0,0 {Uh.. that unit address does not look right. The encoding of PCI 3-cell addresses into a unit address string is not simply comma separated cells. I forget the details, so you'll need to check the OF PCI binding.Grant wrote [0]: |You'll also note that I added ',0,0' to the end of the address. |That's because the node address reflects the parent bus address format |which uses 3 cells in this case.It is quite possible I was mistaken on this point. The PCI binding is not my area of strength.
In real OF, the unit address of a PCI device is the first entry in the reg property, which is the config space address. For the config space address, only the most significant of the three cells is significant; the other two must be 0. The numerical representation of that cell in binary is 0000.0000.0000.0000.dddd.dfff.0000.0000, where d is the device number on its bus segment and fff is the function number. The text representation is "D,F" , where D is the hexadecimal ASCII representation of the binary number ddddd and F is the hexadecimal ASCII representation of the binary number fff . So "show-devs" will display names like "/pci/ethernet@12,e" - device number 0x12, function number 0xe. (In the general case, there are more fields in both the numerical and text representations, but the unit address usage is restricted to just the device and function numbers. Bus numbers are handled by the hierarchy of PCI-to-PCI bridges.) In real OF, there are "encode-unit" and "decode-unit" methods in the parent (PCI bus) node to convert between the numerical and text representations. I don't know how this plays out in the flattened DT world, but the above is a summary of what the PCI bus binding stipulates.
g. _______________________________________________ devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org https://lists.ozlabs.org/listinfo/devicetree-discuss