diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:20:36 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:20:36 -0700 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /drivers/mtd/chips/Kconfig | |
download | op-kernel-dev-1da177e4c3f41524e886b7f1b8a0c1fc7321cac2.zip op-kernel-dev-1da177e4c3f41524e886b7f1b8a0c1fc7321cac2.tar.gz |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'drivers/mtd/chips/Kconfig')
-rw-r--r-- | drivers/mtd/chips/Kconfig | 286 |
1 files changed, 286 insertions, 0 deletions
diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig new file mode 100644 index 0000000..d682dbc --- /dev/null +++ b/drivers/mtd/chips/Kconfig @@ -0,0 +1,286 @@ +# drivers/mtd/chips/Kconfig +# $Id: Kconfig,v 1.13 2004/12/01 15:49:10 nico Exp $ + +menu "RAM/ROM/Flash chip drivers" + depends on MTD!=n + +config MTD_CFI + tristate "Detect flash chips by Common Flash Interface (CFI) probe" + depends on MTD + select MTD_GEN_PROBE + help + The Common Flash Interface specification was developed by Intel, + AMD and other flash manufactures that provides a universal method + for probing the capabilities of flash devices. If you wish to + support any device that is CFI-compliant, you need to enable this + option. Visit <http://www.amd.com/products/nvd/overview/cfi.html> + for more information on CFI. + +config MTD_JEDECPROBE + tristate "Detect non-CFI AMD/JEDEC-compatible flash chips" + depends on MTD + select MTD_GEN_PROBE + help + This option enables JEDEC-style probing of flash chips which are not + compatible with the Common Flash Interface, but will use the common + CFI-targetted flash drivers for any chips which are identified which + are in fact compatible in all but the probe method. This actually + covers most AMD/Fujitsu-compatible chips, and will shortly cover also + non-CFI Intel chips (that code is in MTD CVS and should shortly be sent + for inclusion in Linus' tree) + +config MTD_GEN_PROBE + tristate + +config MTD_CFI_ADV_OPTIONS + bool "Flash chip driver advanced configuration options" + depends on MTD_GEN_PROBE + help + If you need to specify a specific endianness for access to flash + chips, or if you wish to reduce the size of the kernel by including + support for only specific arrangements of flash chips, say 'Y'. This + option does not directly affect the code, but will enable other + configuration options which allow you to do so. + + If unsure, say 'N'. + +choice + prompt "Flash cmd/query data swapping" + depends on MTD_CFI_ADV_OPTIONS + default MTD_CFI_NOSWAP + +config MTD_CFI_NOSWAP + bool "NO" + ---help--- + This option defines the way in which the CPU attempts to arrange + data bits when writing the 'magic' commands to the chips. Saying + 'NO', which is the default when CONFIG_MTD_CFI_ADV_OPTIONS isn't + enabled, means that the CPU will not do any swapping; the chips + are expected to be wired to the CPU in 'host-endian' form. + Specific arrangements are possible with the BIG_ENDIAN_BYTE and + LITTLE_ENDIAN_BYTE, if the bytes are reversed. + + If you have a LART, on which the data (and address) lines were + connected in a fashion which ensured that the nets were as short + as possible, resulting in a bit-shuffling which seems utterly + random to the untrained eye, you need the LART_ENDIAN_BYTE option. + + Yes, there really exists something sicker than PDP-endian :) + +config MTD_CFI_BE_BYTE_SWAP + bool "BIG_ENDIAN_BYTE" + +config MTD_CFI_LE_BYTE_SWAP + bool "LITTLE_ENDIAN_BYTE" + +endchoice + +config MTD_CFI_GEOMETRY + bool "Specific CFI Flash geometry selection" + depends on MTD_CFI_ADV_OPTIONS + help + This option does not affect the code directly, but will enable + some other configuration options which would allow you to reduce + the size of the kernel by including support for only certain + arrangements of CFI chips. If unsure, say 'N' and all options + which are supported by the current code will be enabled. + +config MTD_MAP_BANK_WIDTH_1 + bool "Support 8-bit buswidth" if MTD_CFI_GEOMETRY + default y + help + If you wish to support CFI devices on a physical bus which is + 8 bits wide, say 'Y'. + +config MTD_MAP_BANK_WIDTH_2 + bool "Support 16-bit buswidth" if MTD_CFI_GEOMETRY + default y + help + If you wish to support CFI devices on a physical bus which is + 16 bits wide, say 'Y'. + +config MTD_MAP_BANK_WIDTH_4 + bool "Support 32-bit buswidth" if MTD_CFI_GEOMETRY + default y + help + If you wish to support CFI devices on a physical bus which is + 32 bits wide, say 'Y'. + +config MTD_MAP_BANK_WIDTH_8 + bool "Support 64-bit buswidth" if MTD_CFI_GEOMETRY + default n + help + If you wish to support CFI devices on a physical bus which is + 64 bits wide, say 'Y'. + +config MTD_MAP_BANK_WIDTH_16 + bool "Support 128-bit buswidth" if MTD_CFI_GEOMETRY + default n + help + If you wish to support CFI devices on a physical bus which is + 128 bits wide, say 'Y'. + +config MTD_MAP_BANK_WIDTH_32 + bool "Support 256-bit buswidth" if MTD_CFI_GEOMETRY + default n + help + If you wish to support CFI devices on a physical bus which is + 256 bits wide, say 'Y'. + +config MTD_CFI_I1 + bool "Support 1-chip flash interleave" if MTD_CFI_GEOMETRY + default y + help + If your flash chips are not interleaved - i.e. you only have one + flash chip addressed by each bus cycle, then say 'Y'. + +config MTD_CFI_I2 + bool "Support 2-chip flash interleave" if MTD_CFI_GEOMETRY + default y + help + If your flash chips are interleaved in pairs - i.e. you have two + flash chips addressed by each bus cycle, then say 'Y'. + +config MTD_CFI_I4 + bool "Support 4-chip flash interleave" if MTD_CFI_GEOMETRY + default n + help + If your flash chips are interleaved in fours - i.e. you have four + flash chips addressed by each bus cycle, then say 'Y'. + +config MTD_CFI_I8 + bool "Support 8-chip flash interleave" if MTD_CFI_GEOMETRY + default n + help + If your flash chips are interleaved in eights - i.e. you have eight + flash chips addressed by each bus cycle, then say 'Y'. + +config MTD_CFI_INTELEXT + tristate "Support for Intel/Sharp flash chips" + depends on MTD_GEN_PROBE + select MTD_CFI_UTIL + help + The Common Flash Interface defines a number of different command + sets which a CFI-compliant chip may claim to implement. This code + provides support for one of those command sets, used on Intel + StrataFlash and other parts. + +config MTD_CFI_AMDSTD + tristate "Support for AMD/Fujitsu flash chips" + depends on MTD_GEN_PROBE + select MTD_CFI_UTIL + help + The Common Flash Interface defines a number of different command + sets which a CFI-compliant chip may claim to implement. This code + provides support for one of those command sets, used on chips + including the AMD Am29LV320. + +config MTD_CFI_AMDSTD_RETRY + int "Retry failed commands (erase/program)" + depends on MTD_CFI_AMDSTD + default "0" + help + Some chips, when attached to a shared bus, don't properly filter + bus traffic that is destined to other devices. This broken + behavior causes erase and program sequences to be aborted when + the sequences are mixed with traffic for other devices. + + SST49LF040 (and related) chips are know to be broken. + +config MTD_CFI_AMDSTD_RETRY_MAX + int "Max retries of failed commands (erase/program)" + depends on MTD_CFI_AMDSTD_RETRY + default "0" + help + If you have an SST49LF040 (or related chip) then this value should + be set to at least 1. This can also be adjusted at driver load + time with the retry_cmd_max module parameter. + +config MTD_CFI_STAA + tristate "Support for ST (Advanced Architecture) flash chips" + depends on MTD_GEN_PROBE + select MTD_CFI_UTIL + help + The Common Flash Interface defines a number of different command + sets which a CFI-compliant chip may claim to implement. This code + provides support for one of those command sets. + +config MTD_CFI_UTIL + tristate + +config MTD_RAM + tristate "Support for RAM chips in bus mapping" + depends on MTD + help + This option enables basic support for RAM chips accessed through + a bus mapping driver. + +config MTD_ROM + tristate "Support for ROM chips in bus mapping" + depends on MTD + help + This option enables basic support for ROM chips accessed through + a bus mapping driver. + +config MTD_ABSENT + tristate "Support for absent chips in bus mapping" + depends on MTD + help + This option enables support for a dummy probing driver used to + allocated placeholder MTD devices on systems that have socketed + or removable media. Use of this driver as a fallback chip probe + preserves the expected registration order of MTD device nodes on + the system regardless of media presence. Device nodes created + with this driver will return -ENODEV upon access. + +config MTD_OBSOLETE_CHIPS + depends on MTD && BROKEN + bool "Older (theoretically obsoleted now) drivers for non-CFI chips" + help + This option does not enable any code directly, but will allow you to + select some other chip drivers which are now considered obsolete, + because the generic CONFIG_JEDECPROBE code above should now detect + the chips which are supported by these drivers, and allow the generic + CFI-compatible drivers to drive the chips. Say 'N' here unless you have + already tried the CONFIG_JEDECPROBE method and reported its failure + to the MTD mailing list at <linux-mtd@lists.infradead.org> + +config MTD_AMDSTD + tristate "AMD compatible flash chip support (non-CFI)" + depends on MTD && MTD_OBSOLETE_CHIPS + help + This option enables support for flash chips using AMD-compatible + commands, including some which are not CFI-compatible and hence + cannot be used with the CONFIG_MTD_CFI_AMDSTD option. + + It also works on AMD compatible chips that do conform to CFI. + +config MTD_SHARP + tristate "pre-CFI Sharp chip support" + depends on MTD && MTD_OBSOLETE_CHIPS + help + This option enables support for flash chips using Sharp-compatible + commands, including some which are not CFI-compatible and hence + cannot be used with the CONFIG_MTD_CFI_INTELxxx options. + +config MTD_JEDEC + tristate "JEDEC device support" + depends on MTD && MTD_OBSOLETE_CHIPS + help + Enable older older JEDEC flash interface devices for self + programming flash. It is commonly used in older AMD chips. It is + only called JEDEC because the JEDEC association + <http://www.jedec.org/> distributes the identification codes for the + chips. + +config MTD_XIP + bool "XIP aware MTD support" + depends on !SMP && MTD_CFI_INTELEXT && EXPERIMENTAL + default y if XIP_KERNEL + help + This allows MTD support to work with flash memory which is also + used for XIP purposes. If you're not sure what this is all about + then say N. + +endmenu + |