Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS

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

On Tue, Aug 07, 2007 at 06:58:20PM +0200, Segher Boessenkool wrote:
> >> Most characters are allowed in the unit-address...  The following
> >> is just fine: "my-secret-base@the-moon".  ISA uses letters to
> >> distinguish between its different address spaces, for example.
> >
> > Yeah, I should probably make dtc a bit more flexible about accepting
> > that, too.  At present, it only takes hex digits and ',', since those
> > are the common character.
> 
> Sounds good.  And then the legacy ISA devices in existing
> DTS files should be changed to say @i60 instead of @60, etc.
> (@60 is correct since the default is legacy I/O space, but
> it's good the be more verbose in those cases).

Ok, I'll look into that.  No promises that it will be real soon,
though.

> >> David, can multiple devices sit on the same chip-select
> >> on EBC, or on the same "minor" address?  If not, you can
> >> simplify your unit address representation.
> >
> > As far as I know, multiple devices could sit on the same chip select:
> > provided there was enough address decoding logic in or around the
> > devices, and that there existing bus timing parameters which would
> > work with all the devices on a chip select (or "bank" in the
> > terminology of the EBC bridge documentation).
> 
> Ah, that's what multiple banks are for!

Yes.

> > Devices on different banks can certainly have the same address/offset
> > within the bank - e.g. on Ebony most of the devices are at offset 0.
> > The OPB address range for each bank is separately programmable in the
> > EBC bridge DCRs.
> 
> Okay, seems like the <bank,offset> representation is the simplest
> possible, then.  Good.  <rubber stamp>

Excellent.  I should really do a proper write-up for b-o-f.txt, I
guess.

> > (Incidentally, this is why I created the binding in this way, rather
> > than just using the firmware established addresses in OPB space, which
> > are usually fixed for a particular board/platform.  This way provides
> > enough information that, if necessary, the kernel or another client
> > can reprogram the EBC from scratch to access the various devices
> > present.  Well.. actually fully reprogramming would also need the the
> > bus timing parameters, which I was thinking of adding information
> > before, but I haven't gotten to it yet.)
> 
> It gives a full "as simple as possible but no simpler" description
> of the hardware, so it's just fine independent of whether you want
> to reprogram the EBC or not.

That was the idea.

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