2005-07-10 18:58:15 +00:00
|
|
|
if ARCH_OMAP
|
|
|
|
|
|
2010-07-05 13:31:47 +00:00
|
|
|
menu "TI OMAP Common Features"
|
2005-07-10 18:58:15 +00:00
|
|
|
|
|
|
|
|
config ARCH_OMAP_OTG
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
choice
|
|
|
|
|
prompt "OMAP System Type"
|
2010-02-12 20:26:46 +00:00
|
|
|
default ARCH_OMAP2PLUS
|
2005-07-10 18:58:15 +00:00
|
|
|
|
|
|
|
|
config ARCH_OMAP1
|
|
|
|
|
bool "TI OMAP1"
|
2010-11-17 09:04:33 +00:00
|
|
|
select CLKDEV_LOOKUP
|
2011-05-09 08:51:03 +00:00
|
|
|
select CLKSRC_MMIO
|
2011-06-08 00:02:46 +00:00
|
|
|
select GENERIC_IRQ_CHIP
|
2011-10-01 19:10:32 +00:00
|
|
|
select HAVE_IDE
|
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-06 16:12:25 +00:00
|
|
|
select IRQ_DOMAIN
|
2012-04-04 22:48:04 +00:00
|
|
|
select NEED_MACH_IO_H if PCCARD
|
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-06 16:12:25 +00:00
|
|
|
select NEED_MACH_MEMORY_H
|
2010-02-12 20:26:46 +00:00
|
|
|
help
|
|
|
|
|
"Systems based on omap7xx, omap15xx or omap16xx"
|
|
|
|
|
|
|
|
|
|
config ARCH_OMAP2PLUS
|
|
|
|
|
bool "TI OMAP2/3/4"
|
2010-11-17 09:04:33 +00:00
|
|
|
select CLKDEV_LOOKUP
|
2011-05-22 09:01:21 +00:00
|
|
|
select GENERIC_IRQ_CHIP
|
2010-12-24 02:48:09 +00:00
|
|
|
select OMAP_DM_TIMER
|
2012-10-22 20:29:19 +00:00
|
|
|
select PINCTRL
|
2012-02-23 18:17:02 +00:00
|
|
|
select PROC_DEVICETREE if PROC_FS
|
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-06 16:12:25 +00:00
|
|
|
select SPARSE_IRQ
|
|
|
|
|
select USE_OF
|
2010-02-12 20:26:46 +00:00
|
|
|
help
|
2012-04-03 09:24:58 +00:00
|
|
|
"Systems based on OMAP2, OMAP3, OMAP4 or OMAP5"
|
2005-07-10 18:58:15 +00:00
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
comment "OMAP Feature Selections"
|
|
|
|
|
|
2006-12-07 01:14:03 +00:00
|
|
|
config OMAP_DEBUG_DEVICES
|
2006-12-07 01:14:03 +00:00
|
|
|
bool
|
|
|
|
|
help
|
2006-12-07 01:14:03 +00:00
|
|
|
For debug cards on TI reference boards.
|
|
|
|
|
|
|
|
|
|
config OMAP_DEBUG_LEDS
|
2012-03-13 18:14:39 +00:00
|
|
|
def_bool y if NEW_LEDS
|
2006-12-07 01:14:03 +00:00
|
|
|
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-06 16:12:25 +00:00
|
|
|
select LEDS_CLASS
|
2006-12-07 01:14:03 +00:00
|
|
|
|
2012-04-24 06:08:50 +00:00
|
|
|
config POWER_AVS_OMAP
|
|
|
|
|
bool "AVS(Adaptive Voltage Scaling) support for OMAP IP versions 1&2"
|
2012-04-25 11:13:17 +00:00
|
|
|
depends on POWER_AVS && (ARCH_OMAP3 || ARCH_OMAP4) && PM
|
2012-09-20 14:36:56 +00:00
|
|
|
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-29 16:32:22 +00:00
|
|
|
help
|
2012-04-25 11:13:17 +00:00
|
|
|
Say Y to enable AVS(Adaptive Voltage Scaling)
|
|
|
|
|
support on OMAP containing the version 1 or
|
2012-04-24 06:08:50 +00:00
|
|
|
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-29 16:32:22 +00:00
|
|
|
|
|
|
|
|
Please note, that by default SmartReflex is only
|
2012-04-24 06:08:50 +00:00
|
|
|
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-29 16:32:22 +00:00
|
|
|
user must write 1 to
|
2012-04-24 06:08:50 +00:00
|
|
|
/debug/smartreflex/sr_<X>/autocomp,
|
|
|
|
|
where X is mpu_iva or core for OMAP3.
|
2011-02-25 06:09:35 +00:00
|
|
|
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-29 16:32:22 +00:00
|
|
|
by default during system init via the enable_on_init flag
|
|
|
|
|
which an be passed as platform data to the smartreflex driver.
|
|
|
|
|
|
2012-04-24 06:08:50 +00:00
|
|
|
config POWER_AVS_OMAP_CLASS3
|
2010-05-29 16:32:25 +00:00
|
|
|
bool "Class 3 mode of Smartreflex Implementation"
|
2012-04-24 06:08:50 +00:00
|
|
|
depends on POWER_AVS_OMAP && TWL4030_CORE
|
2010-05-29 16:32:25 +00:00
|
|
|
help
|
|
|
|
|
Say Y to enable Class 3 implementation of Smartreflex
|
|
|
|
|
|
|
|
|
|
Class 3 implementation of Smartreflex employs continuous hardware
|
|
|
|
|
voltage calibration.
|
|
|
|
|
|
2005-07-10 18:58:18 +00:00
|
|
|
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.
|
|
|
|
|
|
2005-07-10 18:58:15 +00:00
|
|
|
config OMAP_MUX
|
|
|
|
|
bool "OMAP multiplexing support"
|
2009-12-08 23:33:10 +00:00
|
|
|
depends on ARCH_OMAP
|
2005-07-10 18:58:15 +00:00
|
|
|
default y
|
2009-12-08 23:33:10 +00:00
|
|
|
help
|
|
|
|
|
Pin multiplexing support for OMAP boards. If your bootloader
|
|
|
|
|
sets the multiplexing correctly, say N. Otherwise, or if unsure,
|
|
|
|
|
say Y.
|
2005-07-10 18:58:15 +00:00
|
|
|
|
|
|
|
|
config OMAP_MUX_DEBUG
|
|
|
|
|
bool "Multiplexing debug output"
|
2009-12-08 23:33:10 +00:00
|
|
|
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.
|
2005-07-10 18:58:15 +00:00
|
|
|
|
|
|
|
|
config OMAP_MUX_WARNINGS
|
|
|
|
|
bool "Warn about pins the bootloader didn't set up"
|
2009-12-08 23:33:10 +00:00
|
|
|
depends on OMAP_MUX
|
|
|
|
|
default y
|
|
|
|
|
help
|
2005-07-10 18:58:15 +00:00
|
|
|
Choose Y here to warn whenever driver initialization logic needs
|
2009-12-08 23:33:10 +00:00
|
|
|
to change the pin multiplexing setup. When there are no warnings
|
2005-07-10 18:58:15 +00:00
|
|
|
printed, it's safe to deselect OMAP_MUX for your product.
|
|
|
|
|
|
2009-03-24 01:07:23 +00:00
|
|
|
config OMAP_MBOX_FWK
|
|
|
|
|
tristate "Mailbox framework support"
|
|
|
|
|
depends on ARCH_OMAP
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you want to use OMAP Mailbox framework support for
|
|
|
|
|
DSP, IVA1.0 and IVA2 in OMAP1/2/3.
|
|
|
|
|
|
2010-05-05 15:33:09 +00:00
|
|
|
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).
|
|
|
|
|
|
2010-10-11 09:53:49 +00:00
|
|
|
config OMAP_IOMMU_IVA2
|
|
|
|
|
bool
|
|
|
|
|
|
2005-07-10 18:58:15 +00:00
|
|
|
config OMAP_MPU_TIMER
|
|
|
|
|
bool "Use mpu timer"
|
2011-01-18 20:42:23 +00:00
|
|
|
depends on ARCH_OMAP1
|
2005-07-10 18:58:15 +00:00
|
|
|
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"
|
2010-02-12 20:26:48 +00:00
|
|
|
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
|
2011-01-18 20:42:23 +00:00
|
|
|
default y if (ARCH_OMAP16XX || ARCH_OMAP2PLUS)
|
2005-07-10 18:58:15 +00:00
|
|
|
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
|
2012-04-03 09:24:58 +00:00
|
|
|
currently only available for OMAP16XX, 24XX, 34XX and OMAP4/5.
|
2005-07-10 18:58:15 +00:00
|
|
|
|
2012-11-20 07:17:15 +00: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.
|
|
|
|
|
|
|
|
|
|
|
2009-11-12 10:07:22 +00:00
|
|
|
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.
|
|
|
|
|
|
2005-07-10 18:58:15 +00:00
|
|
|
config OMAP_32K_TIMER_HZ
|
2009-12-08 23:33:10 +00:00
|
|
|
int "Kernel internal timer frequency for 32KHz timer"
|
|
|
|
|
range 32 1024
|
|
|
|
|
depends on OMAP_32K_TIMER
|
|
|
|
|
default "128"
|
|
|
|
|
help
|
2005-07-10 18:58:15 +00:00
|
|
|
Kernel internal timer frequency should be a divisor of 32768,
|
|
|
|
|
such as 64 or 128.
|
|
|
|
|
|
2005-09-07 16:20:26 +00:00
|
|
|
config OMAP_DM_TIMER
|
|
|
|
|
bool "Use dual-mode timer"
|
2010-02-12 20:26:48 +00:00
|
|
|
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
|
2005-09-07 16:20:26 +00:00
|
|
|
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"
|
2009-05-28 17:56:16 +00:00
|
|
|
depends on ARCH_OMAP1 && OMAP_MUX
|
2005-09-07 16:20:26 +00:00
|
|
|
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.
|
|
|
|
|
|
2009-09-03 17:14:01 +00:00
|
|
|
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
|
|
|
|
|
|
2005-07-10 18:58:15 +00:00
|
|
|
endmenu
|
|
|
|
|
|
|
|
|
|
endif
|
