dect
/
linux-2.6
Archived
13
0
Fork 0
This repository has been archived on 2022-02-17. You can view files and clone it, but cannot push or open issues or pull requests.
linux-2.6/arch/arm/mach-omap2/Kconfig

170 lines
3.4 KiB
Plaintext
Raw Normal View History

comment "OMAP Core Type"
depends on ARCH_OMAP2
config ARCH_OMAP2420
bool "OMAP2420 support"
depends on ARCH_OMAP2
select OMAP_DM_TIMER
select ARCH_OMAP_OTG
config ARCH_OMAP2430
bool "OMAP2430 support"
depends on ARCH_OMAP2
config ARCH_OMAP3430
bool "OMAP3430 support"
depends on ARCH_OMAP3
select ARCH_OMAP_OTG
config OMAP_PACKAGE_CBC
bool
config OMAP_PACKAGE_CBB
bool
config OMAP_PACKAGE_CUS
bool
config OMAP_PACKAGE_CBP
bool
comment "OMAP Board Type"
depends on ARCH_OMAP2PLUS
config MACH_OMAP_GENERIC
bool "Generic OMAP board"
depends on ARCH_OMAP2
config MACH_OMAP2_TUSB6010
bool
depends on ARCH_OMAP2 && ARCH_OMAP2420
default y if MACH_NOKIA_N8X0
config MACH_OMAP_H4
bool "OMAP 2420 H4 board"
depends on ARCH_OMAP2
select OMAP_DEBUG_DEVICES
config MACH_OMAP_APOLLON
bool "OMAP 2420 Apollon board"
depends on ARCH_OMAP2
config MACH_OMAP_2430SDP
bool "OMAP 2430 SDP board"
depends on ARCH_OMAP2
config MACH_OMAP3_BEAGLE
bool "OMAP3 BEAGLE board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_DEVKIT8000
bool "DEVKIT8000 board"
depends on ARCH_OMAP3
config MACH_OMAP_LDP
bool "OMAP3 LDP board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OVERO
bool "Gumstix Overo board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OMAP3EVM
bool "OMAP 3530 EVM board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OMAP3517EVM
bool "OMAP3517/ AM3517 EVM board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OMAP3_PANDORA
bool "OMAP3 Pandora"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OMAP3_TOUCHBOOK
bool "OMAP3 Touch Book"
depends on ARCH_OMAP3
select BACKLIGHT_CLASS_DEVICE
config MACH_OMAP_3430SDP
bool "OMAP 3430 SDP board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_NOKIA_N800
bool
config MACH_NOKIA_N810
bool
config MACH_NOKIA_N810_WIMAX
bool
config MACH_NOKIA_N8X0
bool "Nokia N800/N810"
depends on ARCH_OMAP2420
select MACH_NOKIA_N800
select MACH_NOKIA_N810
select MACH_NOKIA_N810_WIMAX
config MACH_NOKIA_RX51
bool "Nokia RX-51 board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OMAP_ZOOM2
bool "OMAP3 Zoom2 board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OMAP_ZOOM3
bool "OMAP3630 Zoom3 board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBP
config MACH_CM_T35
bool "CompuLab CM-T35 module"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CUS
select OMAP_MUX
config MACH_IGEP0020
bool "IGEP v2 board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OMAP_3630SDP
bool "OMAP3630 SDP board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBP
config MACH_OMAP_4430SDP
bool "OMAP 4430 SDP board"
depends on ARCH_OMAP4
config OMAP3_EMU
bool "OMAP3 debugging peripherals"
depends on ARCH_OMAP3
select OC_ETM
help
Say Y here to enable debugging hardware of omap3
OMAP3: SDRC: Place SDRC AC timing and MR changes in CORE DVFS SRAM code behind Kconfig The code that reprograms the SDRC memory controller during CORE DVFS, mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not ensure that all L3 initiators are prevented from accessing the SDRAM before modifying the SDRC AC timing and MR registers. This can cause memory to be corrupted or cause the SDRC to enter an unpredictable state. This patch places that code behind a Kconfig option, CONFIG_OMAP3_SDRC_AC_TIMING for now, and adds a note explaining what is going on. Ideally the code can be added back in once supporting code is present to ensure that other initiators aren't touching the SDRAM. At the very least, these registers should be reprogrammable during kernel init to deal with buggy bootloaders. Users who know that all other system initiators will not be touching the SDRAM can also re-enable this Kconfig option. This is a modification of a patch originally written by Rajendra Nayak <rnayak@ti.com> (the original is at http://patchwork.kernel.org/patch/51927/). Rather than removing the code completely, this patch just comments it out. Thanks to Benoît Cousson <b-cousson@ti.com> and Christophe Sucur <c-sucur@ti.com> for explaining the technical basis for this and for explaining what can be done to make this path work in future code. Thanks to Richard Woodruff <r-woodruff2@ti.com>, Nishanth Menon <nm@ti.com>, and Olof Johansson <olof@lixom.net> for their comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Christophe Sucur <c-sucur@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Olof Johansson <olof@lixom.net>
2009-12-08 23:33:14 +00:00
config OMAP3_SDRC_AC_TIMING
bool "Enable SDRC AC timing register changes"
depends on ARCH_OMAP3
OMAP3: SDRC: Place SDRC AC timing and MR changes in CORE DVFS SRAM code behind Kconfig The code that reprograms the SDRC memory controller during CORE DVFS, mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not ensure that all L3 initiators are prevented from accessing the SDRAM before modifying the SDRC AC timing and MR registers. This can cause memory to be corrupted or cause the SDRC to enter an unpredictable state. This patch places that code behind a Kconfig option, CONFIG_OMAP3_SDRC_AC_TIMING for now, and adds a note explaining what is going on. Ideally the code can be added back in once supporting code is present to ensure that other initiators aren't touching the SDRAM. At the very least, these registers should be reprogrammable during kernel init to deal with buggy bootloaders. Users who know that all other system initiators will not be touching the SDRAM can also re-enable this Kconfig option. This is a modification of a patch originally written by Rajendra Nayak <rnayak@ti.com> (the original is at http://patchwork.kernel.org/patch/51927/). Rather than removing the code completely, this patch just comments it out. Thanks to Benoît Cousson <b-cousson@ti.com> and Christophe Sucur <c-sucur@ti.com> for explaining the technical basis for this and for explaining what can be done to make this path work in future code. Thanks to Richard Woodruff <r-woodruff2@ti.com>, Nishanth Menon <nm@ti.com>, and Olof Johansson <olof@lixom.net> for their comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Christophe Sucur <c-sucur@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Olof Johansson <olof@lixom.net>
2009-12-08 23:33:14 +00:00
default n
help
If you know that none of your system initiators will attempt to
access SDRAM during CORE DVFS, select Y here. This should boost
SDRAM performance at lower CORE OPPs. There are relatively few
users who will wish to say yes at this point - almost everyone will
wish to say no. Selecting yes without understanding what is
going on could result in system crashes;