On Tue, Aug 07, 2007 at 06:58:20PM +0200, Segher Boessenkool wrote:

quoted

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

(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