2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-19 02:34:01 +08:00
linux-next/arch/arm/plat-omap/Kconfig

178 lines
5.3 KiB
Plaintext
Raw Normal View History

if ARCH_OMAP
menu "TI OMAP Common Features"
config ARCH_OMAP_OTG
bool
comment "OMAP Feature Selections"
config OMAP_DEBUG_DEVICES
bool
help
For debug cards on TI reference boards.
config OMAP_DEBUG_LEDS
def_bool y if NEW_LEDS
depends on OMAP_DEBUG_DEVICES
ARM: config: sort select statements alphanumerically As suggested by Andrew Morton: This is a pet peeve of mine. Any time there's a long list of items (header file inclusions, kconfig entries, array initalisers, etc) and someone wants to add a new item, they *always* go and stick it at the end of the list. Guys, don't do this. Either put the new item into a randomly-chosen position or, probably better, alphanumerically sort the list. lets sort all our select statements alphanumerically. This commit was created by the following perl: while (<>) { while (/\\\s*$/) { $_ .= <>; } undef %selects if /^\s*config\s+/; if (/^\s+select\s+(\w+).*/) { if (defined($selects{$1})) { if ($selects{$1} eq $_) { print STDERR "Warning: removing duplicated $1 entry\n"; } else { print STDERR "Error: $1 differently selected\n". "\tOld: $selects{$1}\n". "\tNew: $_\n"; exit 1; } } $selects{$1} = $_; next; } if (%selects and (/^\s*$/ or /^\s+help/ or /^\s+---help---/ or /^endif/ or /^endchoice/)) { foreach $k (sort (keys %selects)) { print "$selects{$k}"; } undef %selects; } print; } if (%selects) { foreach $k (sort (keys %selects)) { print "$selects{$k}"; } } It found two duplicates: Warning: removing duplicated S5P_SETUP_MIPIPHY entry Warning: removing duplicated HARDIRQS_SW_RESEND entry and they are identical duplicates, hence the shrinkage in the diffstat of two lines. We have four testers reporting success of this change (Tony, Stephen, Linus and Sekhar.) Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-10-07 00:12:25 +08:00
select LEDS_CLASS
config POWER_AVS_OMAP
bool "AVS(Adaptive Voltage Scaling) support for OMAP IP versions 1&2"
depends on POWER_AVS && (ARCH_OMAP3 || ARCH_OMAP4) && PM
select POWER_SUPPLY
OMAP3: PM: Adding smartreflex driver support. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. With Smartreflex the power supply voltage can be adapted to the silicon performance(manufacturing process, temperature induced performance, age induced performance etc). There are differnet classes of smartreflex implementation. Class-0: Manufacturing Test Calibration Class-1: Boot-Time Software Calibration Class-2: Continuous Software Calibration Class-3: Continuous Hardware Calibration Class-4: Fully Integrated Power Management OMAP3 has two smartreflex modules one associated with VDD MPU and the other associated with VDD CORE. This patch adds support for smartreflex driver. The driver is designed for Class-1 , Class-2 and Class-3 support and is a platform driver. Smartreflex driver can be enabled through a Kconfig option "SmartReflex support" under "System type"->"TI OMAP implementations" menu. Smartreflex autocompensation feature can be enabled runtime through a debug fs option. To enable smartreflex autocompensation feature echo 1 > /debug/voltage/vdd_<X>/smartreflex/autocomp To disable smartreflex autocompensation feature echo 0 > /debug/voltage/vdd_<X>/smartreflex/autocomp where X can be mpu, core , iva etc. This patch contains code originally in linux omap pm branch. Major contributors to this driver are Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley, Nishant Menon, Kevin Hilman. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-30 00:32:22 +08:00
help
Say Y to enable AVS(Adaptive Voltage Scaling)
support on OMAP containing the version 1 or
version 2 of the SmartReflex IP.
V1 is the 65nm version used in OMAP3430.
V2 is the update for the 45nm version of the IP used in OMAP3630
and OMAP4430
OMAP3: PM: Adding smartreflex driver support. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. With Smartreflex the power supply voltage can be adapted to the silicon performance(manufacturing process, temperature induced performance, age induced performance etc). There are differnet classes of smartreflex implementation. Class-0: Manufacturing Test Calibration Class-1: Boot-Time Software Calibration Class-2: Continuous Software Calibration Class-3: Continuous Hardware Calibration Class-4: Fully Integrated Power Management OMAP3 has two smartreflex modules one associated with VDD MPU and the other associated with VDD CORE. This patch adds support for smartreflex driver. The driver is designed for Class-1 , Class-2 and Class-3 support and is a platform driver. Smartreflex driver can be enabled through a Kconfig option "SmartReflex support" under "System type"->"TI OMAP implementations" menu. Smartreflex autocompensation feature can be enabled runtime through a debug fs option. To enable smartreflex autocompensation feature echo 1 > /debug/voltage/vdd_<X>/smartreflex/autocomp To disable smartreflex autocompensation feature echo 0 > /debug/voltage/vdd_<X>/smartreflex/autocomp where X can be mpu, core , iva etc. This patch contains code originally in linux omap pm branch. Major contributors to this driver are Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley, Nishant Menon, Kevin Hilman. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-30 00:32:22 +08:00
Please note, that by default SmartReflex is only
initialized and not enabled. To enable the automatic voltage
compensation for vdd mpu and vdd core from user space,
OMAP3: PM: Adding smartreflex driver support. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. With Smartreflex the power supply voltage can be adapted to the silicon performance(manufacturing process, temperature induced performance, age induced performance etc). There are differnet classes of smartreflex implementation. Class-0: Manufacturing Test Calibration Class-1: Boot-Time Software Calibration Class-2: Continuous Software Calibration Class-3: Continuous Hardware Calibration Class-4: Fully Integrated Power Management OMAP3 has two smartreflex modules one associated with VDD MPU and the other associated with VDD CORE. This patch adds support for smartreflex driver. The driver is designed for Class-1 , Class-2 and Class-3 support and is a platform driver. Smartreflex driver can be enabled through a Kconfig option "SmartReflex support" under "System type"->"TI OMAP implementations" menu. Smartreflex autocompensation feature can be enabled runtime through a debug fs option. To enable smartreflex autocompensation feature echo 1 > /debug/voltage/vdd_<X>/smartreflex/autocomp To disable smartreflex autocompensation feature echo 0 > /debug/voltage/vdd_<X>/smartreflex/autocomp where X can be mpu, core , iva etc. This patch contains code originally in linux omap pm branch. Major contributors to this driver are Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley, Nishant Menon, Kevin Hilman. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-30 00:32:22 +08:00
user must write 1 to
/debug/smartreflex/sr_<X>/autocomp,
where X is mpu_iva or core for OMAP3.
Optionally autocompensation can be enabled in the kernel
OMAP3: PM: Adding smartreflex driver support. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. With Smartreflex the power supply voltage can be adapted to the silicon performance(manufacturing process, temperature induced performance, age induced performance etc). There are differnet classes of smartreflex implementation. Class-0: Manufacturing Test Calibration Class-1: Boot-Time Software Calibration Class-2: Continuous Software Calibration Class-3: Continuous Hardware Calibration Class-4: Fully Integrated Power Management OMAP3 has two smartreflex modules one associated with VDD MPU and the other associated with VDD CORE. This patch adds support for smartreflex driver. The driver is designed for Class-1 , Class-2 and Class-3 support and is a platform driver. Smartreflex driver can be enabled through a Kconfig option "SmartReflex support" under "System type"->"TI OMAP implementations" menu. Smartreflex autocompensation feature can be enabled runtime through a debug fs option. To enable smartreflex autocompensation feature echo 1 > /debug/voltage/vdd_<X>/smartreflex/autocomp To disable smartreflex autocompensation feature echo 0 > /debug/voltage/vdd_<X>/smartreflex/autocomp where X can be mpu, core , iva etc. This patch contains code originally in linux omap pm branch. Major contributors to this driver are Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley, Nishant Menon, Kevin Hilman. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-30 00:32:22 +08:00
by default during system init via the enable_on_init flag
which an be passed as platform data to the smartreflex driver.
config POWER_AVS_OMAP_CLASS3
bool "Class 3 mode of Smartreflex Implementation"
depends on POWER_AVS_OMAP && TWL4030_CORE
help
Say Y to enable Class 3 implementation of Smartreflex
Class 3 implementation of Smartreflex employs continuous hardware
voltage calibration.
config OMAP_RESET_CLOCKS
bool "Reset unused clocks during boot"
depends on ARCH_OMAP
help
Say Y if you want to reset unused clocks during boot.
This option saves power, but assumes all drivers are
using the clock framework. Broken drivers that do not
yet use clock framework may not work with this option.
If you are booting from another operating system, you
probably do not want this option enabled until your
device drivers work properly.
config OMAP_MUX
bool "OMAP multiplexing support"
depends on ARCH_OMAP
default y
help
Pin multiplexing support for OMAP boards. If your bootloader
sets the multiplexing correctly, say N. Otherwise, or if unsure,
say Y.
config OMAP_MUX_DEBUG
bool "Multiplexing debug output"
depends on OMAP_MUX
help
Makes the multiplexing functions print out a lot of debug info.
This is useful if you want to find out the correct values of the
multiplexing registers.
config OMAP_MUX_WARNINGS
bool "Warn about pins the bootloader didn't set up"
depends on OMAP_MUX
default y
help
Choose Y here to warn whenever driver initialization logic needs
to change the pin multiplexing setup. When there are no warnings
printed, it's safe to deselect OMAP_MUX for your product.
config OMAP_MBOX_FWK
tristate "Mailbox framework support"
ARM: OMAP2+: Disable code that currently does not work with multiplaform We still need to fix up few places for multiplatform support, but that can proceed separately. Fix the issue by making the problem drivers depends !ARCH_MULTIPLATFORM for now. The remaining pieces that are not multiplatform compatible for omap2+ SoCs are: 1. Some drivers are using custom omap_dm_timer calls There are two drivers that are directly usign omap hardware timers for PWM and DSP clocking: drivers/media/rc/ir-rx51.c and drivers/staging/tidspbridge/core/dsp-clock.c. These can be fixed for multiplatform by allowing a minimal set of hardware timers to be accessed, and for some functionality by using the hrtimer framework. 2. Hardware OMAP4_ERRATA_I688 needs to be fixed up This can't be enabled for multiplatform configurations in it's current form. It may be possible to fix it up to do instruction replacement early on during init. Luckily it looks like this errata does not seem to get hit with mainline kernel code alone at least currently. 3. Legacy header needed for omap-sham.c Looks like it still needs mach/irqs.h for omap1 that does not exist for multiplatform systems. Just ifdef it for now. 4. Mailbox is waiting to get moved to drivers Disable it for now to avoid adding a dependency to the mailbox patches. Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi> Cc: Sean Young <sean@mess.org> Cc: "Víctor Manuel Jáquez Leal" <vjaquez@igalia.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> [tony@atomide.com: updated to disable mailbox] Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-01-12 03:24:20 +08:00
depends on ARCH_OMAP && !ARCH_MULTIPLATFORM
help
Say Y here if you want to use OMAP Mailbox framework support for
DSP, IVA1.0 and IVA2 in OMAP1/2/3.
config OMAP_MBOX_KFIFO_SIZE
int "Mailbox kfifo default buffer size (bytes)"
depends on OMAP_MBOX_FWK
default 256
help
Specify the default size of mailbox's kfifo buffers (bytes).
This can also be changed at runtime (via the mbox_kfifo_size
module parameter).
config OMAP_IOMMU_IVA2
bool
config OMAP_MPU_TIMER
bool "Use mpu timer"
depends on ARCH_OMAP1
help
Select this option if you want to use the OMAP mpu timer. This
timer provides more intra-tick resolution than the 32KHz timer,
but consumes more power.
config OMAP_32K_TIMER
bool "Use 32KHz timer"
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
default y if (ARCH_OMAP16XX || ARCH_OMAP2PLUS)
help
Select this option if you want to enable the OMAP 32KHz timer.
This timer saves power compared to the OMAP_MPU_TIMER, and has
support for no tick during idle. The 32KHz timer provides less
intra-tick resolution than OMAP_MPU_TIMER. The 32KHz timer is
currently only available for OMAP16XX, 24XX, 34XX and OMAP4/5.
ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way. Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER setting. To remove the dependancy, several conversions/additions had to be done: 1) Timer initialization functions are named by the platform name and the clock source in use. This also makes it possible to define and use the GPTIMER as the clock source instead of the 32K timer on platforms that do not have the 32K timer ip block or the 32K timer is not wired on the board. Currently, the the timer is chosen in the machine_desc structure on per board basis. Later, DT should be used to choose the timer. 2) Settings under the CONFIG_OMAP_32K_TIMER option are used as defaults and those under !CONFIG_OMAP_32K_TIMER are removed. This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code. 3) Since we have all the timers defined inside machine_desc structure and we no longer need the fallback to gp_timer clock source in case 32k_timer clock source is unavailable (namely on AM33xx), we no longer need the #ifdef around omap2_sync32k_clocksource_init() function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the omap2_sync32k_clocksource_init() function. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com>
2012-11-20 15:17:15 +08:00
On OMAP2PLUS this value is only used for CONFIG_HZ and
CLOCK_TICK_RATE compile time calculation.
The actual timer selection is done in the board file
through the (DT_)MACHINE_START structure.
config OMAP3_L2_AUX_SECURE_SAVE_RESTORE
bool "OMAP3 HS/EMU save and restore for L2 AUX control register"
depends on ARCH_OMAP3 && PM
default n
help
Without this option, L2 Auxiliary control register contents are
lost during off-mode entry on HS/EMU devices. This feature
requires support from PPA / boot-loader in HS/EMU devices, which
currently does not exist by default.
config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
int "Service ID for the support routine to set L2 AUX control"
depends on OMAP3_L2_AUX_SECURE_SAVE_RESTORE
default 43
help
PPA routine service ID for setting L2 auxiliary control register.
config OMAP_DM_TIMER
bool "Use dual-mode timer"
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
help
Select this option if you want to use OMAP Dual-Mode timers.
config OMAP_SERIAL_WAKE
bool "Enable wake-up events for serial ports"
depends on ARCH_OMAP1 && OMAP_MUX
default y
help
Select this option if you want to have your system wake up
to data on the serial RX line. This allows you to wake the
system from serial console.
choice
prompt "OMAP PM layer selection"
depends on ARCH_OMAP
default OMAP_PM_NOOP
config OMAP_PM_NOOP
bool "No-op/debug PM layer"
endchoice
endmenu
endif