[PATCH 2/6] PowerPC 440EPx: Sequoia DTS
Segher Boessenkool
segher at kernel.crashing.org
Wed Aug 8 02:58:20 EST 2007
>> Most characters are allowed in the unit-address... The following
>> is just fine: "my-secret-base at 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).
>> 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
More information about the Linuxppc-dev
mailing list