> 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. > > Hrm.. this is a property of how the flash is wired onto the bus, > rather than of the flash chips themselves, so I'm not entirely sure > where description of it belongs. > > Simplest option seems to me to add a property "endianness" or > "bit-swizzling" or something which can be defined to describe some odd > connections. If absent we'd default to direct mapping. Segher, is > that idea going to cause you to scream?
No, that's fine with me. I would recommend either using a _good_ _descriptive_ name for such a property describing the swizzling, if this swizzling is common; or just put the whole bloody weirdo address permutation into some nice big array, something like address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>; >> Well, "device-width" is not the thing that we care about either. >> ;-) > > Well, yes but we need to encode it somehow. Segher preferred > device-width to interleave, because it's closer to a description of > the actual hardware, rather than an abstration decribing its wiring. > > In other words I *still* don't see any reason to prefer giving the > interleave. You *need* to know the device width. You *need* to know the bank width. And for 99% of the cases you don't need to know anything more since most hardware designs aren't insane. Case closed I'd say. >> Didn't know that the spec allows commas after @... > > Well, now you do. I believe USB usually uses that format, too. PCI too, and it even has an official binding :-) >> Don't we need "ranges" here, at least from the formal PoV -- as >> the parent >> and child address spaces differ? I know the physmap_of parser doesn't >> care but >> still... > > That's one I've wondered about. To describe the partitions address > space as lying (ultimately) in the physical address space, which in a > sense it does, yes we'd need a ranges property here. But we also have > a 'reg' at the top level which would overlap with that hypothetical > ranges which would be weird. Or we could exclude the top-level reg, > but then that's a pain if we do want to map the flash as a whole. > > So I left out ranges, on the grounds that there isn't actually > anything at present which will attempt to access flash partitions > "generically" as a device tree device. It looks good to me like this. In a real OF, the "register" access for the flash partition node would be handled by its parent node, which would know to do the direct-mapping thing (at least mapping it to _its_ parent, which typically asks the nodes further up, etc.) For the kernel world, we should just document it in the binding. > I'm not sold on this approach, but I haven't heard you give a better > argument yet. I haven't heard or thought of anything better either. Using "ranges" is conceptually wrong, even ignoring the technical problems that come with it. Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
