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

[Segher Boessenkool <segher@kernel.crashing.org>]

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

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