Re: PCI bus node location

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Wed, Nov 11, 2009 at 7:03 PM, David Gibson
<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> On Wed, Nov 11, 2009 at 03:16:56PM +0100, Rafal Jaworowski wrote:
>>
>> On 2009-11-11, at 01:05, David Gibson wrote:
>>
>> >>The current approach seems a bit of a maintenance problem: the PCI
>> >>bridges control reg need to specify the whole address instead of
>> >>just an offset, which is more error prone in case of changes (when a
>> >
>> >Well, yes.  And worse, it means there's two places that need to be
>> >adjusted rather than one, if the the IMMR is relocated (which it can
>> >be).  But it's a trade-off of this versus the inconvenience of dealing
>> >with separate "control" and "bridge" nodes for the PCI and following
>> >phandles between them.
>>
>> Would the technique with additional control node and a phandle
>> complicate bindings handling much? The clear benefit is the ability
>> to truly reflect hierarchy of devices available within IMMR/CCSR
>> block.
>>
>> >>number of places need to be adjusted etc.). What would need to be
>> >>done/extended for the ranges prop you mention to allow for better
>> >>handling cases like this?
>> >
>> >I don't really understand the question.  As Grant has said the
>> >"correct" approach is to have one node representing the control
>> >registers - located under the IMMR ("soc") node - and another
>> >representing the PCI host bridge itself (which would be in its present
>> >location).  There would need to be phandles linking the two.  It
>> >doesn't really need any extension to the device tree semantics itself
>> >- just a more complex binding for this device.
>>
>> Maybe I misunderstood Grant, my impression was that there was
>> possible some 'fixing' of ranges properties (which would be
>> alternative to the control node approach).
>
> Well.. the other approach would be for the "soc" node to have, in
> addition to a range for the IMMR registers, extra ranges for all the
> bridged ranges (PCI or localbus, or whatever).  That has its own
> problems because it means either we need a complicated encoding, or
> it's less obvious which devices have registers in the IMMR space and
> which have registers elsewhere.  We need more complex conventions
> about which range is which in the soc node's "ranges" property and so
> forth.

No, the encoding isn't complex at all.  And I think it become very
obvious which range is getting used for by each 'reg' property.  It
just has the ugliness of having to describe PCI BARs in the IMMR node.
 It would look like this (borrowing heavily from the 5200):

immr@f0000000 {
        #size-cells = <1>;
        #address-cells = <1>;
        ranges = <0 f0000000 0x00010000  # 16k Internal register range
                  80000000 80000000 0x40000000>; # 1GB range for PCI windows
        pci@0xd00 {
                #size-cells = <2>;
                #address-cells = <3>;
                reg = <0xd00 0x100>;
                /* 3 range entries; prefetchable, non-prefetchable, & IO. */
                ranges = <0x42000000 0 0x80000000    0x80000000    0 0x20000000
                          0x02000000 0 0xa0000000    0xa0000000    0 0x10000000
                          0x01000000 0 0x00000000    0xb0000000    0
0x01000000>;
        }
}

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.