On Wed, Nov 11, 2009 at 7:03 PM, David Gibson
[off-list ref] wrote:

On Wed, Nov 11, 2009 at 03:16:56PM +0100, Rafal Jaworowski wrote:

quoted

On 2009-11-11, at 01:05, David Gibson wrote:

quoted

quoted

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.

quoted

quoted

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.