Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
[linux-2.6] / drivers / mtd / Kconfig
1 menuconfig MTD
2         tristate "Memory Technology Device (MTD) support"
3         depends on HAS_IOMEM
4         help
5           Memory Technology Devices are flash, RAM and similar chips, often
6           used for solid state file systems on embedded devices. This option
7           will provide the generic support for MTD drivers to register
8           themselves with the kernel and for potential users of MTD devices
9           to enumerate the devices which are present and obtain a handle on
10           them. It will also allow you to select individual drivers for
11           particular hardware and users of MTD devices. If unsure, say N.
12
13 if MTD
14
15 config MTD_DEBUG
16         bool "Debugging"
17         help
18           This turns on low-level debugging for the entire MTD sub-system.
19           Normally, you should say 'N'.
20
21 config MTD_DEBUG_VERBOSE
22         int "Debugging verbosity (0 = quiet, 3 = noisy)"
23         depends on MTD_DEBUG
24         default "0"
25         help
26           Determines the verbosity level of the MTD debugging messages.
27
28 config MTD_CONCAT
29         tristate "MTD concatenating support"
30         help
31           Support for concatenating several MTD devices into a single
32           (virtual) one. This allows you to have -for example- a JFFS(2)
33           file system spanning multiple physical flash chips. If unsure,
34           say 'Y'.
35
36 config MTD_PARTITIONS
37         bool "MTD partitioning support"
38         help
39           If you have a device which needs to divide its flash chip(s) up
40           into multiple 'partitions', each of which appears to the user as
41           a separate MTD device, you require this option to be enabled. If
42           unsure, say 'Y'.
43
44           Note, however, that you don't need this option for the DiskOnChip
45           devices. Partitioning on NFTL 'devices' is a different - that's the
46           'normal' form of partitioning used on a block device.
47
48 config MTD_REDBOOT_PARTS
49         tristate "RedBoot partition table parsing"
50         depends on MTD_PARTITIONS
51         ---help---
52           RedBoot is a ROM monitor and bootloader which deals with multiple
53           'images' in flash devices by putting a table one of the erase
54           blocks on the device, similar to a partition table, which gives
55           the offsets, lengths and names of all the images stored in the
56           flash.
57
58           If you need code which can detect and parse this table, and register
59           MTD 'partitions' corresponding to each image in the table, enable
60           this option.
61
62           You will still need the parsing functions to be called by the driver
63           for your particular device. It won't happen automatically. The
64           SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
65           example.
66
67 config MTD_REDBOOT_DIRECTORY_BLOCK
68         int "Location of RedBoot partition table"
69         depends on MTD_REDBOOT_PARTS
70         default "-1"
71         ---help---
72           This option is the Linux counterpart to the
73           CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
74           option.
75
76           The option specifies which Flash sectors holds the RedBoot
77           partition table.  A zero or positive value gives an absolute
78           erase block number. A negative value specifies a number of
79           sectors before the end of the device.
80
81           For example "2" means block number 2, "-1" means the last
82           block and "-2" means the penultimate block.
83
84 config MTD_REDBOOT_PARTS_UNALLOCATED
85         bool "Include unallocated flash regions"
86         depends on MTD_REDBOOT_PARTS
87         help
88           If you need to register each unallocated flash region as a MTD
89           'partition', enable this option.
90
91 config MTD_REDBOOT_PARTS_READONLY
92         bool "Force read-only for RedBoot system images"
93         depends on MTD_REDBOOT_PARTS
94         help
95           If you need to force read-only for 'RedBoot', 'RedBoot Config' and
96           'FIS directory' images, enable this option.
97
98 config MTD_CMDLINE_PARTS
99         bool "Command line partition table parsing"
100         depends on MTD_PARTITIONS = "y" && MTD = "y"
101         ---help---
102           Allow generic configuration of the MTD partition tables via the kernel
103           command line. Multiple flash resources are supported for hardware where
104           different kinds of flash memory are available.
105
106           You will still need the parsing functions to be called by the driver
107           for your particular device. It won't happen automatically. The
108           SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
109           example.
110
111           The format for the command line is as follows:
112
113           mtdparts=<mtddef>[;<mtddef]
114           <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
115           <partdef> := <size>[@offset][<name>][ro]
116           <mtd-id>  := unique id used in mapping driver/device
117           <size>    := standard linux memsize OR "-" to denote all
118           remaining space
119           <name>    := (NAME)
120
121           Due to the way Linux handles the command line, no spaces are
122           allowed in the partition definition, including mtd id's and partition
123           names.
124
125           Examples:
126
127           1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
128           mtdparts=sa1100:-
129
130           Same flash, but 2 named partitions, the first one being read-only:
131           mtdparts=sa1100:256k(ARMboot)ro,-(root)
132
133           If unsure, say 'N'.
134
135 config MTD_AFS_PARTS
136         tristate "ARM Firmware Suite partition parsing"
137         depends on ARM && MTD_PARTITIONS
138         ---help---
139           The ARM Firmware Suite allows the user to divide flash devices into
140           multiple 'images'. Each such image has a header containing its name
141           and offset/size etc.
142
143           If you need code which can detect and parse these tables, and
144           register MTD 'partitions' corresponding to each image detected,
145           enable this option.
146
147           You will still need the parsing functions to be called by the driver
148           for your particular device. It won't happen automatically. The
149           'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example.
150
151 config MTD_OF_PARTS
152         tristate "Flash partition map based on OF description"
153         depends on PPC_OF && MTD_PARTITIONS
154         help
155           This provides a partition parsing function which derives
156           the partition map from the children of the flash node,
157           as described in Documentation/powerpc/booting-without-of.txt.
158
159 config MTD_AR7_PARTS
160         tristate "TI AR7 partitioning support"
161         depends on MTD_PARTITIONS
162         ---help---
163           TI AR7 partitioning support
164
165 comment "User Modules And Translation Layers"
166
167 config MTD_CHAR
168         tristate "Direct char device access to MTD devices"
169         help
170           This provides a character device for each MTD device present in
171           the system, allowing the user to read and write directly to the
172           memory chips, and also use ioctl() to obtain information about
173           the device, or to erase parts of it.
174
175 config MTD_BLKDEVS
176         tristate "Common interface to block layer for MTD 'translation layers'"
177         depends on BLOCK
178         default n
179
180 config MTD_BLOCK
181         tristate "Caching block device access to MTD devices"
182         depends on BLOCK
183         select MTD_BLKDEVS
184         ---help---
185           Although most flash chips have an erase size too large to be useful
186           as block devices, it is possible to use MTD devices which are based
187           on RAM chips in this manner. This block device is a user of MTD
188           devices performing that function.
189
190           At the moment, it is also required for the Journalling Flash File
191           System(s) to obtain a handle on the MTD device when it's mounted
192           (although JFFS and JFFS2 don't actually use any of the functionality
193           of the mtdblock device).
194
195           Later, it may be extended to perform read/erase/modify/write cycles
196           on flash chips to emulate a smaller block size. Needless to say,
197           this is very unsafe, but could be useful for file systems which are
198           almost never written to.
199
200           You do not need this option for use with the DiskOnChip devices. For
201           those, enable NFTL support (CONFIG_NFTL) instead.
202
203 config MTD_BLOCK_RO
204         tristate "Readonly block device access to MTD devices"
205         depends on MTD_BLOCK!=y && BLOCK
206         select MTD_BLKDEVS
207         help
208           This allows you to mount read-only file systems (such as cramfs)
209           from an MTD device, without the overhead (and danger) of the caching
210           driver.
211
212           You do not need this option for use with the DiskOnChip devices. For
213           those, enable NFTL support (CONFIG_NFTL) instead.
214
215 config FTL
216         tristate "FTL (Flash Translation Layer) support"
217         depends on BLOCK
218         select MTD_BLKDEVS
219         ---help---
220           This provides support for the original Flash Translation Layer which
221           is part of the PCMCIA specification. It uses a kind of pseudo-
222           file system on a flash device to emulate a block device with
223           512-byte sectors, on top of which you put a 'normal' file system.
224
225           You may find that the algorithms used in this code are patented
226           unless you live in the Free World where software patents aren't
227           legal - in the USA you are only permitted to use this on PCMCIA
228           hardware, although under the terms of the GPL you're obviously
229           permitted to copy, modify and distribute the code as you wish. Just
230           not use it.
231
232 config NFTL
233         tristate "NFTL (NAND Flash Translation Layer) support"
234         depends on BLOCK
235         select MTD_BLKDEVS
236         ---help---
237           This provides support for the NAND Flash Translation Layer which is
238           used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
239           file system on a flash device to emulate a block device with
240           512-byte sectors, on top of which you put a 'normal' file system.
241
242           You may find that the algorithms used in this code are patented
243           unless you live in the Free World where software patents aren't
244           legal - in the USA you are only permitted to use this on DiskOnChip
245           hardware, although under the terms of the GPL you're obviously
246           permitted to copy, modify and distribute the code as you wish. Just
247           not use it.
248
249 config NFTL_RW
250         bool "Write support for NFTL"
251         depends on NFTL
252         help
253           Support for writing to the NAND Flash Translation Layer, as used
254           on the DiskOnChip.
255
256 config INFTL
257         tristate "INFTL (Inverse NAND Flash Translation Layer) support"
258         depends on BLOCK
259         select MTD_BLKDEVS
260         ---help---
261           This provides support for the Inverse NAND Flash Translation
262           Layer which is used on M-Systems' newer DiskOnChip devices. It
263           uses a kind of pseudo-file system on a flash device to emulate
264           a block device with 512-byte sectors, on top of which you put
265           a 'normal' file system.
266
267           You may find that the algorithms used in this code are patented
268           unless you live in the Free World where software patents aren't
269           legal - in the USA you are only permitted to use this on DiskOnChip
270           hardware, although under the terms of the GPL you're obviously
271           permitted to copy, modify and distribute the code as you wish. Just
272           not use it.
273
274 config RFD_FTL
275         tristate "Resident Flash Disk (Flash Translation Layer) support"
276         depends on BLOCK
277         select MTD_BLKDEVS
278         ---help---
279           This provides support for the flash translation layer known
280           as the Resident Flash Disk (RFD), as used by the Embedded BIOS
281           of General Software. There is a blurb at:
282
283                 http://www.gensw.com/pages/prod/bios/rfd.htm
284
285 config SSFDC
286         tristate "NAND SSFDC (SmartMedia) read only translation layer"
287         depends on BLOCK
288         select MTD_BLKDEVS
289         help
290           This enables read only access to SmartMedia formatted NAND
291           flash. You can mount it with FAT file system.
292
293 config MTD_OOPS
294         tristate "Log panic/oops to an MTD buffer"
295         depends on MTD
296         help
297           This enables panic and oops messages to be logged to a circular
298           buffer in a flash partition where it can be read back at some
299           later point.
300
301           To use, add console=ttyMTDx to the kernel command line,
302           where x is the MTD device number to use.
303
304 source "drivers/mtd/chips/Kconfig"
305
306 source "drivers/mtd/maps/Kconfig"
307
308 source "drivers/mtd/devices/Kconfig"
309
310 source "drivers/mtd/nand/Kconfig"
311
312 source "drivers/mtd/onenand/Kconfig"
313
314 source "drivers/mtd/ubi/Kconfig"
315
316 endif # MTD