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: "[EMAIL PROTECTED]". 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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
