Add the rt linux 4.1.3-rt3 as base
[kvmfornfv.git] / kernel / drivers / mtd / ubi / Kconfig
diff --git a/kernel/drivers/mtd/ubi/Kconfig b/kernel/drivers/mtd/ubi/Kconfig
new file mode 100644 (file)
index 0000000..f0855ce
--- /dev/null
@@ -0,0 +1,106 @@
+menuconfig MTD_UBI
+       tristate "Enable UBI - Unsorted block images"
+       select CRC32
+       help
+         UBI is a software layer above MTD layer which admits of LVM-like
+         logical volumes on top of MTD devices, hides some complexities of
+         flash chips like wear and bad blocks and provides some other useful
+         capabilities. Please, consult the MTD web site for more details
+         (www.linux-mtd.infradead.org).
+
+if MTD_UBI
+
+config MTD_UBI_WL_THRESHOLD
+       int "UBI wear-leveling threshold"
+       default 4096
+       range 2 65536
+       help
+         This parameter defines the maximum difference between the highest
+         erase counter value and the lowest erase counter value of eraseblocks
+         of UBI devices. When this threshold is exceeded, UBI starts performing
+         wear leveling by means of moving data from eraseblock with low erase
+         counter to eraseblocks with high erase counter.
+
+         The default value should be OK for SLC NAND flashes, NOR flashes and
+         other flashes which have eraseblock life-cycle 100000 or more.
+         However, in case of MLC NAND flashes which typically have eraseblock
+         life-cycle less than 10000, the threshold should be lessened (e.g.,
+         to 128 or 256, although it does not have to be power of 2).
+
+config MTD_UBI_BEB_LIMIT
+       int "Maximum expected bad eraseblock count per 1024 eraseblocks"
+       default 20
+       range 0 768
+       help
+         This option specifies the maximum bad physical eraseblocks UBI
+         expects on the MTD device (per 1024 eraseblocks). If the underlying
+         flash does not admit of bad eraseblocks (e.g. NOR flash), this value
+         is ignored.
+
+         NAND datasheets often specify the minimum and maximum NVM (Number of
+         Valid Blocks) for the flashes' endurance lifetime. The maximum
+         expected bad eraseblocks per 1024 eraseblocks then can be calculated
+         as "1024 * (1 - MinNVB / MaxNVB)", which gives 20 for most NANDs
+         (MaxNVB is basically the total count of eraseblocks on the chip).
+
+         To put it differently, if this value is 20, UBI will try to reserve
+         about 1.9% of physical eraseblocks for bad blocks handling. And that
+         will be 1.9% of eraseblocks on the entire NAND chip, not just the MTD
+         partition UBI attaches. This means that if you have, say, a NAND
+         flash chip admits maximum 40 bad eraseblocks, and it is split on two
+         MTD partitions of the same size, UBI will reserve 40 eraseblocks when
+         attaching a partition.
+
+         This option can be overridden by the "mtd=" UBI module parameter or
+         by the "attach" ioctl.
+
+         Leave the default value if unsure.
+
+config MTD_UBI_FASTMAP
+       bool "UBI Fastmap (Experimental feature)"
+       default n
+       help
+          Important: this feature is experimental so far and the on-flash
+          format for fastmap may change in the next kernel versions
+
+          Fastmap is a mechanism which allows attaching an UBI device
+          in nearly constant time. Instead of scanning the whole MTD device it
+          only has to locate a checkpoint (called fastmap) on the device.
+          The on-flash fastmap contains all information needed to attach
+          the device. Using fastmap makes only sense on large devices where
+          attaching by scanning takes long. UBI will not automatically install
+          a fastmap on old images, but you can set the UBI module parameter
+          fm_autoconvert to 1 if you want so. Please note that fastmap-enabled
+          images are still usable with UBI implementations without
+          fastmap support. On typical flash devices the whole fastmap fits
+          into one PEB. UBI will reserve PEBs to hold two fastmaps.
+
+          If in doubt, say "N".
+
+config MTD_UBI_GLUEBI
+       tristate "MTD devices emulation driver (gluebi)"
+       help
+          This option enables gluebi - an additional driver which emulates MTD
+          devices on top of UBI volumes: for each UBI volumes an MTD device is
+          created, and all I/O to this MTD device is redirected to the UBI
+          volume. This is handy to make MTD-oriented software (like JFFS2)
+          work on top of UBI. Do not enable this unless you use legacy
+          software.
+
+config MTD_UBI_BLOCK
+       bool "Read-only block devices on top of UBI volumes"
+       default n
+       depends on BLOCK
+       help
+          This option enables read-only UBI block devices support. UBI block
+          devices will be layered on top of UBI volumes, which means that the
+          UBI driver will transparently handle things like bad eraseblocks and
+          bit-flips. You can put any block-oriented file system on top of UBI
+          volumes in read-only mode (e.g., ext4), but it is probably most
+          practical for read-only file systems, like squashfs.
+
+          When selected, this feature will be built in the UBI driver.
+
+          If in doubt, say "N".
+
+endif # MTD_UBI