On Thu, Jan 27, 2011 at 02:41:47PM +0530, Sebastian Andrzej Siewior wrote:
> * David Gibson | 2011-01-27 15:00:27 [+1000]:
> >> + >;
> >> +
> >> + 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.
g.
On 2/3/2011 10:59 AM, Grant Likely wrote:
> On Thu, Jan 27, 2011 at 02:41:47PM +0530, Sebastian Andrzej Siewior wrote:
>> * David Gibson | 2011-01-27 15:00:27 [+1000]:
>>>> + >;
>>>> +
>>>> + 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
> [email protected]
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
Mitch Bradley wrote:
> 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.
[snip more of it]
> 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.
Thanks for clearing it up. After David pointed it out I looked it up in
the PCI spec and it seems to match what you saying here.
Sebastian