Re: OF compatible MTD platform RAM driver ?
On Monday 31 March 2008 00:39, Segher Boessenkool wrote: For RAMs we need something to indicate that it's memory but intended for secondary storage, not as main memory. How it is intended to be used is not a property of the hardware, so that information doesn't belong in the device tree at all. The Linux platform code should handle this, I imagine. There must be some reason why it is not intended to be used as main memory. Presumably it has something different about it compared to normal RAM, and that difference could perfectly well be expressed in the device tree. Sure, that's a different thing. It might sit on a bus that doesn't do cache coherency, or maybe it's just slow (or sits on a slow bus). All these things can be usefully expressed in the device tree (but typically are not, it is left to the client code to know this stuff implicitly). It's still the (platform) probe code its responsibility to figure out what (if anything) to do with any device. And main memory is probed differently (via /chosen/memory, for example) anyway. Well, actually, Linux searches for all nodes with device_type memory, which should work fine as well [*]. So, all in all, I think we should just give these auxiliary memory devices a name of ram c.q. rom, and some reg, and that should be all that is needed: the main memory probe stuff won't consider these nodes, and the (platform) device probe code can do whatever it wants (create mtd devices, I guess). Ok, I get your point. I'll prepare a new documentation patch; changes to physmap_of.c will go away. If I understand you correctly, there should be no compatible property on the ram and rom devices. Should the non-volatile, slow and static ram properties still be expressed in the device tree ? -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
So, all in all, I think we should just give these auxiliary memory devices a name of ram c.q. rom, and some reg, and that should be all that is needed: the main memory probe stuff won't consider these nodes, and the (platform) device probe code can do whatever it wants (create mtd devices, I guess). Ok, I get your point. I'll prepare a new documentation patch; changes to physmap_of.c will go away. Thanks. If I understand you correctly, there should be no compatible property on the ram and rom devices. They aren't normally needed here, I think. Should the non-volatile, slow and static ram properties still be expressed in the device tree ? If those are useful. I'll need to see a proposed binding to form an opinion on this, it's too vague now, sorry. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
memory-mapped-memory perhaps :-) Or, just memory. Although that one might play havoc with some I'd suggest ram and rom then. Luckily the device trees don't contain binding for the real RAM chips yet. :-) not-quite-correct main memory probing code. You mean the there's parsers that search the compatible prop for memory as well as device_type prop? There are parsers that make all kinds of mistakes, sure. The code that figures out what region of ram to use should look at the node pointed to by /chosen/memory, it's shouldn't look for anything with a certain compatible, and it shouldn't look at device_type _at all_. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Could we agree on a name ? I'd like to submit a new patch. For ROMs I think just plain rom should be sufficient. Yes. For RAMs we need something to indicate that it's memory but intended for secondary storage, not as main memory. How it is intended to be used is not a property of the hardware, so that information doesn't belong in the device tree at all. The Linux platform code should handle this, I imagine. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Segher Boessenkool writes: For RAMs we need something to indicate that it's memory but intended for secondary storage, not as main memory. How it is intended to be used is not a property of the hardware, so that information doesn't belong in the device tree at all. The Linux platform code should handle this, I imagine. There must be some reason why it is not intended to be used as main memory. Presumably it has something different about it compared to normal RAM, and that difference could perfectly well be expressed in the device tree. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
For RAMs we need something to indicate that it's memory but intended for secondary storage, not as main memory. How it is intended to be used is not a property of the hardware, so that information doesn't belong in the device tree at all. The Linux platform code should handle this, I imagine. There must be some reason why it is not intended to be used as main memory. Presumably it has something different about it compared to normal RAM, and that difference could perfectly well be expressed in the device tree. Sure, that's a different thing. It might sit on a bus that doesn't do cache coherency, or maybe it's just slow (or sits on a slow bus). All these things can be usefully expressed in the device tree (but typically are not, it is left to the client code to know this stuff implicitly). It's still the (platform) probe code its responsibility to figure out what (if anything) to do with any device. And main memory is probed differently (via /chosen/memory, for example) anyway. Well, actually, Linux searches for all nodes with device_type memory, which should work fine as well [*]. So, all in all, I think we should just give these auxiliary memory devices a name of ram c.q. rom, and some reg, and that should be all that is needed: the main memory probe stuff won't consider these nodes, and the (platform) device probe code can do whatever it wants (create mtd devices, I guess). Segher [*] It seems to me the longtrail workaround code in prom_init.c is incorrect though: it will match any node with name memory that doesn't have a device_type? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Segher Boessenkool writes: It's still the (platform) probe code its responsibility to figure out what (if anything) to do with any device. And main memory is probed differently (via /chosen/memory, for example) anyway. Well, actually, Linux searches for all nodes with device_type memory, which should work fine as well [*]. So, all in all, I think we should just give these auxiliary memory devices a name of ram c.q. rom, and some reg, and that should be all that is needed: the main memory probe stuff won't consider these nodes, and the (platform) device probe code can do whatever it wants (create mtd devices, I guess). Sounds reasonable. [*] It seems to me the longtrail workaround code in prom_init.c is incorrect though: it will match any node with name memory that doesn't have a device_type? It only matches on children of the root node, and it's that way because the /memory node in the longtrail device tree doesn't have a device_type. Actually we could probably remove the longtrail stuff now; I think mine has stopped working, and I only know of 2 others in existence. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
[*] It seems to me the longtrail workaround code in prom_init.c is incorrect though: it will match any node with name memory that doesn't have a device_type? It only matches on children of the root node, Oh okay, I misread that then. and it's that way because the /memory node in the longtrail device tree doesn't have a device_type. Yeah. Actually we could probably remove the longtrail stuff now; I think mine has stopped working, and I only know of 2 others in existence. :) I'll prepare a patch. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
[Removed linux-mtd from cc:] [*] It seems to me the longtrail workaround code in prom_init.c is incorrect though: it will match any node with name memory that doesn't have a device_type? It only matches on children of the root node, Oh okay, I misread that then. ...No, I did not. prom_next_node() does a depth-first tree traversal. Actually we could probably remove the longtrail stuff now; I think mine has stopped working, and I only know of 2 others in existence. :) I'll prepare a patch. ...Actually, that's a lot of code to rip out, and I can't test this at all, so I'll have to pass on this. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
David Gibson wrote: Heh, we've gone thru physmap before -- it was labelled Linux-specific name (well, I'd agree with that). 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 :-) 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. 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. :-) Main memory is also direct physically mapped, after all, but that's not what you want to cover with this description. 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)... :-( In general how a device is wired is described by where it sits in the tree, not by its properties. 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). 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. 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. 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. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote: Laurent Pinchart wrote: Regarding non-volatility nothing prevents a user from using a volatile RAM as an MTD device, but there's little point in doing so. Would it be acceptable for the linear-nvram specification not to include volatile RAM ? ROM chips would be excluded too. Is that an issue ? We actually use a volatile ram (SRAM) as an MTD device. We use it to store info from bootloader and system specific values between resets. So we're left with two main options. - Reusing the nvram device type from the Device Support Extensions. Volatile devices wouldn't be supported, and we'd need a separate device specification for linear-mapped volatile RAMs. I'm not very happy with that. - Using another device node with a compatible value set to linear-ram (or something similar). This would support both volatile and non-volatile devices, and a property could be added to specify if the device is volatile or not. I'd go for the second option, and I'd specify a linear-rom compatible value as well while we're at it. Both volatile and non-volatile RAMs can be handled by the physmap_of MTD driver. They both use the same map probe type (map_ram). Volatility isn't handled there. ROMs should be handled by the same driver and should use the mtd_rom map probe type. OK, let's go with it. As all those devices use the physmap_of MTD driver, what about using physmap-ram and physmap-rom as compatibility names ? Heh, we've gone thru physmap before -- it was labelled Linux-specific name (well, I'd agree with that). 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 :-) Could we agree on a name ? I'd like to submit a new patch. -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Wednesday 26 March 2008 16:40, Sergei Shtylyov wrote: Segher Boessenkool wrote: - Using another device node with a compatible value set to linear-ram (or something similar). This would support both volatile and non-volatile devices, and a property could be added to specify if the device is volatile or not. memory-mapped-memory perhaps :-) Or, just memory. Although that one might play havoc with some I'd suggest ram and rom then. Luckily the device trees don't contain binding for the real RAM chips yet. :-) And when it will we'll be in trouble. Here are a few names. I like physmap-r[ao]m better. Does anyone have another suggestion ? I'd like to send a revised patch. linear-r[ao]m linear-mapped-r[ao]m mapped-r[ao]m memory-mapped-r[ao]m physmap-r[ao]m not-quite-correct main memory probing code. You mean the there's parsers that search the compatible prop for memory as well as device_type prop? -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpS3dubbrOIr.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Hello. David Gibson wrote: Laurent Pinchart wrote: [snip] Heh, we've gone thru physmap before -- it was labelled Linux-specific name (well, I'd agree with that). 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 :-) 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. 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. :-) Main memory is also direct physically mapped, after all, but that's not what you want to cover with this description. 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). In general how a device is wired is described by where it sits in the tree, not by its properties. Oh, another argument against reg-shift in the Xilinx UART quarry... :-) It only seems like a usefully distinguishing name because it's the Linux physmap_of driver that uses it. So in this sense it is a Linux specific name after all. In fact, physmap_of is itself very badly named - right now it only handles direct mapped mtds, but that's Yeah, because that's what is what it has been written for. 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. This driver resides on the top, device mapping layer of the MTD 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/ -- as it has been done in the MTD tree before the great OF revolution. This is really strange idea... WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Thursday 27 March 2008 11:03, David Gibson wrote: On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote: On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote: Laurent Pinchart wrote: [snip] Heh, we've gone thru physmap before -- it was labelled Linux-specific name (well, I'd agree with that). 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 :-) 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. Main memory is also direct physically mapped, after all, but that's not what you want to cover with this description. In general how a device is wired is described by where it sits in the tree, not by its properties. It only seems like a usefully distinguishing name because it's the Linux physmap_of driver that uses it. So in this sense it is a Linux specific name after all. In fact, physmap_of is itself very badly named - right now it only handles direct mapped mtds, but that's 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. Could we agree on a name ? I'd like to submit a new patch. For ROMs I think just plain rom should be sufficient. For RAMs we need something to indicate that it's memory but intended for secondary storage, not as main memory. Unfortunately, I'm finding myself unable to think of something. What about storage-ram, auxiliary-ram, secondary-ram, application-ram, user-ram or ramdisk ? -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Thu, Mar 27, 2008 at 03:23:46PM +0300, Sergei Shtylyov wrote: Hello. David Gibson wrote: Laurent Pinchart wrote: [snip] Heh, we've gone thru physmap before -- it was labelled Linux-specific name (well, I'd agree with that). 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 :-) 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. 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. :-) Main memory is also direct physically mapped, after all, but that's not what you want to cover with this description. 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. In general how a device is wired is described by where it sits in the tree, not by its properties. 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. It only seems like a usefully distinguishing name because it's the Linux physmap_of driver that uses it. So in this sense it is a Linux specific name after all. In fact, physmap_of is itself very badly named - right now it only handles direct mapped mtds, but that's Yeah, because that's what is what it has been written for. 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. This driver resides on the top, device mapping layer of the MTD 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 *nothing* that actually relies on the direct mapping in physmap_of; the *only* thing it does is take the device tree information and marshal it into an initialization call for the appropriate mtd chip drivers. I really should get around to sending a patch to rename physmap_of to of_mtd.c. -- 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) is because there wasn't a single generally available source of information about where and how flash was mapped so a whole pile of platform or sitation specific ways of getting that information were needed. With a device tree all that can be replaced with just getting the information from the device tree. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Thu, Mar 27, 2008 at 03:31:34PM +0100, Laurent Pinchart wrote: On Thursday 27 March 2008 11:03, David Gibson wrote: On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote: On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote: Laurent Pinchart wrote: [snip] Heh, we've gone thru physmap before -- it was labelled Linux-specific name (well, I'd agree with that). 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 :-) 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. Main memory is also direct physically mapped, after all, but that's not what you want to cover with this description. In general how a device is wired is described by where it sits in the tree, not by its properties. It only seems like a usefully distinguishing name because it's the Linux physmap_of driver that uses it. So in this sense it is a Linux specific name after all. In fact, physmap_of is itself very badly named - right now it only handles direct mapped mtds, but that's 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. Could we agree on a name ? I'd like to submit a new patch. For ROMs I think just plain rom should be sufficient. For RAMs we need something to indicate that it's memory but intended for secondary storage, not as main memory. Unfortunately, I'm finding myself unable to think of something. What about storage-ram, auxiliary-ram, secondary-ram, application-ram, user-ram or ramdisk ? Well, I like all those better than anything previously suggested. storage-ram is probably my favourite. It still doesn't seem great, but given I've been unable to thing of something better. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Laurent Pinchart wrote: Regarding non-volatility nothing prevents a user from using a volatile RAM as an MTD device, but there's little point in doing so. Would it be acceptable for the linear-nvram specification not to include volatile RAM ? ROM chips would be excluded too. Is that an issue ? We actually use a volatile ram (SRAM) as an MTD device. We use it to store info from bootloader and system specific values between resets. So we're left with two main options. - Reusing the nvram device type from the Device Support Extensions. Volatile devices wouldn't be supported, and we'd need a separate device specification for linear-mapped volatile RAMs. I'm not very happy with that. - Using another device node with a compatible value set to linear-ram (or something similar). This would support both volatile and non-volatile devices, and a property could be added to specify if the device is volatile or not. I'd go for the second option, and I'd specify a linear-rom compatible value as well while we're at it. Both volatile and non-volatile RAMs can be handled by the physmap_of MTD driver. They both use the same map probe type (map_ram). Volatility isn't handled there. ROMs should be handled by the same driver and should use the mtd_rom map probe type. OK, let's go with it. As all those devices use the physmap_of MTD driver, what about using physmap-ram and physmap-rom as compatibility names ? Heh, we've gone thru physmap before -- it was labelled Linux-specific name (well, I'd agree with that). Best regards, WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
So we're left with two main options. - Reusing the nvram device type from the Device Support Extensions. This wouldn't bring you anything. A device_type is only used internally by OF, to decide what device nodes support which OF programming model. If you only have a flat device tree, device_type should be used only as a workaround for older kernels that require it. - Using another device node with a compatible value set to linear-ram (or something similar). This would support both volatile and non-volatile devices, and a property could be added to specify if the device is volatile or not. memory-mapped-memory perhaps :-) Or, just memory. Although that one might play havoc with some not-quite-correct main memory probing code. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Segher Boessenkool wrote: - Using another device node with a compatible value set to linear-ram (or something similar). This would support both volatile and non-volatile devices, and a property could be added to specify if the device is volatile or not. memory-mapped-memory perhaps :-) Or, just memory. Although that one might play havoc with some I'd suggest ram and rom then. Luckily the device trees don't contain binding for the real RAM chips yet. :-) not-quite-correct main memory probing code. You mean the there's parsers that search the compatible prop for memory as well as device_type prop? Segher WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Tuesday 11 March 2008 23:40, David Gibson wrote:
On Tue, Mar 11, 2008 at 11:39:08AM +0100, Laurent Pinchart wrote:
On Tuesday 11 March 2008 01:45, David Gibson wrote:
On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
[EMAIL PROTECTED] wrote:
[snip]
We ran ito the same issue.
We did option 3, as it was efinetly the easiest,
I think this is the best option in principle.
I'll implement that and post a patch after completing the ppc-to-powerpc
migration.
here is the sram entry in our dts:
Except that your implementation of it is not good.
You're relying on the old obsolete flash binding with the probe-type
field. The solution should be adapted to the new approach which uses
values in the compatible field to indicate various sorts of flash
device.
What compatible values should I use for ROM and RAM mappings ?
That I'm not so sure of. We'll need to find some consensus.
There may be existing IEEE1275 bindings for roms, which we should
investigate.
Do you (or someone else here) have access to the IEEE1275 specification ? Is
there any ROM binding in there ?
Arguably RAM should be represented by a memory node, but
that's going to get messy for this sort of application.
We're talking about a very specific type of RAM, used for permanent storage
with a battery backup. The RAM is really meant to be used as an MTD device
and as such I think it makes sense to describe it as an mtd-compatible device
on the local bus.
What about the following definition for the RAM node ?
[EMAIL PROTECTED], {
compatible = mtd,ram;
reg = 2 0x 0x0010;
bank-width = 2;
};
Or should the node have a device-type property of either 'ram' or 'rom' with
the compatible property just referencing MTD ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpBeTwQpIHsf.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Hello.
Laurent Pinchart wrote:
here is the sram entry in our dts:
Except that your implementation of it is not good.
You're relying on the old obsolete flash binding with the probe-type
field. The solution should be adapted to the new approach which uses
values in the compatible field to indicate various sorts of flash
device.
What compatible values should I use for ROM and RAM mappings ?
That I'm not so sure of. We'll need to find some consensus.
There may be existing IEEE1275 bindings for roms, which we should
investigate.
Do you (or someone else here) have access to the IEEE1275 specification ? Is
Yeah, and I can point you to it -- see the documantation section on
http://www.openbios.org/...
there any ROM binding in there ?
No. We initially called the flash devices that physmap_of driver
controlled rom (I mean the device_type property) -- now this is obsoleted.
Arguably RAM should be represented by a memory node, but
that's going to get messy for this sort of application.
Note that the OF memory type nodes do *not* represent RAM devices.
We're talking about a very specific type of RAM, used for permanent storage
with a battery backup. The RAM is really meant to be used as an MTD device
and as such I think it makes sense to describe it as an mtd-compatible device
on the local bus.
What about the following definition for the RAM node ?
[EMAIL PROTECTED], {
Note that there's a OF device_type of nvram, so your (generic) device
name seems to add some mess. (IIRC, that OF device type didn't actually
represent a real device, and only served to provide access to NVRAM for OF).
compatible = mtd,ram;
The part before comma should be a company name or a stock ticker. What did
you mean here?
reg = 2 0x 0x0010;
bank-width = 2;
};
Or should the node have a device-type property of either 'ram' or 'rom' with
the compatible property just referencing MTD ?
The device_type properties are not required and their further creation
has been discouraged on liunxppc-dev.
Best regards,
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Hi Sergei,
On Tuesday 25 March 2008 16:29, Sergei Shtylyov wrote:
Hello.
Laurent Pinchart wrote:
here is the sram entry in our dts:
Except that your implementation of it is not good.
You're relying on the old obsolete flash binding with the probe-type
field. The solution should be adapted to the new approach which uses
values in the compatible field to indicate various sorts of flash
device.
What compatible values should I use for ROM and RAM mappings ?
That I'm not so sure of. We'll need to find some consensus.
There may be existing IEEE1275 bindings for roms, which we should
investigate.
Do you (or someone else here) have access to the IEEE1275 specification ?
Is
Yeah, and I can point you to it -- see the documantation section on
http://www.openbios.org/...
Thanks a lot for the pointer.
there any ROM binding in there ?
No. We initially called the flash devices that physmap_of driver
controlled rom (I mean the device_type property) -- now this is obsoleted.
Arguably RAM should be represented by a memory node, but
that's going to get messy for this sort of application.
Note that the OF memory type nodes do *not* represent RAM devices.
We're talking about a very specific type of RAM, used for permanent storage
with a battery backup. The RAM is really meant to be used as an MTD device
and as such I think it makes sense to describe it as an mtd-compatible
device
on the local bus.
What about the following definition for the RAM node ?
[EMAIL PROTECTED], {
Note that there's a OF device_type of nvram, so your (generic) device
name seems to add some mess. (IIRC, that OF device type didn't actually
represent a real device, and only served to provide access to NVRAM for OF).
Ok.
compatible = mtd,ram;
The part before comma should be a company name or a stock ticker. What
did
you mean here?
I didn't know that. Let's say I meant mtd-ram :-)
reg = 2 0x 0x0010;
bank-width = 2;
};
Or should the node have a device-type property of either 'ram' or 'rom'
with
the compatible property just referencing MTD ?
The device_type properties are not required and their further creation
has been discouraged on liunxppc-dev.
What about
[EMAIL PROTECTED], {
compatible = mtd-ram;
reg = 2 0x 0x0010;
bank-width = 2;
};
ROMs could use mtd-rom for their compatible property.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpMOYAiInRmR.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Tuesday 25 March 2008 17:23, Sergei Shtylyov wrote:
Laurent Pinchart wrote:
We're talking about a very specific type of RAM, used for permanent
storage
with a battery backup. The RAM is really meant to be used as an MTD
device
and as such I think it makes sense to describe it as an mtd-compatible
device
on the local bus.
What about the following definition for the RAM node ?
[EMAIL PROTECTED], {
Note that there's a OF device_type of nvram, so your (generic)
device
name seems to add some mess. (IIRC, that OF device type didn't actually
represent a real device, and only served to provide access to NVRAM for
OF).
Ok.
Well, I might have gone too far here -- it should be a real device
(spec'ed in Device Support Extensions recommended practice). It's just that
the spec didn't mention reg property, only #bytes (the device capacity).
So, it may be worth considering...
The nvram device descrived in the Device Support Extensions is probably meant
to describe the kind of nvram found in RTC chips. That memory isn't directly
accessible. As the spec doesn't mention this explicitely we could still reuse
the nvram device type for direct-mapped battery-backed ram. I have no strong
opinion for or against that.
compatible = mtd,ram;
The part before comma should be a company name or a stock ticker. What
did
you mean here?
I didn't know that. Let's say I meant mtd-ram :-)
reg = 2 0x 0x0010;
bank-width = 2;
};
Or should the node have a device-type property of either 'ram' or 'rom'
with
the compatible property just referencing MTD ?
The device_type properties are not required and their further
creation
has been discouraged on liunxppc-dev.
What about
[EMAIL PROTECTED], {
compatible = mtd-ram;
reg = 2 0x 0x0010;
bank-width = 2;
};
ROMs could use mtd-rom for their compatible property.
Heh, there was a whole company against mentioning mtd when we started
working on this (of course, the first idea was to call the flash device type
mtd). I don't think mtd looks good here -- I'd suggest flash-ram (if
this is just a linearly mapped NVRAM).
I'm fine with flash-ram (even thought it looks a bit weird). I'll prepare a
patch.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpzz0chgLDkF.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Laurent Pinchart wrote:
We're talking about a very specific type of RAM, used for permanent storage
with a battery backup. The RAM is really meant to be used as an MTD device
and as such I think it makes sense to describe it as an mtd-compatible device
on the local bus.
What about the following definition for the RAM node ?
[EMAIL PROTECTED], {
Note that there's a OF device_type of nvram, so your (generic) device
name seems to add some mess. (IIRC, that OF device type didn't actually
represent a real device, and only served to provide access to NVRAM for OF).
Ok.
Well, I might have gone too far here -- it should be a real device
(spec'ed in Device Support Extensions recommended practice). It's just that
the spec didn't mention reg property, only #bytes (the device capacity).
So, it may be worth considering...
The nvram device descrived in the Device Support Extensions is probably meant
to describe the kind of nvram found in RTC chips.
Well, that is only an assumption -- actually, the sentense in the
description of the #bytes prop about the typical size being from 4 to 32K
speaks against it. The details of NVRAM implementation are hidden behind
read/write/seek methods.
That memory isn't directly accessible.
That's what we have a compatible prop for. ;-)
As the spec doesn't mention this explicitely we could still reuse
the nvram device type for direct-mapped battery-backed ram. I have no strong
opinion for or against that.
reg = 2 0x 0x0010;
bank-width = 2;
};
Or should the node have a device-type property of either 'ram' or 'rom' with
the compatible property just referencing MTD ?
The device_type properties are not required and their further creation
has been discouraged on liunxppc-dev.
What about
[EMAIL PROTECTED], {
compatible = mtd-ram;
reg = 2 0x 0x0010;
bank-width = 2;
};
ROMs could use mtd-rom for their compatible property.
Heh, there was a whole company against mentioning mtd when we started
working on this (of course, the first idea was to call the flash device type
mtd). I don't think mtd looks good here -- I'd suggest flash-ram (if
this is just a linearly mapped NVRAM).
I'm fine with flash-ram (even thought it looks a bit weird). I'll prepare a
patch.
Yeah. I forgeot that flash means EEPROM. Actually, the main facts about
the NVRAM that I'd want to be stated in the compatible property is that it's
non-volatile and directly/lineraly mapped... Just nvram doesn't seem
enopugh, maybe linear-nvram is. And we can specify device_type of nvram
indeed (and #size).
Best regards,
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote: Laurent Pinchart wrote: Heh, there was a whole company against mentioning mtd when we started working on this (of course, the first idea was to call the flash device type mtd). I don't think mtd looks good here -- I'd suggest flash-ram (if this is just a linearly mapped NVRAM). I'm fine with flash-ram (even thought it looks a bit weird). I'll prepare a patch. Yeah. I forgeot that flash means EEPROM. Actually, the main facts about the NVRAM that I'd want to be stated in the compatible property is that it's non-volatile and directly/lineraly mapped... Just nvram doesn't seem enopugh, maybe linear-nvram is. Direct mapping is a hard requirement for the nvram if we want to use it with the MTD subsystem. Regarding non-volatility nothing prevents a user from using a volatile RAM as an MTD device, but there's little point in doing so. Would it be acceptable for the linear-nvram specification not to include volatile RAM ? ROM chips would be excluded too. Is that an issue ? And we can specify device_type of nvram indeed (and #size). I suppose you meant #bytes. What about sub-partitions support ? Nothing prevents RAM-based MTD devices from being partioned. Would it be acceptable to reference the CFI/JEDEC flash section in Documentation/powerpc/booting-without-of.txt in the description of the nvram node ? Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpFY5Ra1Z7Qi.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Laurent Pinchart wrote: Heh, there was a whole company against mentioning mtd when we started working on this (of course, the first idea was to call the flash device type mtd). I don't think mtd looks good here -- I'd suggest flash-ram (if this is just a linearly mapped NVRAM). I'm fine with flash-ram (even thought it looks a bit weird). I'll prepare a patch. Yeah. I forgeot that flash means EEPROM. Actually, the main facts about the NVRAM that I'd want to be stated in the compatible property is that it's non-volatile and directly/lineraly mapped... Just nvram doesn't seem enopugh, maybe linear-nvram is. Direct mapping is a hard requirement for the nvram if we want to use it with the MTD subsystem. I thought we're currently talking about a driver controlling the directly mapped NVRAM. The compatible property wouldn't allow us to specify the compatibility to *any* NVRAM since there could be no least common denominator driver anyway. Regarding non-volatility nothing prevents a user from using a volatile RAM as an MTD device, but there's little point in doing so. Indeed, if just for testing... we could specify non-volatility as the device's prop, though... Would it be acceptable for the linear-nvram specification not to include volatile RAM ? ROM chips would be excluded too. Is that an issue ? Well, I think we need a separate compatible prop for ROMs. Or we'll end up with the compatible being just memory with the memory attributes (R/O, N/V) being described by other properties... :-) And we can specify device_type of nvram indeed (and #size). I suppose you meant #bytes. Of course. :-) What about sub-partitions support ? Nothing prevents RAM-based MTD devices Hm... I remember that the knowledge of MTD partitions turned me away from nvram device type when I started spec'ing the flash binding -- it's not uncommon to have a flash partition devoted to and labelled as nvram. Therefore, that sole partition would have been a nvram device for OF... from being partioned. Would it be acceptable to reference the CFI/JEDEC flash section in Documentation/powerpc/booting-without-of.txt in the description of the nvram node ? I don't see why not. Best regards, WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: OF compatible MTD platform RAM driver ?
Laurent Pinchart wrote: On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote: Laurent Pinchart wrote: Regarding non-volatility nothing prevents a user from using a volatile RAM as an MTD device, but there's little point in doing so. Would it be acceptable for the linear-nvram specification not to include volatile RAM ? ROM chips would be excluded too. Is that an issue ? We actually use a volatile ram (SRAM) as an MTD device. We use it to store info from bootloader and system specific values between resets. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Tuesday 11 March 2008 01:45, David Gibson wrote: On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote: [EMAIL PROTECTED] wrote: Hi everybody, as part of a ARCH=ppc to ARCH=powerpc migration process, I'm looking for an OpenFirmware compatible way to handle a RAM-based MTD device. On the platform_device based ppc architecture, the drivers/mtd/maps/plat-ram.c driver handled mtd-ram platform devices. There is no such driver for the OF-based powerpc architecture. As a temporary workaround I hacked the physmap_of driver to handle direct-mapped OF devices oh type ram by adding a corresponding entry in the of_flash_match[] array. This seems to work fine. What would be the preferred way to handle OF-compatible RAM-based MTD devices ? The 3 ways I can think of are 1. porting the plat-ram driver to OF (the driver isn't used in the kernel tree but I suspect it is used by out-of-tree boards) 2. creating a new plat-ram-of driver, much like the physmap_of driver comes from the physmap driver 3. extending the physmap_of driver to handle RAM devices (in which case references to flash in the function names should probably be replaced by mtd) I live option 3 better so far. Has anyone already worked on this ? Is there any defined device tree mapping for MTD RAM devices ? We ran ito the same issue. We did option 3, as it was efinetly the easiest, I think this is the best option in principle. I'll implement that and post a patch after completing the ppc-to-powerpc migration. here is the sram entry in our dts: Except that your implementation of it is not good. You're relying on the old obsolete flash binding with the probe-type field. The solution should be adapted to the new approach which uses values in the compatible field to indicate various sorts of flash device. What compatible values should I use for ROM and RAM mappings ? Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgp2iwSqncFAX.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: OF compatible MTD platform RAM driver ?
David Gibson wrote: On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote: We ran ito the same issue. We did option 3, as it was efinetly the easiest, I think this is the best option in principle. here is the sram entry in our dts: Except that your implementation of it is not good. You're relying on the old obsolete flash binding with the probe-type field. The solution should be adapted to the new approach which uses values in the compatible field to indicate various sorts of flash device. Yea, I know. But it was the easiest way of doing it at the time we did our port In a timecrunch, easier is sometimes better than correct. :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Tue, Mar 11, 2008 at 11:39:08AM +0100, Laurent Pinchart wrote: On Tuesday 11 March 2008 01:45, David Gibson wrote: On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote: [EMAIL PROTECTED] wrote: [snip] We ran ito the same issue. We did option 3, as it was efinetly the easiest, I think this is the best option in principle. I'll implement that and post a patch after completing the ppc-to-powerpc migration. here is the sram entry in our dts: Except that your implementation of it is not good. You're relying on the old obsolete flash binding with the probe-type field. The solution should be adapted to the new approach which uses values in the compatible field to indicate various sorts of flash device. What compatible values should I use for ROM and RAM mappings ? That I'm not so sure of. We'll need to find some consensus. There may be existing IEEE1275 bindings for roms, which we should investigate. Arguably RAM should be represented by a memory node, but that's going to get messy for this sort of application. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: OF compatible MTD platform RAM driver ?
[EMAIL PROTECTED] wrote:
Hi everybody,
as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
looking for an
OpenFirmware compatible way to handle a RAM-based MTD device.
On the platform_device based ppc architecture, the
drivers/mtd/maps/plat-ram.c
driver handled mtd-ram platform devices. There is no such
driver for the
OF-based powerpc architecture.
As a temporary workaround I hacked the physmap_of driver to
handle direct-mapped OF devices oh type ram by adding a
corresponding entry in the of_flash_match[] array. This seems to work
fine.
What would be the preferred way to handle OF-compatible RAM-based MTD
devices ? The 3 ways I can think of are
1. porting the plat-ram driver to OF (the driver isn't used
in the kernel tree
but I suspect it is used by out-of-tree boards)
2. creating a new plat-ram-of driver, much like the
physmap_of driver comes
from the physmap driver
3. extending the physmap_of driver to handle RAM devices (in
which case
references to flash in the function names should probably
be replaced
by mtd)
I live option 3 better so far.
Has anyone already worked on this ? Is there any defined
device tree mapping
for MTD RAM devices ?
Best regards,
We ran ito the same issue.
We did option 3, as it was efinetly the easiest,
here is the sram entry in our dts:
[EMAIL PROTECTED],0 {
device_type = rom;
compatible = direct-mapped;
probe-type = RAM;
reg = 9 0 2;
bank-width = 2;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
[EMAIL PROTECTED] {
label = SRAM;
reg = 0 2;
};
here is the change to physmap_of.c:
diff --git a/drivers/mtd/maps/physmap_of.c
b/drivers/mtd/maps/physmap_of.c
old mode 100644
new mode 100755
index aeed9ea..687ef54
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -201,6 +201,8 @@ static struct mtd_info * __devinit
obsolete_probe(struct of_device *dev,
return do_map_probe(cfi_probe, map);
} else if (strcmp(of_probe, JEDEC) == 0) {
return do_map_probe(jedec_probe, map);
+ } else if (strcmp(of_probe, RAM) == 0) {
+ return do_map_probe(map_ram, map);
} else {
if (strcmp(of_probe, ROM) != 0)
dev_warn(dev-dev, obsolete_probe: don't know
probe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote: [EMAIL PROTECTED] wrote: Hi everybody, as part of a ARCH=ppc to ARCH=powerpc migration process, I'm looking for an OpenFirmware compatible way to handle a RAM-based MTD device. On the platform_device based ppc architecture, the drivers/mtd/maps/plat-ram.c driver handled mtd-ram platform devices. There is no such driver for the OF-based powerpc architecture. As a temporary workaround I hacked the physmap_of driver to handle direct-mapped OF devices oh type ram by adding a corresponding entry in the of_flash_match[] array. This seems to work fine. What would be the preferred way to handle OF-compatible RAM-based MTD devices ? The 3 ways I can think of are 1. porting the plat-ram driver to OF (the driver isn't used in the kernel tree but I suspect it is used by out-of-tree boards) 2. creating a new plat-ram-of driver, much like the physmap_of driver comes from the physmap driver 3. extending the physmap_of driver to handle RAM devices (in which case references to flash in the function names should probably be replaced by mtd) I live option 3 better so far. Has anyone already worked on this ? Is there any defined device tree mapping for MTD RAM devices ? We ran ito the same issue. We did option 3, as it was efinetly the easiest, I think this is the best option in principle. here is the sram entry in our dts: Except that your implementation of it is not good. You're relying on the old obsolete flash binding with the probe-type field. The solution should be adapted to the new approach which uses values in the compatible field to indicate various sorts of flash device. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
