Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

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