[RFC] Adding MTD to device tree
sshtylyov at ru.mvista.com
Sun Aug 13 02:19:32 EST 2006
Segher Boessenkool wrote:
>>> Required properties:
>>> - device_type : one of "nand-flash", "nor-flash", or "rom".
I thought about having the separate device types initially, then I decided
that all the differences can be handled on the driver level...
>>There are more than just those kinds of MTDs. There's dataflash,
>>AG-AND, NVRAM, ioremappable DRAM, etc. I'd prefer it to just be
>>called "flash". See more below.
> Existing firmwares call it "rom", "nvram", "flash". All of those
> are easy; and I have really no opinion how all the weirdo nand-flash
> etc. interfaces should be handled.
> device_type communicates to the device-tree consumer what other
> properties to expect in this node -- it does not indicate the exact
> programming model of the device itself.
Erm, IIUC the exact set of properties is defined by the node name (or the
"compatible" property). The device type defines some mandatory set of
properties/methods but there may be some specific...
> I suspect for most nand-flash you can get away with a device_type
> of "nand-flash"; for some you might have to specify something more
Hm, not sure that you need to be so much detailed with the device type.
The original OF spec. had device type "block" signifying any kind of blocked
>>> - model : an identifier for the actual controller chip used.
>>Meaning what exactly? Lots of NOR flash doesn't have a "controller".
> Lots of those chips from different vendors are pin-compatible as well,
> so you cannot really hardcode one specific model number. I don't see
> this information being very useful anyway. Instead, in most cases, the
> information you're really after is the programming interface for the
> device. And that goes...
This property might be marked optional still.
>>> - compatible : Should be the name of the MTD driver. For
>>> type "rom", this is most likely "physmap".
>>This I agree with, but Sergei already had this. And since you're
>>specifying the name of the MTD driver, that typically already knows
>>type of chip it's talking to.
> "compatible" contains a list, most specific first. So for example
> for a NOR-flash it could be "jedec-flash,nor-flash,flash" or whatnot.
> (Btw: no comma's, but 0-chars in the actual properties!)
The "compatible" prop (as well as "name") should define which driver to
select according to spec. (the Generic Names spec. delegates this role solely
to the "compatible" prop). While specifying the flash interface (JEDEC in this
case) is indeed useful (however, the current 'platform_device' based 'physmap'
implementation doesn't allow to pass the probe type to the driver), the prop
in the form suggested doesn't really help with selecting the MTD map driver
(without which you can't support a NOR flash). A reference to 'physmap' should
still be present in the node in one or another form...
More information about the Linuxppc-embedded