[RFC] Adding MTD to device tree
On Sat, 2006-08-12 at 20:48 +0200, Segher Boessenkool wrote: Memory type devices are specific to Linux? Doubt it. :-) The name mtd is. Actually it came from PCMCIA. -- dwmw2
[RFC] Adding MTD to device tree
Hello. Milton Miller wrote: + 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. Memory type devices are specific to Linux? Doubt it. :-) In fact, device type flash sounds too restrictive. First of all, I was only quoting that. I'm not ascribing them to you. :-) Second, no, memory type devices are not specific to Linux. But the term MTD probably is[1]. I doubt Google based conslusions qualify here. If you don't want to call it flash, then call it rom. The fact that its programable rom is a detail. Important detail, I'd say. 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. - 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. I'm with your suggestion for device_type and model, but not compatable. physmap? What kind of device is that? A Directly mapped NOR flash or ROM I think. I don't know how you got there, without your linux implementation knowledge. Indeed, this was compeletely Linux specific name. command set name, maybe with a width, would be That'd be pretty useless if you don't let Linux know which MTD *map* driver to use. And I have specified the bank-width prop. The fact that its directly mapped should be evident from its location in the device tree and its properties such as reg. Nohow. The flash could be be indirectly accessible and still have the reg prop in the device node. It also may need nasty byte swapping tricks (in which case it's not physmap compatible). I think you are getting caught up the layering of the linux mtd subsystem, and not thinking about describing the hardware. If we end up with the node spec that is correct from the point of description the hardware but absolutely useless when it comes to selectiong the proper driver, what use it would be? appropriate. Physmap is the name of another linux driver. And the role of the compatible prop is exactly to help OS in selecting the driver. Yes, help select. But not say here is the name of the driver to use. Its to specify the programing interface. Well, you may be wrong here. See below. :-) Putting cfi-xxx, cfi, rom would show that it should be probed by cfi instead of by jedec for example. Yes. But that's just no use with the current platform_device base implementation of physmap. So we'd either need to extend this implementation or make physmap parse all that from the device tree by itself. Are we still talking about doing a driver that calls physmap with the appropriate address gathered from of_device? Well, this would not exactly be a driver then. It would be the one to select the nodes compatable nodes, finds the relevant parms, and calls the mtd layer. In fact, I indended to probe the MTD/PPC people which way they like best: sticking with platform_device still, or making physmap of_device aware by itself (although we'd still need to register the flash device somewhere in arch/powerpc/, since there's not code anywhere that register *all* devices found in the device tree)... Even rom would be better than physmap. Doubt it since the ROM is the only one thing (and even the least probable) that we're going to support. But it would make sense to be a later compatible entry ... we can treat the flash as a true read-only memory and it will work, we just will not have the feature of writing to it. Indeed, if compatible incorporated the chip interfaces (probe types for MTD/physmap drivers), that'd have made sense. Alas, with platform_device based approach, we have no way of passing this info to MTD subsys currently. As segher pointed out, compatible is a (specific to generic) list of hints to the programming interface. If you look into the OF specs, compatible and name are treated as the *driver* names here. There are whole passages there warning about not selecting too generic driver names like network. I'll admit I'm not that familiar with the mtd subsystem. But I did go
[RFC] Adding MTD to device tree
In message 44DE4F84.9030802 at ru.mvista.com you wrote: Hm, MTD is a short for memory type device, what Linux has to do with it Memory Technology Device. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.
[RFC] Adding MTD to device tree
In message 91f1d0619c8ff22cf70404059d514857 at bga.com you wrote: Second, no, memory type devices are not specific to Linux. But the term MTD probably is[1]. If you don't want to call it flash, then call it rom. No, it is not. It has been used by other RTOS as well, and probably before Linux. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam
[RFC] Adding MTD to device tree
On Friday 11 August 2006 17:31, Sergei Shtylyov wrote: + ? 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. 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. - 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
[RFC] Adding MTD to device tree
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. - 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... - 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
[RFC] Adding MTD to device tree
Hello. 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 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. - 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 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
[RFC] Adding MTD to device tree
Hello. Milton Miller wrote: + 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. Memory type devices are specific to Linux? Doubt it. :-) In fact, device type flash sounds too restrictive. 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. - 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. I'm with your suggestion for device_type and model, but not compatable. physmap? What kind of device is that? A Directly mapped NOR flash or ROM I think. command set name, maybe with a width, would be That'd be pretty useless if you don't let Linux know which MTD *map* driver to use. And I have specified the bank-width prop. appropriate. Physmap is the name of another linux driver. And the role of the compatible prop is exactly to help OS in selecting the driver. Something like direct or linear might be appropriate for a rom, where just address and length appear. I agree that linear or direct may be better variants. Even rom would be better than physmap. Doubt it since the ROM is the only one thing (and even the least probable) that we're going to support. milton WBR, Sergei
[RFC] Adding MTD to device tree
On Aug 12, 2006, at 12:43 PM, Sergei Shtylyov wrote: Hello. Milton Miller wrote: + 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. Memory type devices are specific to Linux? Doubt it. :-) In fact, device type flash sounds too restrictive. First of all, I was only quoting that. Second, no, memory type devices are not specific to Linux. But the term MTD probably is[1]. If you don't want to call it flash, then call it rom. The fact that its programable rom is a detail. 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. - 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. I'm with your suggestion for device_type and model, but not compatable. physmap? What kind of device is that? A Directly mapped NOR flash or ROM I think. I don't know how you got there, without your linux implementation knowledge. command set name, maybe with a width, would be That'd be pretty useless if you don't let Linux know which MTD *map* driver to use. And I have specified the bank-width prop. The fact that its directly mapped should be evident from its location in the device tree and its properties such as reg. I think you are getting caught up the layering of the linux mtd subsystem, and not thinking about describing the hardware. appropriate. Physmap is the name of another linux driver. And the role of the compatible prop is exactly to help OS in selecting the driver. Yes, help select. But not say here is the name of the driver to use. Its to specify the programing interface. We don't say use the ohci driver but this device has pci class 0C0310 and the ohci-pci driver says I handle devices that are pci class serial subclass usb and programming interface ohci. Putting cfi-xxx, cfi, rom would show that it should be probed by cfi instead of by jedec for example. Are we still talking about doing a driver that calls physmap with the appropriate address gathered from of_device? It would be the one to select the nodes compatable nodes, finds the relevant parms, and calls the mtd layer. Something like direct or linear might be appropriate for a rom, where just address and length appear. I agree that linear or direct may be better variants. Yea. Even rom would be better than physmap. Doubt it since the ROM is the only one thing (and even the least probable) that we're going to support. But it would make sense to be a later compatible entry ... we can treat the flash as a true read-only memory and it will work, we just will not have the feature of writing to it. As segher pointed out, compatible is a (specific to generic) list of hints to the programming interface. I'll admit I'm not that familiar with the mtd subsystem. But I did go and browse the redboot, ebony, and ocetea map drivers, along with physmap. With the addresses filled out, they would appear to collapse into one driver, with multiple device nodes for each one. Except for the partitioning information. Ok that brings up partitions: if you need partitions, and don't have a table system like redboot, then we need some way to convey that in the device tree. My first instinct is that would be via device nodes under the map device in the tree. The nodes would get a reg with relative address and size, and the name would be the name of the partition. We could also do it in properties on the mtd node, but then would not not have a good place to put the name. (Well, we could do a list of strings and a parallel list of partition sizes. I would prefer we not encode both in one property). Yes, we can rely on cmdline partitioning ... but that means a long argument in your device tree you don't want edited. milton [1] Google seems to confirm this: the first several hits are for a power equipment manufacturer, and then linux-mtd site by itself, without other os's mtd projects in the first 4 pages of hits.
[RFC] 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 Signed-off-by: Sergei Shtylyov sshtylyov at ru.mvista.com -- next part -- An embedded and charset-unspecified text was scrubbed... Name: OF-physmap-device.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060811/ebf70715/attachment.txt
[RFC] Adding MTD to device tree
On Fri, 2006-08-11 at 23:10 +0200, Arnd Bergmann wrote: On Friday 11 August 2006 17:31, Sergei Shtylyov wrote: + 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
