Re: [RFC] Adding MTD to device tree

Re: [RFC] Adding MTD to device tree

[Milton Miller]

T24gIEZyaSBBdWcgMTEgMjAwNiAwNDoxMDo0MCBQTSBDRFQsIEFybmQgQmVyZ21hbm4gd3JvdGU6
DQo+IE9uIEZyaWRheSAxMSBBdWd1c3QgMjAwNiAxNzozMSwgU2VyZ2VpIFNodHlseW92IHdyb3Rl
Og0KPiA+ICsgwqAgaCkgTVREIG5vZGVzDQo+ID4gKw0KPiA+ICsgwqAgTWVtb3J5IFRlY2hub2xv
Z3kgRGV2aWNlcyBhcmUgZmxhc2gsIFJPTSwgYW5kIHNpbWlsYXIgY2hpcHMsIG9mdGVuIHVzZWQN
Cj4gPiArIMKgIGZvciBzb2xpZCBzdGF0ZSBmaWxlIHN5c3RlbXMgb24gZW1iZWRkZWQgZGV2aWNl
cy4NCj4gPiArDQo+ID4gKyDCoCBSZXF1aXJlZCBwcm9wZXJ0aWVzOg0KPiA+ICsNCj4gPiArIMKg
IMKgLSBkZXZpY2VfdHlwZSA6IGhhcyB0byBiZSAibXRkIg0KPiA+ICsgwqAgwqAtIGNvbXBhdGli
bGUgOiBTaG91bGQgYmUgdGhlIG5hbWUgb2YgdGhlIE1URCBkcml2ZXIuIEN1cnJlbnRseSwgdGhp
cyBpcw0KPiA+ICsgwqAgwqAgwqBtb3N0IGxpa2VseSB0byBiZSAicGh5c21hcCIuDQo+ID4gKyDC
oCDCoC0gcmVnIDogT2Zmc2V0IGFuZCBsZW5ndGggb2YgdGhlIHJlZ2lzdGVyIHNldCBmb3IgdGhl
IGRldmljZS4NCj4gDQo+IEkgd291bGQgcHJlZmVyIHRvIGNhbGwgdGhlbSBzb21ldGhpbmcgZGlm
ZmVyZW50IGluIHRoZSBkZXZpY2UgdHJlZS4NCj4gVGhlIG5hbWUgJ210ZCcgaXMgdmVyeSBzcGVj
aWZpYyB0byBMaW51eCwgYnV0IHRoZSBkZXZpY2UgdHJlZQ0KPiBpcyBhIG1vcmUgZ2VuZXJpYyBj
b25jZXB0Lg0KPiANCj4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlIGJvb3Rpbmctd2l0aG91dC1vZi50
eHQgZmlsZSBpcyBieSBkZWZpbml0aW9uDQo+IExpbnV4IHNwZWNpZmljIGFzIHdlbGwsIGJ1dCB3
ZSBzaG91bGQgYmUgcHJlcGFyZWQgZm9yIG1ha2luZyBwYXJ0cw0KPiBvZiBpdCBhIE9TIGluZGVw
ZW5kZW50IGJpbmRpbmcgYXQgdGhlIHBvaW50IHdoZXJlIHdlIHB1dCB0aGUgc2FtZQ0KPiBkZXZp
Y2Ugbm9kZXMgaW50byBhY3R1YWwgT0YgaW1wbGVtZW50YXRpb25zIHRoYXQgYWJsZSB0byBib290
DQo+IGRpZmZlcmVudCBvcGVyYXRpbmcgc3lzdGVtcy4NCj4gDQo+IEkgd291bGQgcHJlZmVyIGEg
bmFtaW5nIHRoYXQgaGFzIA0KPiANCj4gICAgUmVxdWlyZWQgcHJvcGVydGllczoNCj4gICAgIC0g
ZGV2aWNlX3R5cGUgOiBvbmUgb2YgIm5hbmQtZmxhc2giLCAibm9yLWZsYXNoIiwgb3IgInJvbSIu
DQo+ICAgICAtIG1vZGVsIDogYW4gaWRlbnRpZmllciBmb3IgdGhlIGFjdHVhbCBjb250cm9sbGVy
IGNoaXAgdXNlZC4NCj4gICAgIC0gY29tcGF0aWJsZSA6IFNob3VsZCBiZSB0aGUgbmFtZSBvZiB0
aGUgTVREIGRyaXZlci4gRm9yDQo+ICAgICAgIHR5cGUgInJvbSIsIHRoaXMgaXMgbW9zdCBsaWtl
bHkgInBoeXNtYXAiLg0KDQpJJ20gd2l0aCB5b3VyIHN1Z2dlc3Rpb24gZm9yIGRldmljZV90eXBl
IGFuZCBtb2RlbCwgYnV0IG5vdCANCmNvbXBhdGFibGUuICAgInBoeXNtYXAiPyAgV2hhdCBraW5k
IG9mIGRldmljZSBpcyB0aGF0PyAgQSANCmNvbW1hbmQgc2V0IG5hbWUsIG1heWJlIHdpdGggYSB3
aWR0aCwgd291bGQgYmUgDQphcHByb3ByaWF0ZS4gICBQaHlzbWFwIGlzIHRoZSBuYW1lIG9mIGFu
b3RoZXIgbGludXggZHJpdmVyLiAgIA0KU29tZXRoaW5nIGxpa2UgZGlyZWN0IG9yIGxpbmVhciBt
aWdodCBiZSBhcHByb3ByaWF0ZSBmb3IgYSByb20sIA0Kd2hlcmUganVzdCBhZGRyZXNzIGFuZCBs
ZW5ndGggYXBwZWFyLiAgRXZlbiByb20gd291bGQgYmUNCmJldHRlciB0aGFuIHBoeXNtYXAuDQoN
Cm1pbHRvbg0K

Re: [RFC] Adding MTD to device tree

[Sergei Shtylyov]

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

Re: [RFC] Adding MTD to device tree

[Segher Boessenkool]

>>> 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. :-)

The name "mtd" is.

>     In fact, device type "flash" sounds too restrictive.

But we can't call it "memory", that one is taken already.

>> '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.

So use "flash" and "rom" as device_type (and as name, heh).

>> 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.

But it *cannot* do that by just naming the driver.  Not every OS
calls this driver "physmap", you know.


Segher

Re: [RFC] Adding MTD to device tree

[David Woodhouse]

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

Re: [RFC] Adding MTD to device tree

[Milton Miller]

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.

Re: [RFC] Adding MTD to device tree

[Sergei Shtylyov]

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 
> 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.

    Then they should have indeed collapsed into it. The thing is physmap 
driver might be actually newer than those ones, so they're kept for historical 
reasons (and for the partition info which actually should move into the 
platform setup code).

> 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.

    Erm, what map device?

> The nodes would get a reg with relative address and size, and the name 
> would be
> the name of the partition.

    MTD partitions are *not* devices, so I guess the first instinct is wrong 
(I had to struggle with it too :-).

>   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).

    'dtc' wouldn't able to chew it anyway although the OF spec. promised 
multi-type properties.
    Sorry, have you bothered looking into my node spec? :-)

>  Yes, we can rely on cmdline partitioning ... but that 
> means a long
> argument in your device tree you don't want edited.

    I finally decided that if we have the ability to store it in the device 
tree, this is better than have user to type and store the bootargs (or worse 
yet, rebuild U-Boot changing the default value of this env. var.).

> 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.

    Hm, MTD is a short for "memory type device", what Linux has to do with it 
at all? However, let the MTD experts correct me...

WBR, Sergei

Re: [RFC] Adding MTD to device tree

[Wolfgang Denk]

In message <44DE4F84.9030802@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@denx.de
We are Microsoft. Unix is irrelevant. Openness is futile.  Prepare to
be assimilated.

Re: [RFC] Adding MTD to device tree

[Wolfgang Denk]

In message <91f1d0619c8ff22cf70404059d514857@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@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

[Sergei Shtylyov]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

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@ru.mvista.com>


[-- Attachment #2: OF-physmap-device.patch --]
[-- Type: text/plain, Size: 5358 bytes --]

Index: powerpc/Documentation/powerpc/booting-without-of.txt
===================================================================
--- powerpc.orig/Documentation/powerpc/booting-without-of.txt
+++ powerpc/Documentation/powerpc/booting-without-of.txt
@@ -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.
 
 
Index: powerpc/arch/powerpc/sysdev/Makefile
===================================================================
--- powerpc.orig/arch/powerpc/sysdev/Makefile
+++ powerpc/arch/powerpc/sysdev/Makefile
@@ -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
Index: powerpc/arch/powerpc/sysdev/flash.c
===================================================================
--- /dev/null
+++ powerpc/arch/powerpc/sysdev/flash.c
@@ -0,0 +1,104 @@
+/*
+ * arch/powerpc/sysdev/flash.c
+ *
+ * Flash memory registration
+ *
+ * (C) 2006 MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/physmap.h>
+#include <linux/mtd/partitions.h>
+#include <linux/platform_device.h>
+#include <asm/prom.h>
+
+static void parse_flash_partitions(struct device_node *node,
+				   struct physmap_flash_data *physmap_data)
+{
+#ifdef CONFIG_MTD_PARTITIONS
+	int i, plen, num_parts;
+	const  u32  *part;
+	const  char *name;
+
+	part = get_property(node, "partitions", &plen);
+	if (part == NULL)
+		return;
+
+	physmap_data->nr_parts = num_parts = plen / (2 * sizeof(u32));
+	physmap_data->parts = kcalloc(num_parts, sizeof(struct mtd_partition),
+				      GFP_KERNEL);
+	if (physmap_data->parts == NULL) {
+		printk(KERN_ERR "Can't allocate the flash partition data!\n");
+		return;
+	}
+
+	name = get_property(node, "partition-names", &plen);
+
+	for (i = 0; i < num_parts; i++) {
+		physmap_data->parts[i].offset = *part++;
+		physmap_data->parts[i].size   = *part & ~1;
+		if (*part++ & 1) /* bit 0 set signifies read only partition */
+			physmap_data->parts[i].mask_flags = MTD_WRITEABLE;
+
+		if (name != NULL && plen > 0) {
+			int len = strlen(name) + 1;
+
+			physmap_data->parts[i].name = (char *)name;
+			plen -= len;
+			name += len;
+		} else
+			physmap_data->parts[i].name = "unnamed";
+	}
+#endif
+}
+
+static int __init powerpc_flash_init(void)
+{
+	struct device_node *node = NULL;
+	int num = 0;
+
+	while ((node = of_find_compatible_node(node, "mtd", "physmap")) != NULL) {
+		struct platform_device *physmap_flash;
+		struct physmap_flash_data physmap_data;
+		struct resource res;
+		const  u32 *width;
+
+		if (of_address_to_resource(node, 0, &res)) {
+			printk(KERN_ERR "Can't get the flash mapping!\n");
+			continue;
+		}
+
+		width = get_property(node, "bank-width", NULL);
+		if (width == NULL) {
+			printk(KERN_ERR "Can't get the flash bank width!\n");
+			continue;
+		}
+
+		physmap_flash = platform_device_register_simple("physmap-flash",
+								num, &res, 1);
+		if (IS_ERR(physmap_flash)) {
+			printk(KERN_ERR "Can't register the \"physmap-flash\" "
+			       "platform device!\n");
+			continue;
+		}
+
+		memset(&physmap_data, 0, sizeof(physmap_data));
+		physmap_data.width = *width;
+
+		parse_flash_partitions(node, &physmap_data);
+
+		if (platform_device_add_data(physmap_flash, &physmap_data,
+					     sizeof(struct physmap_flash_data))) {
+			printk(KERN_ERR "Can't pass data to physmap driver!\n");
+			platform_device_unregister(physmap_flash);
+			continue;
+		}
+		++num;
+	}
+	return 0;
+}
+
+arch_initcall(powerpc_flash_init);

Re: [RFC] Adding MTD to device tree

[Arnd Bergmann]

On Friday 11 August 2006 17:31, Sergei Shtylyov wrote:
> + =A0 h) MTD nodes
> +
> + =A0 Memory Technology Devices are flash, ROM, and similar chips, often =
used
> + =A0 for solid state file systems on embedded devices.
> +
> + =A0 Required properties:
> +
> + =A0 =A0- device_type : has to be "mtd"
> + =A0 =A0- compatible : Should be the name of the MTD driver. Currently, =
this is
> + =A0 =A0 =A0most likely to be "physmap".
> + =A0 =A0- reg : Offset and length of the register set for the device.

I would prefer to call them something different in the device tree.
The name 'mtd' is very specific to Linux, but the device tree
is a more generic concept.

I understand that the booting-without-of.txt file is by definition
Linux specific as well, but we should be prepared for making parts
of it a OS independent binding at the point where we put the same
device nodes into actual OF implementations that able to boot
different operating systems.

I would prefer a naming that has=20

   Required properties:
    - device_type : one of "nand-flash", "nor-flash", or "rom".
    - model : an identifier for the actual controller chip used.
    - compatible : Should be the name of the MTD driver. For
      type "rom", this is most likely "physmap".

	Arnd <><

Re: [RFC] Adding MTD to device tree

[Josh Boyer]

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

Re: [RFC] Adding MTD to device tree

[Segher Boessenkool]

>>    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

Re: [RFC] Adding MTD to device tree

[Sergei Shtylyov]

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

Re: [RFC] Adding MTD to device tree

[Segher Boessenkool]

>>>>    - 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.

>>> 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...

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.

>> I suspect for most nand-flash you can get away with a device_type
>> of "nand-flash"; for some you might have to specify something more
>> detailed.
>
>    Hm, not sure that you need to be so much detailed with the  
> device type.
> The original OF spec. had device type "block" signifying any kind  
> of blocked storage device.

But memory devices aren't really block devices, for example, NOR-flash
is random access for everything but erase operations.


>>>>    - 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.

>> "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