Adding MTD to device tree
Subsystems (3)
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
RFC 1/1 Adding MTD to device tree
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
Documentation/powerpc/booting-without-of.txt +38 -0
@@ -6,6 +6,8 @@ IBM Corp. (c) 2005 Becky Bruce <becky.bruce at freescale.com>, Freescale Semiconductor, FSL SOC and 32-bit additions +(c) 2006 MontaVista Software, Inc. + MTD node definition May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
@@ -1442,6 +1444,42 @@ platforms are moved over to use the flat }; + 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. + + Recommended properties : + + - bank-width : Width of the flash data bus in bytes. Must be specified + for the NOR flashes. + - partitions : Several pairs of 32-bit values where the first value is + partition's offset from the start of the MTD device and the second + one is partition size in bytes with LSB used to signify a read only + partititon (so, the parition size should always be an even number). + - partition-names : The list of concatenated zero terminated strings + representing the partition names. + + Example: + + flash@ff000000 { + device_type = "mtd"; + compatible = "physmap"; + reg = <ff000000 01000000>; + bank-width = <4>; + partitions = <00000000 00f80000 + 00f80000 00080001>; + partition-names = "fs\0firmware"; + }; + + More devices will be defined as this spec matures.
arch/powerpc/sysdev/Makefile +1 -0
@@ -13,6 +13,7 @@ obj-$(CONFIG_PPC_83xx) += ipic.o obj-$(CONFIG_FSL_SOC) += fsl_soc.o obj-$(CONFIG_PPC_TODC) += todc.o obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o +obj-$(CONFIG_MTD) += flash.o ifeq ($(CONFIG_PPC_MERGE),y) obj-$(CONFIG_PPC_I8259) += i8259.o
arch/powerpc/sysdev/flash.c new file +104 -0
104 lines not on this page · raw message
Quoted 3 lines · Sergei Shtylyov
+ =A0 h) MTD nodes
+
+ =A0 Memory Technology Devices are flash, ROM, and similar chips, often =
used
Review
Quoted 6 lines
+ =A0 for solid state file systems on embedded devices.
(quoted diff) +5
-0+ + =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
Quoted 2 lines
+ =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 <><
Quoted 16 lines · Arnd Bergmann
Documentation/powerpc/booting-without-of.txt platforms are moved over to use the flat · line 1457
Quoted 11 lines · Sergei Shtylyov
Documentation/powerpc/booting-without-of.txt +11
-0+ 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.
Quoted 11 lines
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.
Quoted 1 line
- model : an identifier for the actual controller chip used.
Meaning what exactly? Lots of NOR flash doesn't have a "controller".
Quoted 2 lines
- 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
Quoted 6 lines
Quoted 2 lines
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 3 lines
Quoted 1 line
- 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 6 lines
Quoted 2 lines
- 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
Hello.
Quoted 2 lines · Segher Boessenkool
Quoted 2 lines
Quoted 2 lines
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 10 lines
Quoted 2 lines
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_typecommunicates 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...
Quoted 3 lines
I suspect for most nand-flash you can get away with a
device_typeof "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 9 lines
Quoted 3 lines
Quoted 1 line
- 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.
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines
- 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!)
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
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
-
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 7 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
device_typecommunicates 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 7 lines
Quoted 3 lines
I suspect for most nand-flash you can get away with a
device_typeof "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 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
- 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 6 lines
Quoted 3 lines
"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