Re: OF compatible MTD platform RAM driver ?

Sergei Shtylyov
2008-03-27T12:22:25Z

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