>> 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). >> 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! > 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> > (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. Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
