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

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

>>> Aha!  Ok, now I understand the sorts of situations you're talking
>>> about.  By "not direct mapped", I thought you were talking about some
>>> kind of access via address/data registers on some indirect bus
>>> controller, rather than weird variations on endianness and
>>> bit-swizzling.
>>
>>     No, that would be just too ridiculous for a NOR flash -- I hope. 
>> :-)
>
> Heh.  In my experience, very little is so ridiculous that some
> embedded vendor won't do it.

True -- but if you can't map the NOR into the CPU address space,
there are cheaper alternatives.  Most embedded vendors care about
that, too ;-)

>>     So, you're saying that the 1:1 address correspondence rule stops 
>> to apply
>> here?
>
> Well.. it all depends what exactly you consider the address space of
> the flash bank.  By which I mean the whole shmozzle represented by the
> device node, not the individual flash chips.  It's not immediately
> obvious whether or not that should include any swizzling done by the
> bus wiring.

The parent device/bus shouldn't care, from its viewpoint the flash
bank is just one linear hunk of address space.  For reading or
writing the flash bank appears linear to the CPU as well (at least
that's the only thing our current proposed binding supports); the
only thing that gets "interesting" is sending commands to the flash
chips.

> It would be possible, I guess, to define a 'swizzled-ranges' property
> or something which allows child devices to be embedded in the parent's
> address range in a not-direct way.

Let's not even consider this please.

> However, the swizzling on the
> flash bank is really a property of the flash bank,

Yeah, it's the "fine structure" of the flash bank.  Something
only the flash driver has to deal with.  So no contaminating the
parent device node, thank you.

>>> Simplest option seems to me to add a property "endianness" or
>>
>>     And we even have a precedent of "big-endian" prop in the MPIC 
>> nodes
>> (although I'm not sure why it's needed there).

A single register read (32-bit registers) gives a big-endian value
on some MPIC implementations, and wrong-endian on others.  The
device driver really needs to know -- it really should just figure
it out from the "compatible" property though.


Segher