Re: [RFC] AmigaOne device tree source v2

[David Gibson <david@gibson.dropbear.id.au>]

On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > That looks totally bogus.  Unlike Segher, I think there are a few
> > cases where overlapping reg and ranges can make sense
> 
> That's not unlike me -- I may have lower tolerance for it though :-)

I see.  Can't imagine how I got another impression... :-p

: Date: Thu, 19 Jul 2007 17:51:17 +0200
: From: Segher Boessenkool <segher@kernel.crashing.org>
: Subject: Re: [PATCH] Add 8548CDS with Arcadia 3.0 support
...
: "reg" and "ranges" overlap, that can't be right.

: Date: Tue, 7 Aug 2007 18:51:04 +0200
: From: Segher Boessenkool <segher@kernel.crashing.org>
: Subject: Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
...
: > To be honest this looks rather to me like another case where having
: > overlapping 'reg' and 'ranges' would actually make sense.
:
: It never makes sense.  You should give the "master" device
: the full "reg" range it covers, and have it define its own
...

> > (PCI bridges
> > where config space is accessed indirectly via MMIO registers which lie
> > in the legacy ISA IO space is an example).
> 
> That's a good example yes.
> 
> > But this doesn't look like
> > such a case - it just looks like whoever did the device tree
> > misunderstood the distinction between reg and ranges.
> 
> Indeed.
> 
> >>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >>> PowerPC system bus.  So, it can not be mentioned in the "ranges"
> >>> property, but the PHB registers used to access it should be shown
> >>> in the "reg" property.  It could be a simple linear window (it
> >>> sounds like it is here?), but it could for example also be 
> >>> implemented
> >>> via an address/data register pair.
> >
> > Err... huh?  The legacy IO space is assigned a block of addresses in
> > 3-word "OF-PCI-space by the PCI binding.  When that is translated into
> > an MMIO range by the bridge, there's no reason that can't be encoded
> > into the ranges property.
> 
> Sure, it can be encoded like that.  But does it make sense?
> You cannot use legacy I/O space as normal memory space.

Well, no, but you can't use *any* MMIO space as normal memory space,
and that's handled routinely by 'ranges'.

> On an arch like x86, where "I/O addresses" exist on the system
> bus as well, it would make sense, since you can translate I/O
> addresses to I/O addresses that way (except on x86 even it cannot
> be done either, since I/O addresses cannot be encoded on the root
> bus -- at least not in existing device trees.  There is no official
> x86 binding yet though).

What!?  This is nuts, Segher.  Why should the binding have to define
some bridge-specific way of encoding the legacy I/O information, when
the PCI-binding's address encoding plus 'ranges' provides a perfectly
unambiguous way of doing so.  *And* it makes the normal semantics of
ranges do just the right thing for a subordinate PCI<->ISA bridge.

> Also, from a driver standpoint, a PHB driver needs to find out
> two main things about the bridge: a) how and where to generate
> config cycles; b) how and where to generate legacy I/O cycles.
> It is told "how" by the "compatible" property, and "where" by
> the "reg" property, normally.
> 
> But yes, you _can_ use "ranges" for this purpose on PHBs where
> legacy I/O is linearly mapped.  It just doesn't make much sense.
> The binding for your specific PHB should tell you what to do.

-- 
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