UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/arch/arm/mach-iop32x/Kconfig

48 lines
1.2 KiB
Plaintext
Raw Normal View History

[ARM] 3817/1: iop3xx: split the iop3xx mach into iop32x and iop33x Split the iop3xx mach type into iop32x and iop33x -- split the config symbols, and move the code in the mach-iop3xx directory to the mach-iop32x and mach-iop33x directories. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:10:26 +08:00
if ARCH_IOP32X
menu "IOP32x Implementation Options"
comment "IOP32x Platform Types"
[ARM] 4271/1: iop32x: fix ep80219 detection (support iq80219 platforms) An iq80219 is a board with an iq31244 layout and an 80219 processor. It breaks the current assumption that all 80219 processors run on ep80219 platforms. This patch adds the "force_ep80219" option to the kernel to override boot loaders that have passed in the iq31244 id, and adds the MACHINE_START definition for ep80219. [ patch assumes that EP80219 has been added to mach-types ] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-03-17 02:31:06 +08:00
config MACH_EP80219
bool
[ARM] 3851/1: iop3xx: add io-data glantank support Add support for the IO-Data GLAN Tank, from Martin Michlmayr. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-21 09:46:03 +08:00
config MACH_GLANTANK
bool "Enable support for the IO-Data GLAN Tank"
help
Say Y here if you want to run your kernel on the GLAN Tank
NAS appliance or machines from IO-Data's HDL-Gxxx, HDL-GWxxx
and HDL-GZxxx series.
[ARM] 3817/1: iop3xx: split the iop3xx mach into iop32x and iop33x Split the iop3xx mach type into iop32x and iop33x -- split the config symbols, and move the code in the mach-iop3xx directory to the mach-iop32x and mach-iop33x directories. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:10:26 +08:00
config ARCH_IQ80321
bool "Enable support for IQ80321"
help
Say Y here if you want to run your kernel on the Intel IQ80321
[ARM] 3832/1: iop3xx: coding style cleanup Since the iop32x code isn't iop321-specific, and the iop33x code isn't iop331-specfic, do a s/iop321/iop32x/ and s/iop331/iop33x/, and tidy up the code to conform to the coding style guidelines somewhat better. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:26:25 +08:00
evaluation kit for the IOP321 processor.
[ARM] 3817/1: iop3xx: split the iop3xx mach into iop32x and iop33x Split the iop3xx mach type into iop32x and iop33x -- split the config symbols, and move the code in the mach-iop3xx directory to the mach-iop32x and mach-iop33x directories. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:10:26 +08:00
config ARCH_IQ31244
[ARM] 3832/1: iop3xx: coding style cleanup Since the iop32x code isn't iop321-specific, and the iop33x code isn't iop331-specfic, do a s/iop321/iop32x/ and s/iop331/iop33x/, and tidy up the code to conform to the coding style guidelines somewhat better. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:26:25 +08:00
bool "Enable support for EP80219/IQ31244"
[ARM] 4271/1: iop32x: fix ep80219 detection (support iq80219 platforms) An iq80219 is a board with an iq31244 layout and an 80219 processor. It breaks the current assumption that all 80219 processors run on ep80219 platforms. This patch adds the "force_ep80219" option to the kernel to override boot loaders that have passed in the iq31244 id, and adds the MACHINE_START definition for ep80219. [ patch assumes that EP80219 has been added to mach-types ] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-03-17 02:31:06 +08:00
select MACH_EP80219
[ARM] 3817/1: iop3xx: split the iop3xx mach into iop32x and iop33x Split the iop3xx mach type into iop32x and iop33x -- split the config symbols, and move the code in the mach-iop3xx directory to the mach-iop32x and mach-iop33x directories. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:10:26 +08:00
help
[ARM] 3832/1: iop3xx: coding style cleanup Since the iop32x code isn't iop321-specific, and the iop33x code isn't iop331-specfic, do a s/iop321/iop32x/ and s/iop331/iop33x/, and tidy up the code to conform to the coding style guidelines somewhat better. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:26:25 +08:00
Say Y here if you want to run your kernel on the Intel EP80219
evaluation kit for the Intel 80219 processor (a IOP321 variant)
or the IQ31244 evaluation kit for the IOP321 processor.
[ARM] 3817/1: iop3xx: split the iop3xx mach into iop32x and iop33x Split the iop3xx mach type into iop32x and iop33x -- split the config symbols, and move the code in the mach-iop3xx directory to the mach-iop32x and mach-iop33x directories. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:10:26 +08:00
[ARM] 3850/1: iop3xx: add thecus n2100 support Add support for the Thecus n2100 (80219-based.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-21 09:42:12 +08:00
config MACH_N2100
bool "Enable support for the Thecus n2100"
help
Say Y here if you want to run your kernel on the Thecus n2100
NAS appliance.
[ARM] 4348/4: iop3xx: Give Linux control over PCI initialization Currently the iop3xx platform support code assumes that RedBoot is the bootloader and has already initialized the ATU. Linux should handle this initialization for three reasons: 1/ The memory map that RedBoot sets up is not optimal (page_to_dma and virt_to_phys return different addresses). The effect of this is that using the dma mapping API for the internal bus dma units generates pci bus addresses that are incorrect for the internal bus. 2/ Not all iop platforms use RedBoot 3/ If the ATU is already initialized it indicates that the iop is an add-in card in another host, it does not own the PCI bus, and should not be re-initialized. Changelog: * rather than change nr_controllers to zero, simply do not call pci_common_init Cc: Lennert Buytenhek <kernel@wantstofly.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-03 00:59:44 +08:00
config IOP3XX_ATU
bool "Enable the PCI Controller"
default y
help
Say Y here if you want the IOP to initialize its PCI Controller.
Say N if the IOP is an add in card, the host system owns the PCI
bus in this case.
[ARM] 3817/1: iop3xx: split the iop3xx mach into iop32x and iop33x Split the iop3xx mach type into iop32x and iop33x -- split the config symbols, and move the code in the mach-iop3xx directory to the mach-iop32x and mach-iop33x directories. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-19 06:10:26 +08:00
endmenu
endif