David Gibson wrote:

quoted

quoted

quoted

quoted

  Heh, we've gone thru "physmap" before -- it was labelled 
Linux-specific name (well, I'd agree with that).

quoted

quoted

quoted

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

quoted

quoted

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.

quoted

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

quoted

quoted

Main memory is also direct physically mapped, after all,  but that's not 
what you want to cover
with this description.

quoted

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

quoted

quoted

In general how a device is wired is described by where it sits in the 
tree, not by its properties.

quoted

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

quoted

quoted

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.

quoted

  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.

quoted

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.

quoted

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