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