OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

David Gibson 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
>>>>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).

> Yes, I mean the memory node.  And although it's no very likely,
> there's no inherent reason a RAM device couldn't also be at the top of
> the tree, on a CPU with the right sort of localbus.

    Yeah, according to the spec. this represents a RAM device. Too bad it's 
too often misplaced in the tree being on the top layer, and creating confusion 
(I used to misplace MTD device because of that)... :-(

>>>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... 
>>:-)

> Not really.  I was perhaps a bit strong, wiring information in the
> properties isn't necessarily wrong, but it does need a close look.
> "reg-shift" is a useful compromise.

    And I've heard it's been spec'ed already. :-)
    And MTD could surely a subject to alike compromise since it can be wired 
to the bus in a weird way too (not very likely though).

>>>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 

    Which is actually bottom of course call-wise since it reads/writes the 
actual data for the upper layers.

>>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/

> Because doing it as separate drivers would mean duplicating most of
> physmap_of for absolutely no reason.  I'll say it again there is

    Duplicating what, device probe/remove code? Partition parsing has been at 
last factored out into separate module by somebody (that patch should be 
queued in the MTD tree though I'm not sure), the old probing/partition code 
(i.e. our lame one) is not needed for the newly added devices...

> *nothing* that actually relies on the direct mapping in physmap_of;

    Really? Even simple_map_init() call it does?

> the *only* thing it does is take the device tree information and
> marshal it into an initialization call for the appropriate mtd chip
> drivers.

    No, not only that...

> I really should get around to sending a patch to rename physmap_of to
> "of_mtd.c".

    I don't think you should bother with that.

>>-- as it has been done in the MTD tree before "the great 
>>OF revolution". This is really strange idea...

> The only reason mtd needs heaps of little "map drivers" (which barely
> deserve the title of "driver")

    It's a layered driver structure

> is because there wasn't a single
> generally available source of information about where and how flash
> was mapped

    Not entirely true. You could try passing extra info with the platform 
device information...

> so a whole pile of platform or sitation specific ways of
> getting that information were needed.

    Some drivers read the h/w registers to determine the right type of mapping 
-- well, this probably could be replaced with reading this info from the 
device tree...

> With a device tree all that can
> be replaced with just getting the information from the device tree.

    Don't forget that such a universal driver would be taking extra kernel 
memory space as well, being loaded with the unused code handling all known 
mappings as well as extra probe/remove code...

WBR, Sergei