PCI bus node location

[David Gibson]

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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson