OF compatible MTD platform RAM driver ?
sshtylyov at ru.mvista.com
Thu Mar 27 08:23:46 EDT 2008
David Gibson wrote:
>>>Laurent Pinchart wrote:
>>> 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
> 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...
More information about the linux-mtd