lisa/android_kernel_xiaomi_sm8350
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
c7c16c8e76
android_kernel_xiaomi_sm8350/drivers/mtd/maps/Kconfig

635 lines
22 KiB
Plaintext
Raw Normal View History

Linux-2.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!
2005-04-16 18:20:36 -04:00
# drivers/mtd/maps/Kconfig
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
# $Id: Kconfig,v 1.61 2005/11/07 11:14:26 gleixner Exp $
Linux-2.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!
2005-04-16 18:20:36 -04:00
menu "Mapping drivers for chip access"
depends on MTD!=n
config MTD_COMPLEX_MAPPINGS
bool "Support non-linear mappings of flash chips"
depends on MTD
help
This causes the chip drivers to allow for complicated
paged mappings of flash chips.
config MTD_PHYSMAP
tristate "CFI Flash device in physical memory map"
depends on MTD_CFI
help
This provides a 'mapping' driver which allows the CFI probe and
command set driver code to communicate with flash chips which
are mapped physically into the CPU's memory. You will need to
configure the physical address and size of the flash chips on
your particular board as well as the bus width, either statically
with config options or at run-time.
config MTD_PHYSMAP_START
hex "Physical start address of flash mapping"
depends on MTD_PHYSMAP
default "0x8000000"
help
This is the physical memory location at which the flash chips
are mapped on your particular target board. Refer to the
memory map which should hopefully be in the documentation for
your board.
Ignore this option if you use run-time physmap configuration
(i.e., run-time calling physmap_configure()).
config MTD_PHYSMAP_LEN
hex "Physical length of flash mapping"
depends on MTD_PHYSMAP
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 12:16:36 -04:00
default "0"
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This is the total length of the mapping of the flash chips on
your particular board. If there is space, or aliases, in the
physical memory map between the chips, this could be larger
than the total amount of flash present. Refer to the memory
map which should hopefully be in the documentation for your
board.
Ignore this option if you use run-time physmap configuration
(i.e., run-time calling physmap_configure()).
config MTD_PHYSMAP_BANKWIDTH
int "Bank width in octets"
depends on MTD_PHYSMAP
default "2"
help
This is the total width of the data bus of the flash devices
in octets. For example, if you have a data bus width of 32
bits, you would set the bus width octect value to 4. This is
used internally by the CFI drivers.
Ignore this option if you use run-time physmap configuration
(i.e., run-time calling physmap_configure()).
config MTD_SUN_UFLASH
tristate "Sun Microsystems userflash support"
[SPARC]: introduce a SPARC Kconfig symbol Introduce a Kconfig symbol SPARC that is defined on both the sparc and sparc64 architectures. This symbol makes some dependencies more readable. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-23 00:03:47 -05:00
depends on SPARC && MTD_CFI
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
This provides a 'mapping' driver which supports the way in
which user-programmable flash chips are connected on various
Sun Microsystems boardsets. This driver will require CFI support
Linux-2.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!
2005-04-16 18:20:36 -04:00
in the kernel, so if you did not enable CFI previously, do that now.
config MTD_PNC2000
tristate "CFI Flash device mapped on Photron PNC-2000"
depends on X86 && MTD_CFI && MTD_PARTITIONS
help
PNC-2000 is the name of Network Camera product from PHOTRON
Ltd. in Japan. It uses CFI-compliant flash.
config MTD_SC520CDP
tristate "CFI Flash device mapped on AMD SC520 CDP"
mtd: SC520CDP should depend on MTD_CONCAT Toralf Förster found a compile error when CONFIG_MTD_SC520CDP=y and CONFIG_MTD_CONCAT=n: drivers/built-in.o: In function `init_sc520cdp': sc520cdp.c:(.init.text+0xb4de): undefined reference to `mtd_concat_create' drivers/built-in.o: In function `cleanup_sc520cdp': sc520cdp.c:(.exit.text+0x14bc): undefined reference to `mtd_concat_destroy' This patch fixes it. Signed-off-by: Daniel Drake <dsd@gentoo.org> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2006-04-29 06:41:44 -04:00
depends on X86 && MTD_CFI && MTD_CONCAT
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
The SC520 CDP board has two banks of CFI-compliant chips and one
Dual-in-line JEDEC chip. This 'mapping' driver supports that
arrangement, implementing three MTD devices.
config MTD_NETSC520
tristate "CFI Flash device mapped on AMD NetSc520"
depends on X86 && MTD_CFI && MTD_PARTITIONS
help
This enables access routines for the flash chips on the AMD NetSc520
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
demonstration board. If you have one of these boards and would like
Linux-2.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!
2005-04-16 18:20:36 -04:00
to use the flash chips on it, say 'Y'.
config MTD_TS5500
tristate "JEDEC Flash device mapped on Technologic Systems TS-5500"
[MTD] maps: Replace dependency on non existing config option CONFIG_ELAN doesn't exist any more; CONFIG_X86_ELAN is too specific so make ts-5500 memory map dependant on CONFIG_X86. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-08 19:12:50 -05:00
depends on X86
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
select MTD_PARTITIONS
select MTD_JEDECPROBE
select MTD_CFI_AMDSTD
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This provides a driver for the on-board flash of the Technologic
[MTD] Add Resident Flash Disk (RFD) support This type of flash translation layer (FTL) is used by the Embedded BIOS by General Software. It is known as the Resident Flash Disk (RFD), see: http://www.gensw.com/pages/prod/bios/rfd.htm Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-16 04:49:33 -04:00
System's TS-5500 board. The 2MB flash is split into 3 partitions
Linux-2.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!
2005-04-16 18:20:36 -04:00
which are accessed as separate MTD devices.
[MTD] Add Resident Flash Disk (RFD) support This type of flash translation layer (FTL) is used by the Embedded BIOS by General Software. It is known as the Resident Flash Disk (RFD), see: http://www.gensw.com/pages/prod/bios/rfd.htm Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-16 04:49:33 -04:00
mtd0 and mtd2 are the two BIOS drives, which use the resident
flash disk (RFD) flash translation layer.
Linux-2.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!
2005-04-16 18:20:36 -04:00
mtd1 allows you to reprogram your BIOS. BE VERY CAREFUL.
Note that jumper 3 ("Write Enable Drive A") must be set
Trivial typo fixes in Kconfig files (MTD). Signed-off-by: Egry Gábor <gaboregry@t-online.hu> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-12 12:35:02 -04:00
otherwise detection won't succeed.
Linux-2.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!
2005-04-16 18:20:36 -04:00
config MTD_SBC_GXX
tristate "CFI Flash device mapped on Arcom SBC-GXx boards"
depends on X86 && MTD_CFI_INTELEXT && MTD_PARTITIONS && MTD_COMPLEX_MAPPINGS
help
This provides a driver for the on-board flash of Arcom Control
Systems' SBC-GXn family of boards, formerly known as SBC-MediaGX.
By default the flash is split into 3 partitions which are accessed
as separate MTD devices. This board utilizes Intel StrataFlash.
More info at
<http://www.arcomcontrols.com/products/icp/pc104/processors/SBC_GX1.htm>.
config MTD_LUBBOCK
tristate "CFI Flash device mapped on Intel Lubbock XScale eval board"
depends on ARCH_LUBBOCK && MTD_CFI_INTELEXT && MTD_PARTITIONS
help
This provides a driver for the on-board flash of the Intel
'Lubbock' XScale evaluation board.
[MTD] Add mapping driver for Intel PXA27x Mainstone board flash. From: Nicolas Pitre <nico@cam.org> Signed-off-by: Todd Poynor <tpoynor@mvista.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-07-01 18:55:24 -04:00
config MTD_MAINSTONE
tristate "CFI Flash device mapped on Intel Mainstone XScale eval board"
depends on MACH_MAINSTONE && MTD_CFI_INTELEXT
select MTD_PARTITIONS
help
This provides a driver for the on-board flash of the Intel
'Mainstone PXA27x evaluation board.
Linux-2.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!
2005-04-16 18:20:36 -04:00
config MTD_OCTAGON
tristate "JEDEC Flash device mapped on Octagon 5066 SBC"
depends on X86 && MTD_JEDEC && MTD_COMPLEX_MAPPINGS
help
This provides a 'mapping' driver which supports the way in which
the flash chips are connected in the Octagon-5066 Single Board
Computer. More information on the board is available at
<http://www.octagonsystems.com/CPUpages/5066.html>.
config MTD_VMAX
tristate "JEDEC Flash device mapped on Tempustech VMAX SBC301"
depends on X86 && MTD_JEDEC && MTD_COMPLEX_MAPPINGS
help
This provides a 'mapping' driver which supports the way in which
the flash chips are connected in the Tempustech VMAX SBC301 Single
Board Computer. More information on the board is available at
<http://www.tempustech.com/>.
config MTD_SCx200_DOCFLASH
tristate "Flash device mapped with DOCCS on NatSemi SCx200"
depends on SCx200 && MTD_CFI && MTD_PARTITIONS
help
Enable support for a flash chip mapped using the DOCCS signal on a
National Semiconductor SCx200 processor.
If you don't know what to do here, say N.
If compiled as a module, it will be called scx200_docflash.
config MTD_AMD76XROM
tristate "BIOS flash chip on AMD76x southbridge"
depends on X86 && MTD_JEDECPROBE
help
Support for treating the BIOS flash chip on AMD76x motherboards
as an MTD device - with this you can reprogram your BIOS.
BE VERY CAREFUL.
config MTD_ICHXROM
tristate "BIOS flash chip on Intel Controller Hub 2/3/4/5"
depends on X86 && MTD_JEDECPROBE
help
Support for treating the BIOS flash chip on ICHX motherboards
as an MTD device - with this you can reprogram your BIOS.
BE VERY CAREFUL.
config MTD_SCB2_FLASH
tristate "BIOS flash chip on Intel SCB2 boards"
depends on X86 && MTD_JEDECPROBE
help
Support for treating the BIOS flash chip on Intel SCB2 boards
as an MTD device - with this you can reprogram your BIOS.
BE VERY CAREFUL.
config MTD_TSUNAMI
tristate "Flash chips on Tsunami TIG bus"
depends on ALPHA_TSUNAMI && MTD_COMPLEX_MAPPINGS
help
Support for the flash chip on Tsunami TIG bus.
config MTD_LASAT
LASAT depends on MTD_CFI The following difference was found between the mainline and linux-mips kernel. LASAT depends on MTD_CFI. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-03-19 23:40:46 -05:00
tristate "LASAT flash device"
depends on LASAT && MTD_CFI
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
Support for the flash chips on the Lasat 100 and 200 boards.
config MTD_NETtel
tristate "CFI flash device on SnapGear/SecureEdge"
depends on X86 && MTD_PARTITIONS && MTD_JEDECPROBE
help
Support for flash chips on NETtel/SecureEdge/SnapGear boards.
[MTD] Replace all the Au1x mapping drivers with a simplified single driver This driver does not have as many options but it's easier to maintain. And, it turns out AMD never shipped boards with different flash densities. Signed-off-by: Pete Popov <ppopov@pacbell.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-27 16:50:25 -05:00
config MTD_ALCHEMY
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
tristate ' AMD Alchemy Pb1xxx/Db1xxx/RDK MTD support'
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on SOC_AU1X00
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
[MTD] Replace all the Au1x mapping drivers with a simplified single driver This driver does not have as many options but it's easier to maintain. And, it turns out AMD never shipped boards with different flash densities. Signed-off-by: Pete Popov <ppopov@pacbell.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-27 16:50:25 -05:00
Flash memory access on AMD Alchemy Pb/Db/RDK Reference Boards
Linux-2.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!
2005-04-16 18:20:36 -04:00
[MTD] maps: Add support for MTX-1 Flash device Add support for "4G Systems MTX-1 Flash device", better known as meshcube. From: Bruno Randolf <bruno.randolf@4g-systems.biz> Signed-off-by: Joern Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-18 06:46:45 -04:00
config MTD_MTX1
tristate "4G Systems MTX-1 Flash device"
depends on MIPS && MIPS_MTX1
help
Flash memory access on 4G Systems MTX-1 Board. If you have one of
these boards and would like to use the flash chips on it, say 'Y'.
Linux-2.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!
2005-04-16 18:20:36 -04:00
config MTD_DILNETPC
tristate "CFI Flash device mapped on DIL/Net PC"
depends on X86 && MTD_CONCAT && MTD_PARTITIONS && MTD_CFI_INTELEXT
help
MTD map driver for SSV DIL/Net PC Boards "DNP" and "ADNP".
For details, see <http://www.ssv-embedded.de/ssv/pc104/p169.htm>
and <http://www.ssv-embedded.de/ssv/pc104/p170.htm>
config MTD_DILNETPC_BOOTSIZE
hex "Size of DIL/Net PC flash boot partition"
depends on MTD_DILNETPC
default "0x80000"
help
The amount of space taken up by the kernel or Etherboot
on the DIL/Net PC flash chips.
config MTD_L440GX
tristate "BIOS flash chip on Intel L440GX boards"
depends on X86 && MTD_JEDECPROBE
help
Support for treating the BIOS flash chip on Intel L440GX motherboards
as an MTD device - with this you can reprogram your BIOS.
BE VERY CAREFUL.
config MTD_SBC8240
tristate "Flash device on SBC8240"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_JEDECPROBE && 8260
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
Flash access on the SBC8240 board from Wind River. See
<http://www.windriver.com/products/sbc8240/>
config MTD_TQM8XXL
tristate "CFI Flash device mapped on TQM8XXL"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && TQM8xxL
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
The TQM8xxL PowerPC board has up to two banks of CFI-compliant
chips, currently uses AMD one. This 'mapping' driver supports
that arrangement, allowing the CFI probe and command set driver
code to communicate with the chips on the TQM8xxL board. More at
<http://www.denx.de/embedded-ppc-en.html>.
config MTD_RPXLITE
tristate "CFI Flash device mapped on RPX Lite or CLLF"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && (RPXCLASSIC || RPXLITE)
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
The RPXLite PowerPC board has CFI-compliant chips mapped in
a strange sparse mapping. This 'mapping' driver supports that
arrangement, allowing the CFI probe and command set driver code
to communicate with the chips on the RPXLite board. More at
<http://www.embeddedplanet.com/>.
config MTD_MBX860
tristate "System flash on MBX860 board"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && MBX
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the Motorola
MBX860 board. If you have one of these boards and would like
to use the flash chips on it, say 'Y'.
config MTD_DBOX2
tristate "CFI Flash device mapped on D-Box2"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on DBOX2 && MTD_CFI_INTELSTD && MTD_CFI_INTELEXT && MTD_CFI_AMDSTD
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the Nokia/Sagem
D-Box 2 board. If you have one of these boards and would like to use
the flash chips on it, say 'Y'.
config MTD_CFI_FLAGADM
tristate "CFI Flash device mapping on FlagaDM"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on 8xx && MTD_CFI
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
Mapping for the Flaga digital module. If you don't have one, ignore
this setting.
config MTD_BEECH
tristate "CFI Flash device mapped on IBM 405LP Beech"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && BEECH
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the IBM
405LP Beech board. If you have one of these boards and would like
to use the flash chips on it, say 'Y'.
config MTD_ARCTIC
tristate "CFI Flash device mapped on IBM 405LP Arctic"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && ARCTIC2
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the IBM 405LP
Arctic board. If you have one of these boards and would like to
use the flash chips on it, say 'Y'.
config MTD_WALNUT
tristate "Flash device mapped on IBM 405GP Walnut"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_JEDECPROBE && WALNUT
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the IBM 405GP
Walnut board. If you have one of these boards and would like to
use the flash chips on it, say 'Y'.
config MTD_EBONY
tristate "Flash devices mapped on IBM 440GP Ebony"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_JEDECPROBE && EBONY
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the IBM 440GP
Ebony board. If you have one of these boards and would like to
use the flash chips on it, say 'Y'.
config MTD_OCOTEA
tristate "Flash devices mapped on IBM 440GX Ocotea"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && OCOTEA
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the IBM 440GX
Ocotea board. If you have one of these boards and would like to
use the flash chips on it, say 'Y'.
config MTD_REDWOOD
tristate "CFI Flash devices mapped on IBM Redwood"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && ( REDWOOD_4 || REDWOOD_5 || REDWOOD_6 )
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the IBM
Redwood board. If you have one of these boards and would like to
use the flash chips on it, say 'Y'.
[MTD] maps: Add support for the "TQM834x" Boards The following patch adds support for the TQ Systems TQM834x Boards. Verified on TQM8349L. This is a resubmit after integrating the suggested changes. Signed-off-by: Marian Balakowicz <m8@semihalf.com> Signed-off-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 03:33:38 -05:00
config MTD_TQM834x
tristate "Flash device mapped on TQ Components TQM834x Boards"
depends on MTD_CFI && TQM834x
help
This enables access routines for the flash chips on the
TQ Components TQM834x boards. If you have one of these boards
and would like to use the flash chips on it, say 'Y'.
Linux-2.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!
2005-04-16 18:20:36 -04:00
config MTD_CSTM_MIPS_IXX
tristate "Flash chip mapping on ITE QED-4N-S01B, Globespan IVR or custom board"
depends on MIPS && MTD_CFI && MTD_JEDECPROBE && MTD_PARTITIONS
help
This provides a mapping driver for the Integrated Technology
Express, Inc (ITE) QED-4N-S01B eval board and the Globespan IVR
Reference Board. It provides the necessary addressing, length,
buswidth, vpp code and addition setup of the flash device for
these boards. In addition, this mapping driver can be used for
other boards via setting of the CONFIG_MTD_CSTM_MIPS_IXX_START/
LEN/BUSWIDTH parameters. This mapping will provide one mtd device
using one partition. The start address can be offset from the
beginning of flash and the len can be less than the total flash
device size to allow a window into the flash. Both CFI and JEDEC
probes are called.
config MTD_CSTM_MIPS_IXX_START
hex "Physical start address of flash mapping"
depends on MTD_CSTM_MIPS_IXX
default "0x8000000"
help
This is the physical memory location that the MTD driver will
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
use for the flash chips on your particular target board.
Refer to the memory map which should hopefully be in the
Linux-2.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!
2005-04-16 18:20:36 -04:00
documentation for your board.
config MTD_CSTM_MIPS_IXX_LEN
hex "Physical length of flash mapping"
depends on MTD_CSTM_MIPS_IXX
default "0x4000000"
help
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
This is the total length that the MTD driver will use for the
Linux-2.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!
2005-04-16 18:20:36 -04:00
flash chips on your particular board. Refer to the memory
map which should hopefully be in the documentation for your
board.
config MTD_CSTM_MIPS_IXX_BUSWIDTH
int "Bus width in octets"
depends on MTD_CSTM_MIPS_IXX
default "2"
help
This is the total bus width of the mapping of the flash chips
on your particular board.
config MTD_OCELOT
tristate "Momenco Ocelot boot flash device"
depends on MIPS && MOMENCO_OCELOT
help
This enables access routines for the boot flash device and for the
NVRAM on the Momenco Ocelot board. If you have one of these boards
and would like access to either of these, say 'Y'.
config MTD_SOLUTIONENGINE
tristate "CFI Flash device mapped on Hitachi SolutionEngine"
depends on SUPERH && MTD_CFI && MTD_REDBOOT_PARTS
help
This enables access to the flash chips on the Hitachi SolutionEngine and
similar boards. Say 'Y' if you are building a kernel for such a board.
config MTD_ARM_INTEGRATOR
tristate "CFI Flash device mapped on ARM Integrator/P720T"
depends on ARM && MTD_CFI
config MTD_CDB89712
tristate "Cirrus CDB89712 evaluation board mappings"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && ARCH_CDB89712
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the flash or ROM chips on the CDB89712 board.
If you have such a board, say 'Y'.
config MTD_SA1100
tristate "CFI Flash device mapped on StrongARM SA11x0"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && ARCH_SA1100 && MTD_PARTITIONS
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the flash chips on most platforms based on
the SA1100 and SA1110, including the Assabet and the Compaq iPAQ.
If you have such a board, say 'Y'.
config MTD_IPAQ
tristate "CFI Flash device mapped on Compaq/HP iPAQ"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on IPAQ_HANDHELD && MTD_CFI
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This provides a driver for the on-board flash of the iPAQ.
config MTD_DC21285
tristate "CFI Flash device mapped on DC21285 Footbridge"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && ARCH_FOOTBRIDGE && MTD_COMPLEX_MAPPINGS
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This provides a driver for the flash accessed using Intel's
21285 bridge used with Intel's StrongARM processors. More info at
<http://www.intel.com/design/bridge/docs/21285_documentation.htm>.
config MTD_IQ80310
tristate "CFI Flash device mapped on the XScale IQ80310 board"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && ARCH_IQ80310
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access routines for the flash chips on the Intel XScale
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
IQ80310 evaluation board. If you have one of these boards and would
Linux-2.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!
2005-04-16 18:20:36 -04:00
like to use the flash chips on it, say 'Y'.
config MTD_IXP4XX
tristate "CFI Flash device mapped on Intel IXP4xx based systems"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && MTD_COMPLEX_MAPPINGS && ARCH_IXP4XX
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
This enables MTD access to flash devices on platforms based
Linux-2.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!
2005-04-16 18:20:36 -04:00
on Intel's IXP4xx family of network processors such as the
IXDP425 and Coyote. If you have an IXP4xx based board and
would like to use the flash chips on it, say 'Y'.
config MTD_IXP2000
tristate "CFI Flash device mapped on Intel IXP2000 based systems"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && MTD_COMPLEX_MAPPINGS && ARCH_IXP2000
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 06:15:40 -05:00
This enables MTD access to flash devices on platforms based
Linux-2.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!
2005-04-16 18:20:36 -04:00
on Intel's IXP2000 family of network processors such as the
IXDP425 and Coyote. If you have an IXP2000 based board and
would like to use the flash chips on it, say 'Y'.
config MTD_FORTUNET
tristate "CFI Flash device mapped on the FortuNet board"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && MTD_PARTITIONS && SA1100_FORTUNET
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the Flash on the FortuNet board. If you
have such a board, say 'Y'.
config MTD_AUTCPU12
tristate "NV-RAM mapping AUTCPU12 board"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on ARCH_AUTCPU12
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the NV-RAM on autronix autcpu12 board.
If you have such a board, say 'Y'.
config MTD_EDB7312
tristate "CFI Flash device mapped on EDB7312"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on ARCH_EDB7312 && MTD_CFI
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the CFI Flash on the Cogent EDB7312 board.
If you have such a board, say 'Y' here.
config MTD_IMPA7
tristate "JEDEC Flash device mapped on impA7"
depends on ARM && MTD_JEDECPROBE
help
This enables access to the NOR Flash on the impA7 board of
implementa GmbH. If you have such a board, say 'Y' here.
config MTD_CEIVA
tristate "JEDEC Flash device mapped on Ceiva/Polaroid PhotoMax Digital Picture Frame"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_JEDECPROBE && ARCH_CEIVA
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the flash chips on the Ceiva/Polaroid
PhotoMax Digital Picture Frame.
If you have such a device, say 'Y'.
config MTD_NOR_TOTO
tristate "NOR Flash device on TOTO board"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on ARCH_OMAP && OMAP_TOTO
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the NOR flash on the Texas Instruments
TOTO board.
config MTD_H720X
tristate "Hynix evaluation board mappings"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on MTD_CFI && ( ARCH_H7201 || ARCH_H7202 )
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the flash chips on the Hynix evaluation boards.
If you have such a board, say 'Y'.
config MTD_MPC1211
tristate "CFI Flash device mapped on Interface MPC-1211"
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 05:46:19 -04:00
depends on SH_MPC1211 && MTD_CFI
Linux-2.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!
2005-04-16 18:20:36 -04:00
help
This enables access to the flash chips on the Interface MPC-1211(CTP/PCI/MPC-SH02).
If you have such a board, say 'Y'.
[MTD] NOR flash map driver for TI OMAP boards. From: David Brownell, Jian Zhang <jzhang@ti.com>, Tony Lindgren <tony@atomide.com> and others. Signed-off-by: Todd Poynor <tpoynor@mvista.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-07-01 21:53:28 -04:00
config MTD_OMAP_NOR
tristate "TI OMAP board mappings"
depends on MTD_CFI && ARCH_OMAP
help
This enables access to the NOR flash chips on TI OMAP-based
boards defining flash platform devices and flash platform data.
These boards include the Innovator, H2, H3, OSK, Perseus2, and
more. If you have such a board, say 'Y'.
Linux-2.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!
2005-04-16 18:20:36 -04:00
# This needs CFI or JEDEC, depending on the cards found.
config MTD_PCI
tristate "PCI MTD driver"
depends on MTD && PCI && MTD_COMPLEX_MAPPINGS
help
Mapping for accessing flash devices on add-in cards like the Intel XScale
IQ80310 card, and the Intel EBSA285 card in blank ROM programming mode
(please see the manual for the link settings).
If you are not sure, say N.
config MTD_PCMCIA
tristate "PCMCIA MTD driver"
depends on MTD && PCMCIA && MTD_COMPLEX_MAPPINGS && BROKEN
help
Map driver for accessing PCMCIA linear flash memory cards. These
cards are usually around 4-16MiB in size. This does not include
Compact Flash cards which are treated as IDE devices.
[PATCH] pcmcia: id_table for pcmciamtd.c Add pcmcia_device_id table to pcmciamtd. The binding of anonymus cards (i.e. those who do neither report MANFID, CARDID, FUNCID nor product strings) is protected by a new config option. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27 19:28:32 -04:00
config MTD_PCMCIA_ANONYMOUS
bool "Use PCMCIA MTD drivers for anonymous PCMCIA cards"
depends on MTD_PCMCIA
help
If this option is enabled, PCMCIA cards which do not report
anything about themselves are assumed to be MTD cards.
If unsure, say N.
Linux-2.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!
2005-04-16 18:20:36 -04:00
config MTD_UCLINUX
tristate "Generic uClinux RAM/ROM filesystem support"
depends on MTD_PARTITIONS && !MMU
help
Map driver to support image based filesystems for uClinux.
config MTD_WRSBC8260
tristate "Map driver for WindRiver PowerQUICC II MPC82xx board"
depends on (SBC82xx || SBC8560)
select MTD_PARTITIONS
select MTD_MAP_BANK_WIDTH_4
select MTD_MAP_BANK_WIDTH_1
select MTD_CFI_I1
select MTD_CFI_I4
help
Map driver for WindRiver PowerQUICC II MPC82xx board. Drives
all three flash regions on CS0, CS1 and CS6 if they are configured
correctly by the boot loader.
config MTD_DMV182
tristate "Map driver for Dy-4 SVME/DMV-182 board."
depends on DMV182
select MTD_PARTITIONS
select MTD_MAP_BANK_WIDTH_32
select MTD_CFI_I8
select MTD_CFI_AMDSTD
help
Map driver for Dy-4 SVME/DMV-182 board.
config MTD_BAST
[MTD] Update BAST driver configuration update the BAST driver config (which already supports the vr1000) to be selected only if the vr1000 has been configured Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-18 06:03:48 -05:00
tristate "Map driver for Simtec BAST (EB2410ITX) or Thorcom VR1000"
depends on ARCH_BAST || MACH_VR1000
Linux-2.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!
2005-04-16 18:20:36 -04:00
select MTD_PARTITIONS
select MTD_MAP_BANK_WIDTH_16
select MTD_JEDECPROBE
help
[MTD] Update BAST driver configuration update the BAST driver config (which already supports the vr1000) to be selected only if the vr1000 has been configured Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-18 06:03:48 -05:00
Map driver for NOR flash on the Simtec BAST (EB2410ITX), or the
Thorcom VR1000
Linux-2.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!
2005-04-16 18:20:36 -04:00
Note, this driver *cannot* over-ride the WP link on the
board, or currently detect the state of the link.
config MTD_BAST_MAXSIZE
int "Maximum size for BAST flash area (MiB)"
depends on MTD_BAST
default "4"
config MTD_SHARP_SL
bool "ROM maped on Sharp SL Series"
depends on MTD && ARCH_PXA
help
This enables access to the flash chip on the Sharp SL Series of PDAs.
[MTD] Platform RAM Driver Driver for generic RAM blocks which are exported by an platform_device from the device driver system. Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-23 19:37:04 -05:00
config MTD_PLATRAM
[MTD] Fix typo in Kconfig Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-03-17 21:07:24 -05:00
tristate "Map driver for platform device RAM (mtd-ram)"
[MTD] Platform RAM Driver Driver for generic RAM blocks which are exported by an platform_device from the device driver system. Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-23 19:37:04 -05:00
depends on MTD
select MTD_RAM
help
Map driver for RAM areas described via the platform device
system.
This selection automatically selects the map_ram driver.
Linux-2.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!
2005-04-16 18:20:36 -04:00
endmenu
Reference in New Issue Copy Permalink