Hello.
David Gibson wrote:
Laurent Pinchart wrote:
[snip]
Heh, we've gone thru "physmap" before -- it was labelled Linux-specific
name (well, I'd agree with that).
physmap stands for physically mapped. That doesn't sound
Linux-specific to me, the fact that the MTD driver has the same name
is a pure coincidence. linmap-rom and linmap-rom sound even more
Linux-specific :-)
It may not be Linux specific per se, but it's a bad name, because the
fact that the device is physically direct mapped isn't a useful
distinguishing feature of the device.
Yeah, it's not a propery of a device itself (yet, the device would be
useless if this information is not supplied in the tree somehow). Yet remember
the now ungoing discussion about "reg-shift" property for UARTs -- some people
said that the fact that this property may not be a feature of device is
irrelevant WRT the binding. :-)
Main memory is also direct physically mapped, after all, but that's not what
you want to cover
with this description.
Haven't ever seen the description of memory as a device (unless you mean
the "memory" node which can hardly be considered proper device -- mainly
because of their usual placement at the top of the tree, and not where a RAM
device logically should be in the bus hierarchy).
In general how a device is wired is described by where it sits in the tree, not
by its properties.
Oh, another argument against "reg-shift" in the Xilinx UART quarry... :-)
It only seems like a usefully distinguishing name because it's the
Linux "physmap_of" driver that uses it. So in this sense it is a
Linux specific name after all. In fact, physmap_of is itself very
badly named - right now it only handles direct mapped mtds, but that's
Yeah, because that's what is what it has been written for.
not inherent; it could be trivially extended to also instantiate a
non-direct-mapped device (as long as the underlying mtd layer
supported it, of course). It bears no relation at all to the
> "physmap" driver, except historical accident.
This driver resides on the "top", device mapping layer of the MTD
hierarchy, and I don't see a point of cramming support for all the possible
mappings into one driver vs doing it as the *separate* specific drivers in
drivers/mtd/mapps/ -- as it has been done in the MTD tree before "the great OF
revolution". This is really strange idea...
WBR, Sergei
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
