From: Sergei Shtylyov <hidden> Date: 2006-08-11 15:31:11
Hello.
Here's the proposal for the representation of the MTD (optionally having
some partitions) in the device tree, along with the sample code that parses
the MTD node and hands the necessary information to the 'physmap' driver using
the 'platform_device' method. The representation was fitted to the current
Linux MTD driver model, so it doesn't bear any information on the chip models
or the flash interflace, letting the MTD probing code figure all that out
(this part might need some changes I suspect).
To me, however, this method seems too limiting: we have to look thru the
device tree for each particular kind MTDs (assuming that there could be
different ones that 'physmap' can't drive) and register each of them its own
way. If we teach 'physmap' to register on the 'of_platform_device' bus, we
may look up the device tree for *any* MTD nodes somewhere in arch/powerpc/
tree, register them all, and leave it up to the particular driver to claim
them and get the information the driver needs from their node's properties.
That would require introducing another MTD partition pasrsing module (so the
code that parses the partitions in this patch will move into the separate
module under drivers/mtd/).
Opinions on what way should be taken and what needs to be added from both
PowerPC and MTD communities are very welcome.
WBR, Sergei
Signed-off-by: Sergei Shtylyov <redacted>
On Friday 11 August 2006 17:31, Sergei Shtylyov wrote:
+ =A0 h) MTD nodes
+
+ =A0 Memory Technology Devices are flash, ROM, and similar chips, often =
used
+ =A0 for solid state file systems on embedded devices.
+
+ =A0 Required properties:
+
+ =A0 =A0- device_type : has to be "mtd"
+ =A0 =A0- compatible : Should be the name of the MTD driver. Currently, =
this is
+ =A0 =A0 =A0most likely to be "physmap".
+ =A0 =A0- reg : Offset and length of the register set for the device.
I would prefer to call them something different in the device tree.
The name 'mtd' is very specific to Linux, but the device tree
is a more generic concept.
I understand that the booting-without-of.txt file is by definition
Linux specific as well, but we should be prepared for making parts
of it a OS independent binding at the point where we put the same
device nodes into actual OF implementations that able to boot
different operating systems.
I would prefer a naming that has=20
Required properties:
- device_type : one of "nand-flash", "nor-flash", or "rom".
- model : an identifier for the actual controller chip used.
- compatible : Should be the name of the MTD driver. For
type "rom", this is most likely "physmap".
Arnd <><
On Fri, 2006-08-11 at 23:10 +0200, Arnd Bergmann wrote:
On Friday 11 August 2006 17:31, Sergei Shtylyov wrote:
quoted
+ h) MTD nodes
+
+ Memory Technology Devices are flash, ROM, and similar chips, often used
+ for solid state file systems on embedded devices.
+
+ Required properties:
+
+ - device_type : has to be "mtd"
+ - compatible : Should be the name of the MTD driver. Currently, this is
+ most likely to be "physmap".
+ - reg : Offset and length of the register set for the device.
I would prefer to call them something different in the device tree.
The name 'mtd' is very specific to Linux, but the device tree
is a more generic concept.
Agreed here.
I understand that the booting-without-of.txt file is by definition
Linux specific as well, but we should be prepared for making parts
of it a OS independent binding at the point where we put the same
device nodes into actual OF implementations that able to boot
different operating systems.
I would prefer a naming that has
Required properties:
- device_type : one of "nand-flash", "nor-flash", or "rom".
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.
- model : an identifier for the actual controller chip used.
Meaning what exactly? Lots of NOR flash doesn't have a "controller".
- 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 what
type of chip it's talking to.
For example, physmap will probe for CFI, JEDEC, and ROM devices already.
It can't do NAND flash, so you'd have to specify the name of a NAND
driver, such as ndfc.c and that only deals with NAND flash.
josh
Required properties:
- device_type : one of "nand-flash", "nor-flash", or "rom".
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.
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
detailed.
quoted
- 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...
quoted
- 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
what
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!)
Segher
From: Sergei Shtylyov <hidden> Date: 2006-08-12 16:19:32
Hello.
Segher Boessenkool wrote:
quoted
quoted
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...
quoted
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
detailed.
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
storage device.
quoted
quoted
- model : an identifier for the actual controller chip used.
quoted
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.
quoted
quoted
- compatible : Should be the name of the MTD driver. For
type "rom", this is most likely "physmap".
quoted
This I agree with, but Sergei already had this. And since you're
specifying the name of the MTD driver, that typically already knows
what
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...
WBR, Sergei
- 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...
Not necessarily on all OSes.
quoted
quoted
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.
quoted
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.
quoted
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...
Exact set of properties isn't defined anywhere. "device_type" defines a
pretty generic interface, mostly saying what methods will be there (but
you don't care for that for a flattened tree); "compatible" communicates
to the OS what this device is exactly (so it can select a device driver
to use, for example). "name" should not be used by anything but humans
normally.
quoted
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
detailed.
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 storage device.
But memory devices aren't really block devices, for example, NOR-flash
is random access for everything but erase operations.
quoted
quoted
quoted
- model : an identifier for the actual controller chip used.
This property might be marked optional still.
Then there's no reason to include it in the binding; "model" is
already defined in the base spec.
quoted
"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...
"compatible" denotes the device's specific programming interface,
_not_ the
name of the device's driver in some random OS. If you don't care for
the
detailed interface (because your driver will probe for it itself for
example,
as you said), you can take the next-less-specific entry from
"compatible" and
use that instead. Although it would be better to just probe for the few
specific interfaces defined (jedec-flash, cfi-flash, and a few more
perhaps).
Segher