UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/mtd/maps/Kconfig

389 lines
13 KiB
Plaintext
Raw Normal View History

treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 20:07:45 +08:00
# SPDX-License-Identifier: GPL-2.0-only
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-17 06:20:36 +08:00
menu "Mapping drivers for chip access"
depends on MTD!=n
MTD: Relax dependencies CONFIG_GENERIC_IO is just enough for the basic MTD stuff. Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-02-07 08:22:50 +08:00
depends on HAS_IOMEM
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-17 06:20:36 +08:00
config MTD_COMPLEX_MAPPINGS
bool "Support non-linear mappings of flash chips"
help
This causes the chip drivers to allow for complicated
paged mappings of flash chips.
config MTD_PHYSMAP
[MTD] LPDDR extended physmap driver to support LPDDR flash Physmap is a generic map driver for different platforms and flash types. We added support of LPDDR to physmap. All changes here are related to introduction of new pfow_base parameter. This parameter is valid in case of LPDDR chips only. Signed-off-by: Alexey Korolev <akorolev@infradead.org> Acked-by: Jared Hulbert <jaredeh@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-17 02:22:39 +08:00
tristate "Flash device in physical memory map"
mtd: maps: Allow MTD_PHYSMAP with MTD_RAM When the physmap_of_core.c code was merged into physmap-core.c the ability to use MTD_PHYSMAP_OF with only MTD_RAM selected was lost. Restore this by adding MTD_RAM to the dependencies of MTD_PHYSMAP. Fixes: commit 642b1e8dbed7 ("mtd: maps: Merge physmap_of.c into physmap-core.c") Cc: <stable@vger.kernel.org> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Signed-off-by: Richard Weinberger <richard@nod.at>
2019-04-03 10:02:40 +08:00
depends on MTD_CFI || MTD_JEDECPROBE || MTD_ROM || MTD_RAM || MTD_LPDDR
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-17 06:20:36 +08:00
help
[PATCH] [MTD] Maps: Add dependency on alternate probe methods to physmap map/physmap.c tries to probe "cfi_probe", "jedec_probe" and "map_rom", but map/Kconfig says it depends on MTD_CFI only. This patch adds MTD_JEDECPROBE and MTD_ROM to the dependency condition. Signed-off-by: Takashi YOSHII <takasi-y@ops.dti.ne.jp> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2006-08-15 20:26:32 +08:00
This provides a 'mapping' driver which allows the NOR Flash and
ROM driver code to communicate with 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
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-17 06:20:36 +08:00
with config options or at run-time.
[MTD] [MAPS] Document MTD_PHYSMAP module name in kconfig Help out users by telling them the module name in the Kconfig help when using the MTD_PHYSMAP option. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-04-19 04:44:10 +08:00
To compile this driver as a module, choose M here: the
module will be called physmap.
[MTD] physmap: make physmap compat explicit The current method for always showing physmap compat address, size, and width is a bit confusing. If length is set to 0, then the address and width are still shown but silently unused. The physmap code itself already has logic which sets compat based on length, so just pull that out and into the Kconfig to make everything clear. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <Bryan.Wu@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-02 06:23:40 +08:00
config MTD_PHYSMAP_COMPAT
bool "Physmap compat support"
depends on MTD_PHYSMAP
default n
help
Setup a simple mapping via the Kconfig options. Normally the
physmap configuration options are done via your board's
resource file.
If unsure, say N here.
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-17 06:20:36 +08:00
config MTD_PHYSMAP_START
hex "Physical start address of flash mapping"
[MTD] physmap: make physmap compat explicit The current method for always showing physmap compat address, size, and width is a bit confusing. If length is set to 0, then the address and width are still shown but silently unused. The physmap code itself already has logic which sets compat based on length, so just pull that out and into the Kconfig to make everything clear. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <Bryan.Wu@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-02 06:23:40 +08:00
depends on MTD_PHYSMAP_COMPAT
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-17 06:20:36 +08:00
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.
config MTD_PHYSMAP_LEN
hex "Physical length of flash mapping"
[MTD] physmap: make physmap compat explicit The current method for always showing physmap compat address, size, and width is a bit confusing. If length is set to 0, then the address and width are still shown but silently unused. The physmap code itself already has logic which sets compat based on length, so just pull that out and into the Kconfig to make everything clear. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <Bryan.Wu@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-02 06:23:40 +08:00
depends on MTD_PHYSMAP_COMPAT
[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-08 00:16:36 +08: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-17 06:20:36 +08: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.
config MTD_PHYSMAP_BANKWIDTH
int "Bank width in octets"
[MTD] physmap: make physmap compat explicit The current method for always showing physmap compat address, size, and width is a bit confusing. If length is set to 0, then the address and width are still shown but silently unused. The physmap code itself already has logic which sets compat based on length, so just pull that out and into the Kconfig to make everything clear. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <Bryan.Wu@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-02 06:23:40 +08:00
depends on MTD_PHYSMAP_COMPAT
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-17 06:20:36 +08:00
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
typo fixes Most of these fixes were already submitted for old kernel versions, and were approved, but for some reason they never made it into the releases. Because this is a consolidation of a couple old missed patches, it touches both Kconfigs and documentation texts. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-20 07:34:40 +08:00
bits, you would set the bus width octet value to 4. This is
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-17 06:20:36 +08:00
used internally by the CFI drivers.
[MTD] of_device-based physmap driver inlined below is the patch that adds physmap driver for of_device. It's an MTD part of the two-part support for flash/ROM devices based on Open Firmware descriptions. The arch part (currently only PowerPC which is no surprise) was introduced to powerpc folks earlier and recently the older version of the powerpc part has been included into the powerpc.git tree (see http://www.kernel.org/git/?p=linux/kernel/git/paulus/powerpc.git;a=commitdiff;h=28f9ec349ae47c91768b7bc5607db4442c818e11). drivers/mtd/maps/Kconfig | 9 + drivers/mtd/maps/Makefile | 1 drivers/mtd/maps/physmap_of.c | 255 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 265 insertions(+) Signed-off-by: Vitaly Wool <vwool@ru.mvista.com> Signed-off-by: Sergey Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-12-06 18:17:49 +08:00
config MTD_PHYSMAP_OF
mtd: maps: Merge physmap_of.c into physmap-core.c There's no real reason to have two separate driver for the DT and pdata case. Just do what we do everywhere else and handle DT and pdata parsing in the same driver. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-19 15:49:04 +08:00
bool "Memory device in physical memory map based on OF description"
depends on OF && MTD_PHYSMAP
[MTD] of_device-based physmap driver inlined below is the patch that adds physmap driver for of_device. It's an MTD part of the two-part support for flash/ROM devices based on Open Firmware descriptions. The arch part (currently only PowerPC which is no surprise) was introduced to powerpc folks earlier and recently the older version of the powerpc part has been included into the powerpc.git tree (see http://www.kernel.org/git/?p=linux/kernel/git/paulus/powerpc.git;a=commitdiff;h=28f9ec349ae47c91768b7bc5607db4442c818e11). drivers/mtd/maps/Kconfig | 9 + drivers/mtd/maps/Makefile | 1 drivers/mtd/maps/physmap_of.c | 255 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 265 insertions(+) Signed-off-by: Vitaly Wool <vwool@ru.mvista.com> Signed-off-by: Sergey Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-12-06 18:17:49 +08:00
help
mtd: allow CONFIG_MTD_PHYSMAP_OF also for CONFIG_MTD_RAM Up to now mtd-ram devices described in device trees were only accessible if mtd-flash or mtd-rom were also configured at linux configuration time, because MTD_PHYSMAP_OF was only available if (MTD_CFI || MTD_JEDECPROBE || MTD_ROM). Allow MTD_PHYSMAP_OF selection also when only MTD_RAM is set. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-03-06 07:00:00 +08:00
This provides a 'mapping' driver which allows the NOR Flash, ROM
and RAM driver code to communicate with chips which are mapped
[MTD] of_device-based physmap driver inlined below is the patch that adds physmap driver for of_device. It's an MTD part of the two-part support for flash/ROM devices based on Open Firmware descriptions. The arch part (currently only PowerPC which is no surprise) was introduced to powerpc folks earlier and recently the older version of the powerpc part has been included into the powerpc.git tree (see http://www.kernel.org/git/?p=linux/kernel/git/paulus/powerpc.git;a=commitdiff;h=28f9ec349ae47c91768b7bc5607db4442c818e11). drivers/mtd/maps/Kconfig | 9 + drivers/mtd/maps/Makefile | 1 drivers/mtd/maps/physmap_of.c | 255 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 265 insertions(+) Signed-off-by: Vitaly Wool <vwool@ru.mvista.com> Signed-off-by: Sergey Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-12-06 18:17:49 +08:00
physically into the CPU's memory. The mapping description here is
taken from OF device tree.
mtd: physmap: Add Baikal-T1 physically mapped ROM support Baikal-T1 Boot Controller provides an access to a RO storages, which are physically mapped into the SoC MMIO space. In particularly there are Internal ROM embedded into the SoC with a pre-installed firmware, externally attached SPI flash (also accessed in the read-only mode) and a memory region, which mirrors one of them in accordance with the currently enabled system boot mode (also called Boot ROM). This commit adds the Internal ROM support to the physmap driver of the MTD kernel subsystem. The driver will create the Internal ROM MTD as long as it is defined in the system dts file. The physically mapped SPI flash region will be used to implement the SPI-mem interface. The mirroring memory region won't be accessible directly since it's redundant due to both bootable regions being exposed anyway. Note we had to create a dedicated code for the ROMs since read from the corresponding memory regions must be done via the dword-aligned addresses. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru> Cc: Lee Jones <lee.jones@linaro.org> Cc: linux-mips@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200920111445.21816-1-Sergey.Semin@baikalelectronics.ru
2020-09-20 19:14:44 +08:00
config MTD_PHYSMAP_BT1_ROM
bool "Baikal-T1 Boot ROMs OF-based physical memory map handling"
depends on MTD_PHYSMAP_OF
depends on MIPS_BAIKAL_T1 || COMPILE_TEST
select MTD_COMPLEX_MAPPINGS
select MULTIPLEXER
select MUX_MMIO
help
This provides some extra DT physmap parsing for the Baikal-T1
platforms, some detection and setting up ROMs-specific accessors.
mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile, gemini} Now that the physmap_of driver is gone, the gemini and versative extensions are part of the physmap driver. Rename the source files and the config option to reflect this. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-19 15:49:05 +08:00
config MTD_PHYSMAP_VERSATILE
mtd: physmap_of: add a hook for Gemini flash probing In order to support device tree probing of Gemini NOR flash chips, a certain register in the syscon needs to be poked to enable parallel flash mode. Such things used to happen in "necessarily different" board file code, and this indeed was also done for the Gemini, so the MTD driver could treat it as any memory-mapped NOR flash, but this is not the way in the future: board files need to go, and hardware concerns distributed down to the applicable drivers. This adds a hook in the same way that the Versatile did: if the Kconfig symbol is not selected the net total of supporting Gemini should be zero bytes of added code. To live up to this promise, also the return value error print from the Versatile extra probe call get to be removed in this patch, all printing need to happen in the add-ons. Cc: Janos Laube <janos.dev@gmail.com> Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com> Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2017-01-29 05:50:48 +08:00
bool "ARM Versatile OF-based physical memory map handling"
mtd: physmap_of: add a hook for Versatile write protection In order to support device tree probing of Versatile NOR flash chips, there must be a way to add the VPP (write protection) enable/disable callback. The register in question is in the system controllers of these machines. Apart from this quirk, the ARM flash chips are standard CFI flash chips from various vendors. Additionally, the Integrator/AP require you to set up the external bus interface (EBI) to allow writes to the chip select where the flash memory is connected. Solve this by looking for the arm,versatile-flash compatible string in the flash device tree node. In the driver, add a special hook to check for the various Versatile syscons and register a callback for .set_vpp() if this compatible is present. Provide a special Kconfig entry for the addon hook so it will not be compiled in if the Versatile boards are not supported. Stubs in the header file make sure the impact will be zero on other platforms. (Compilers optimze this out.) With this patch, a large slew of ARM board file code can be removed. Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-01-26 18:58:07 +08:00
depends on MTD_PHYSMAP_OF
depends on MFD_SYSCON
ARM: realview: imply device tree boot This reduces the Kconfig for the RealView by assuming we are always booting from the device tree, and removing all the uses of CONFIG_REALVIEW_DT and replacing with CONFIG_ARCH_REALVIEW. Further: - Drop REALVIEW_HIGH_PHYS_OFFSET: we don't use this with device tree. - Drop the REALVIEW_EB_ARM11MP_REVB option: we now handle this by simply using another device tree. - Drop the PB1176 secure flash option: this is defined in the PB1176 device tree but marked as "disabled", so users who want to use it can simply enable it in the device tree and go hacking around. Cc: Brian Norris <computersforpeace@gmail.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-08-10 20:30:35 +08:00
default y if (ARCH_INTEGRATOR || ARCH_VERSATILE || ARCH_REALVIEW)
mtd: physmap_of: add a hook for Versatile write protection In order to support device tree probing of Versatile NOR flash chips, there must be a way to add the VPP (write protection) enable/disable callback. The register in question is in the system controllers of these machines. Apart from this quirk, the ARM flash chips are standard CFI flash chips from various vendors. Additionally, the Integrator/AP require you to set up the external bus interface (EBI) to allow writes to the chip select where the flash memory is connected. Solve this by looking for the arm,versatile-flash compatible string in the flash device tree node. In the driver, add a special hook to check for the various Versatile syscons and register a callback for .set_vpp() if this compatible is present. Provide a special Kconfig entry for the addon hook so it will not be compiled in if the Versatile boards are not supported. Stubs in the header file make sure the impact will be zero on other platforms. (Compilers optimze this out.) With this patch, a large slew of ARM board file code can be removed. Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-01-26 18:58:07 +08:00
help
This provides some extra DT physmap parsing for the ARM Versatile
platforms, basically to add a VPP (write protection) callback so
the flash can be taken out of write protection.
mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile, gemini} Now that the physmap_of driver is gone, the gemini and versative extensions are part of the physmap driver. Rename the source files and the config option to reflect this. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-19 15:49:05 +08:00
config MTD_PHYSMAP_GEMINI
mtd: physmap_of: add a hook for Gemini flash probing In order to support device tree probing of Gemini NOR flash chips, a certain register in the syscon needs to be poked to enable parallel flash mode. Such things used to happen in "necessarily different" board file code, and this indeed was also done for the Gemini, so the MTD driver could treat it as any memory-mapped NOR flash, but this is not the way in the future: board files need to go, and hardware concerns distributed down to the applicable drivers. This adds a hook in the same way that the Versatile did: if the Kconfig symbol is not selected the net total of supporting Gemini should be zero bytes of added code. To live up to this promise, also the return value error print from the Versatile extra probe call get to be removed in this patch, all printing need to happen in the add-ons. Cc: Janos Laube <janos.dev@gmail.com> Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com> Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2017-01-29 05:50:48 +08:00
bool "Cortina Gemini OF-based physical memory map handling"
depends on MTD_PHYSMAP_OF
depends on MFD_SYSCON
mtd: physmap_of_gemini: Handle pin control This enables the complex mapping for the Gemini and kicks in custom read/write functions that will wrap the existing simple functions in calls to enable/disable the parallel flash pins using pin controls. This is necessary on some hardware such as the D-Link DIR-685 where all flash pins are patched in/out at the same time, but some of the flash pins are in practice unused by the flash and have anyway been reused as GPIO. This concerns specifically CE1 on the Gemini. There is only one flash chip, so only CE0 is used, and the line for CE1 has been reused as chip select for the emulated SPI port connected to the display. If we try to use the same lines for flash and GPIO at the same time, one of them will loose: the GPIO line will disappear because it gets disconnected from the pin when the flash group is muxed out. Fix this by introducing two pin control states named simply "enabled" and "disabled" and only enable the flash lines when absolutely necessary (during read/write/copy). This way, they are available for GPIO at all other times and the display works. Collect all the state variables in a struct named struct gemini_flash and allocate this struct at probe time. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-11-28 04:53:58 +08:00
select MTD_COMPLEX_MAPPINGS
mtd: physmap_of: add a hook for Gemini flash probing In order to support device tree probing of Gemini NOR flash chips, a certain register in the syscon needs to be poked to enable parallel flash mode. Such things used to happen in "necessarily different" board file code, and this indeed was also done for the Gemini, so the MTD driver could treat it as any memory-mapped NOR flash, but this is not the way in the future: board files need to go, and hardware concerns distributed down to the applicable drivers. This adds a hook in the same way that the Versatile did: if the Kconfig symbol is not selected the net total of supporting Gemini should be zero bytes of added code. To live up to this promise, also the return value error print from the Versatile extra probe call get to be removed in this patch, all printing need to happen in the add-ons. Cc: Janos Laube <janos.dev@gmail.com> Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com> Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2017-01-29 05:50:48 +08:00
default ARCH_GEMINI
help
This provides some extra DT physmap parsing for the Gemini
platforms, some detection and setting up parallel mode on the
external interface.
mtd: physmap_of: add a hook for Intel IXP4xx flash probing In order to support device tree probing of IXP4xx NOR flash chips, a certain big-endian or mixed-endian memory access pattern need to be used. I have opted to use the pattern set by previous plug-ins to physmap for Gemini and Versatile, just override some functions and reuse most of the physmap core code as it is to minimize maintenance. Parts of drivers/mtd/ixp4xx.c are copied into this file. After we have IXP4xx converted fully to device tree, the drivers/mtd/ixp4xx.c file will be deleted and this will be the only access pattern to the IXP4xx flash. I did not keep the quirk in the flash write function after probe, where the old code for a while checks for access to odd addresses, fails and assigns a "faster" write function once it has convinced probe to only use 2-byte accesses. As we mandate that this device should be using bank-width = <2> this should not be a problem unless misconfigured. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-10-21 07:00:42 +08:00
config MTD_PHYSMAP_IXP4XX
bool "Intel IXP4xx OF-based physical memory map handling"
depends on MTD_PHYSMAP_OF
depends on ARM
select MTD_COMPLEX_MAPPINGS
select MTD_CFI_BE_BYTE_SWAP if CPU_BIG_ENDIAN
default ARCH_IXP4XX
help
This provides some extra DT physmap parsing for the Intel IXP4xx
platforms, some elaborate endianness handling in particular.
mtd: maps: Merge gpio-addr-flash.c into physmap-core.c Controlling some MSB address lines using GPIOs is just a small deviation from the generic physmap logic, and merging those two drivers allows us to share most of the probe logic, which is a good thing. Also, the gpio-addr-flash driver is unused since the removal of the blackfin arch in v4.17, so we can safely remove the old driver without risking breaking existing boards. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Tested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-19 15:49:07 +08:00
config MTD_PHYSMAP_GPIO_ADDR
bool "GPIO-assisted Flash Chip Support"
depends on MTD_PHYSMAP
depends on GPIOLIB || COMPILE_TEST
depends on MTD_COMPLEX_MAPPINGS
help
Extend the physmap driver to allow flashes to be partially
physically addressed and assisted by GPIOs.
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-17 06:20:36 +08:00
config MTD_SUN_UFLASH
tristate "Sun Microsystems userflash support"
sun userflash is PCI-dependent Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-27 00:33:09 +08:00
depends on SPARC && MTD_CFI && PCI
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-17 06:20:36 +08:00
help
[MTD] maps: Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 19:15:40 +08: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-17 06:20:36 +08:00
in the kernel, so if you did not enable CFI previously, do that now.
config MTD_SC520CDP
tristate "CFI Flash device mapped on AMD SC520 CDP"
mtd: Fix Elan SC520 dependencies Anyone working with an AMD Elan SC520 development or evaluation board would be building a dedicated kernel for it, so we can make the sc520cdp and netsc520 maps depend on MELAN. SC520_CPUFREQ already depends on MELAN so it makes things more consistent. It also makes kernel configuration for every other x86 user easier. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-03-15 01:14:20 +08:00
depends on (MELAN || COMPILE_TEST) && 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-17 06:20:36 +08: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"
mtd: Fix Elan SC520 dependencies Anyone working with an AMD Elan SC520 development or evaluation board would be building a dedicated kernel for it, so we can make the sc520cdp and netsc520 maps depend on MELAN. SC520_CPUFREQ already depends on MELAN so it makes things more consistent. It also makes kernel configuration for every other x86 user easier. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-03-15 01:14:20 +08:00
depends on (MELAN || COMPILE_TEST) && 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-17 06:20:36 +08:00
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 19:15:40 +08: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-17 06:20:36 +08:00
to use the flash chips on it, say 'Y'.
config MTD_TS5500
tristate "JEDEC Flash device mapped on Technologic Systems TS-5500"
mtd: ts5500: Add dependency There is no point in displaying the TS5500-specific driver entries if TS5500 board support itself isn't enabled. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-02-23 17:32:01 +08:00
depends on TS5500 || COMPILE_TEST
[MTD] maps/Kconfig: Simplify and update dependencies Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29 17:46:19 +08:00
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-17 06:20:36 +08: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 16:49:33 +08: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-17 06:20:36 +08: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 16:49:33 +08: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-17 06:20:36 +08: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-13 00:35:02 +08: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-17 06:20:36 +08:00
config MTD_SBC_GXX
tristate "CFI Flash device mapped on Arcom SBC-GXx boards"
mtd: kill CONFIG_MTD_PARTITIONS Now that none of the drivers use CONFIG_MTD_PARTITIONS we can remove it from Kconfig and the last remaining uses. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-05-23 17:23:43 +08:00
depends on X86 && MTD_CFI_INTELEXT && 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-17 06:20:36 +08:00
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>.
[MTD] MAPS: Merge Lubbock and Mainstone drivers into common PXA2xx driver Replace Lubbock and Mainstone board drivers with common PXA2xx driver, convert to platform driver (corresponding platform device changes merged to kernel.org for 2.6.15), add power management callbacks. Signed-off-by: Todd Poynor <tpoynor@mvista.com> Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-11-08 05:47:48 +08:00
config MTD_PXA2XX
tristate "CFI Flash device mapped on Intel XScale PXA2xx based boards"
depends on (PXA25x || PXA27x) && MTD_CFI_INTELEXT
[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-02 06:55:24 +08:00
help
[MTD] MAPS: Merge Lubbock and Mainstone drivers into common PXA2xx driver Replace Lubbock and Mainstone board drivers with common PXA2xx driver, convert to platform driver (corresponding platform device changes merged to kernel.org for 2.6.15), add power management callbacks. Signed-off-by: Todd Poynor <tpoynor@mvista.com> Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-11-08 05:47:48 +08:00
This provides a driver for the NOR flash attached to a PXA2xx chip.
[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-02 06:55:24 +08:00
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-17 06:20:36 +08:00
config MTD_SCx200_DOCFLASH
tristate "Flash device mapped with DOCCS on NatSemi SCx200"
mtd: scx200_docflash: convert to mtd_device_register() Convert to mtd_device_register() and remove the CONFIG_MTD_PARTITIONS preprocessor conditionals as partitioning is always available. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-05-23 17:23:10 +08:00
depends on SCx200 && 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-17 06:20:36 +08:00
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.
[MTD] MAPS: Support for BIOS flash chips on Intel ESB2 southbridge Add MTD map driver for BIOS flash chips connected to the Intel ESB2 southbridge. [akpm@osdl.org: coding-style fixes, build fix] Signed-off-by: Ryan Jackson <rjackson@lnxi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-10-21 05:41:04 +08:00
config MTD_ESB2ROM
mtd: Make Kconfig formatting consistent Fix indentation and replace '---help---' by 'help' to make things consistent. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
2018-07-18 23:09:52 +08:00
tristate "BIOS flash chip on Intel ESB Controller Hub 2"
depends on X86 && MTD_JEDECPROBE && PCI
help
Support for treating the BIOS flash chip on ESB2 motherboards
as an MTD device - with this you can reprogram your BIOS.
[MTD] MAPS: Support for BIOS flash chips on Intel ESB2 southbridge Add MTD map driver for BIOS flash chips connected to the Intel ESB2 southbridge. [akpm@osdl.org: coding-style fixes, build fix] Signed-off-by: Ryan Jackson <rjackson@lnxi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-10-21 05:41:04 +08:00
mtd: Make Kconfig formatting consistent Fix indentation and replace '---help---' by 'help' to make things consistent. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
2018-07-18 23:09:52 +08:00
BE VERY CAREFUL.
[MTD] MAPS: Support for BIOS flash chips on Intel ESB2 southbridge Add MTD map driver for BIOS flash chips connected to the Intel ESB2 southbridge. [akpm@osdl.org: coding-style fixes, build fix] Signed-off-by: Ryan Jackson <rjackson@lnxi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-10-21 05:41:04 +08:00
[MTD] [MAPS] Support for BIOS flash chips on the nvidia ck804 southbridge Add support for accessing BIOS flash chips connected to the NVIDIA ck804 southbridge. Signed-off-by: Ryan Jackson <rjackson@lnxi.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-11-07 07:33:57 +08:00
config MTD_CK804XROM
tristate "BIOS flash chip on Nvidia CK804"
[MTD] CK804XROM must depend on PCI CONFIG_MTD_CK804XROM=y, CONFIG_PCI=n results in the following compile error: CC drivers/mtd/maps/ck804xrom.o ck804xrom.c: In function 'ck804xrom_init_one': ck804xrom.c:114: error: implicit declaration of function 'pci_dev_get' ck804xrom.c:114: warning: assignment makes pointer from integer without a cast make[4]: *** [drivers/mtd/maps/ck804xrom.o] Error 1 Considering what hardware this driver is driving, a dependency on PCI also seems logical. Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: Ryan Jackson <rjackson@lnxi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-26 07:15:17 +08:00
depends on X86 && MTD_JEDECPROBE && PCI
[MTD] [MAPS] Support for BIOS flash chips on the nvidia ck804 southbridge Add support for accessing BIOS flash chips connected to the NVIDIA ck804 southbridge. Signed-off-by: Ryan Jackson <rjackson@lnxi.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-11-07 07:33:57 +08:00
help
Support for treating the BIOS flash chip on nvidia motherboards
as an MTD device - with this you can reprogram your BIOS.
BE VERY CAREFUL.
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-17 06:20:36 +08:00
config MTD_SCB2_FLASH
tristate "BIOS flash chip on Intel SCB2 boards"
mtd: fix scb2_flash build when PCI is not enabled scb2_flash.c is a PCI driver, but its build fails when CONFIG_PCI is not enabled, so make it depend on PCI. drivers/mtd/maps/scb2_flash.c:237:1: warning: data definition has no type or storage class drivers/mtd/maps/scb2_flash.c:237:1: warning: type defaults to 'int' in declaration of 'module_pci_driver' drivers/mtd/maps/scb2_flash.c:237:1: warning: parameter names (without types) in function declaration Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-04-17 03:50:37 +08:00
depends on X86 && MTD_JEDECPROBE && PCI
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-17 06:20:36 +08:00
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_NETtel
tristate "CFI flash device on SnapGear/SecureEdge"
mtd: kill CONFIG_MTD_PARTITIONS Now that none of the drivers use CONFIG_MTD_PARTITIONS we can remove it from Kconfig and the last remaining uses. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-05-23 17:23:43 +08:00
depends on X86 && MTD_JEDECPROBE
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-17 06:20:36 +08:00
help
Support for flash chips on NETtel/SecureEdge/SnapGear boards.
MIPS: Lantiq: Add NOR flash support This patch adds the driver/map for NOR devices attached to the SoC via the External Bus Unit (EBU). Signed-off-by: John Crispin <blogic@openwrt.org> Signed-off-by: Ralph Hempel <ralph.hempel@lantiq.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com> Cc: linux-mips@linux-mips.org Cc: linux-mtd@lists.infradead.org Acked-by: Artem Bityutskiy <dedekind1@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/2285/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2011-04-13 00:10:01 +08:00
config MTD_LANTIQ
tristate "Lantiq SoC NOR support"
depends on LANTIQ
help
Support for NOR flash attached to the Lantiq SoC's External Bus Unit.
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-17 06:20:36 +08:00
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_CFI_FLAGADM
tristate "CFI Flash device mapping on FlagaDM"
mtd: replace CONFIG_8xx by CONFIG_PPC_8xx Two config options exist to define powerpc MPC8xx: * CONFIG_PPC_8xx * CONFIG_8xx In addition, CONFIG_PPC_8xx also defines CONFIG_CPM1 as communication co-processor arch/powerpc/platforms/Kconfig.cputype has contained the following comment about CONFIG_8xx item for some years: "# this is temp to handle compat with arch=ppc" It looks like not many places still have that old CONFIG_8xx used, so it is likely to be a good time to get rid of it completely ? Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-03-12 23:24:04 +08:00
depends on PPC_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-17 06:20:36 +08:00
help
Mapping for the Flaga digital module. If you don't have one, ignore
this setting.
config MTD_SOLUTIONENGINE
tristate "CFI Flash device mapped on Hitachi SolutionEngine"
mtd: maps: solutionengine: drop excess dependency Already depends on SOLUTION_ENGINE, so we don't need the SUPERH dependency too. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-07-22 10:07:56 +08:00
depends on SOLUTION_ENGINE && MTD_CFI && MTD_REDBOOT_PARTS
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-17 06:20:36 +08:00
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_SA1100
tristate "CFI Flash device mapped on StrongARM SA11x0"
mtd: sa1100-flash: convert to mtd_device_register() Convert to mtd_device_register() and remove the CONFIG_MTD_PARTITIONS preprocessor conditionals as partitioning is always available. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-05-23 17:23:09 +08:00
depends on MTD_CFI && ARCH_SA1100
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-17 06:20:36 +08: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_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 17:46:19 +08: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-17 06:20:36 +08:00
help
This provides a driver for the flash accessed using Intel's
21285 bridge used with Intel's StrongARM processors. More info at
mtd: Replace HTTP links with HTTPS ones Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-07-14 00:54:08 +08:00
<https://www.intel.com/design/bridge/docs/21285_documentation.htm>.
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-17 06:20:36 +08:00
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.
# This needs CFI or JEDEC, depending on the cards found.
config MTD_PCI
tristate "PCI MTD driver"
Use menuconfig objects: MTD Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-04-20 05:21:41 +08:00
depends on PCI && 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-17 06:20:36 +08:00
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"
pcmciamtd: fixing obvious errors After fixing the obvious errors, the driver will now compile again on v2.6.34-rc3. First tests with two 4MB flash cards including erase- and write test with one of the cards where successful. Also, add two new PCMCIA_DEVICE_PROD_IDs. [linux@dominikbrodowski.net: clean up commit message] Signed-off-by: Alexander Kurz <linux@kbdbabel.org> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2010-05-13 17:59:59 +08:00
depends on PCMCIA && 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-17 06:20:36 +08:00
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-28 07:28:32 +08: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-17 06:20:36 +08:00
config MTD_UCLINUX
mtd: uclinux: do not allow to be built as a module There isn't any benefit to building the uClinux MTD map as a module as the rootfs it requires in order to actually be usable is appended to the kernel image, not the module. No known system builds it this way either, so change the option to "bool". Signed-off-by: Mike Frysinger <vapier@gentoo.org> CC: Paul Mundt <lethal@linux-sh.org> CC: Greg Ungerer <gerg@uclinux.org> CC: uclinux-dev@uclinux.org CC: linux-mtd@lists.infradead.org Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-05-27 07:33:18 +08:00
bool "Generic uClinux RAM/ROM filesystem support"
mtd: uclinux: support ROM and allow passing the base address This allows to put the filesystem at a defined address in ROM allowing to save more precious RAM. I think it's safe to default to ROM because the intention of using the uclinux map is to use a romfs and so mtd-ram doesn't give you anything that mtd-rom doesn't. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2013-01-16 22:36:55 +08:00
depends on (MTD_RAM=y || MTD_ROM=y) && (!MMU || COLDFIRE)
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-17 06:20:36 +08:00
help
Map driver to support image based filesystems for uClinux.
[MTD] map driver for NOR flash on the Intel Vermilion Range chipset The Vermilion Range Expansion Bus supports four chip selects, each of which has 64MiB of address space. The 2nd BAR of the Expansion Bus PCI Device is a 256MiB memory region containing the address spaces for all four of the chip selects, with start addresses hardcoded on 64MiB boundaries. This map driver only supports NOR flash on chip select 0. The buswidth (either 8 bits or 16 bits) is determined by reading the Expansion Bus Timing and Control Register for Chip Select 0 (EXP_TIMING_CS0). Signed-off-by: Andy Lowe <alowe@mvista.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-09-24 01:51:25 +08:00
config MTD_INTEL_VR_NOR
tristate "NOR flash on Intel Vermilion Range Expansion Bus CS0"
depends on PCI
help
Map driver for a NOR flash bank located on the Expansion Bus of the
Intel Vermilion Range chipset.
[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-24 08:37:04 +08:00
config MTD_PLATRAM
[MTD] Fix typo in Kconfig Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-03-18 10:07:24 +08: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-24 08:37:04 +08:00
select MTD_RAM
help
Map driver for RAM areas described via the platform device
system.
This selection automatically selects the map_ram driver.
mtd: flash mapping support for Dreamcast VMU. This patch adds support for the Sega Dreamcast visual memory unit as a flash mapping. It requires changes in the maple bus driver (posted separately) to support block reads and writes. The VMU is a 'smart' flash device, with a built-in 8-bit controller - for instance there is an erase before a write but it is hidden from the user. But the device's overall behaviour means it works well with the mtd layer and it is appropriate to add it as an mtd mapping. Signed-off-by: Adrian McMenamin <adrian@mcmen.demon.co.uk> Acked-By: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2009-03-04 08:31:04 +08:00
config MTD_VMU
tristate "Map driver for Dreamcast VMU"
depends on MAPLE
help
This driver enables access to the Dreamcast Visual Memory Unit (VMU).
Most Dreamcast users will want to say Y here.
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-17 06:20:36 +08:00
mtd: flash mapping support for Dreamcast VMU. This patch adds support for the Sega Dreamcast visual memory unit as a flash mapping. It requires changes in the maple bus driver (posted separately) to support block reads and writes. The VMU is a 'smart' flash device, with a built-in 8-bit controller - for instance there is an erase before a write but it is hidden from the user. But the device's overall behaviour means it works well with the mtd layer and it is appropriate to add it as an mtd mapping. Signed-off-by: Adrian McMenamin <adrian@mcmen.demon.co.uk> Acked-By: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2009-03-04 08:31:04 +08:00
To build this as a module select M here, the module will be called
vmu-flash.
mtd: Really add ARM pismo support (Commit 7cb777a3d71f9d1f7eb149c7a504d21f24219ae8 (mtd: add ARM pismo support) intended to add this, but seems only to have patched the Makefile without touching Kconfig or providing any code...) The following patch adds support for PISMO modules found on ARM Ltd development platforms. These are MTD modules, and can have a selection of SRAM, flash or DOC devices as described by an on-board I2C EEPROM. We support SRAM and NOR flash devices only by registering appropriate conventional MTD platform devices as children of the 'pismo' device. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-11-29 23:23:51 +08:00
config MTD_PISMO
tristate "MTD discovery driver for PISMO modules"
depends on I2C
depends on ARCH_VERSATILE
help
This driver allows for discovery of PISMO modules - see
<http://www.pismoworld.org/>. These are small modules containing
up to five memory devices (eg, SRAM, flash, DOC) described by an
I2C EEPROM.
This driver does not create any MTD maps itself; instead it
creates MTD physmap and MTD SRAM platform devices. If you
enable this option, you should consider enabling MTD_PHYSMAP
and/or MTD_PLATRAM according to the devices on your module.
When built as a module, it will be called pismo.ko
mtd: flash mapping support for Dreamcast VMU. This patch adds support for the Sega Dreamcast visual memory unit as a flash mapping. It requires changes in the maple bus driver (posted separately) to support block reads and writes. The VMU is a 'smart' flash device, with a built-in 8-bit controller - for instance there is an erase before a write but it is hidden from the user. But the device's overall behaviour means it works well with the mtd layer and it is appropriate to add it as an mtd mapping. Signed-off-by: Adrian McMenamin <adrian@mcmen.demon.co.uk> Acked-By: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2009-03-04 08:31:04 +08:00
endmenu