2014-06-10 21:06:10 +07:00
|
|
|
menu "TI OMAP/AM/DM/DRA Family"
|
|
|
|
|
depends on ARCH_MULTI_V6 || ARCH_MULTI_V7
|
|
|
|
|
|
2010-07-05 20:31:47 +07:00
|
|
|
config ARCH_OMAP2
|
2012-03-06 07:02:18 +07:00
|
|
|
bool "TI OMAP2"
|
2013-04-23 20:30:51 +07:00
|
|
|
depends on ARCH_MULTI_V6
|
2013-05-01 05:02:26 +07:00
|
|
|
select ARCH_OMAP2PLUS
|
2010-07-05 20:31:47 +07:00
|
|
|
select CPU_V6
|
2012-07-05 22:05:15 +07:00
|
|
|
select SOC_HAS_OMAP2_SDRC
|
2010-07-05 20:31:47 +07:00
|
|
|
|
|
|
|
|
config ARCH_OMAP3
|
2012-03-06 07:02:18 +07:00
|
|
|
bool "TI OMAP3"
|
2013-04-23 20:30:51 +07:00
|
|
|
depends on ARCH_MULTI_V7
|
2013-05-01 05:02:26 +07:00
|
|
|
select ARCH_OMAP2PLUS
|
2011-10-02 02:09:39 +07:00
|
|
|
select ARM_CPU_SUSPEND if PM
|
2012-09-14 16:20:34 +07:00
|
|
|
select OMAP_INTERCONNECT
|
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 23:12:25 +07:00
|
|
|
select PM_OPP if PM
|
2014-12-19 21:37:54 +07:00
|
|
|
select PM if CPU_IDLE
|
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 23:12:25 +07:00
|
|
|
select SOC_HAS_OMAP2_SDRC
|
2016-05-20 06:20:17 +07:00
|
|
|
select ARM_ERRATA_430973
|
2010-07-05 20:31:47 +07:00
|
|
|
|
|
|
|
|
config ARCH_OMAP4
|
2012-03-06 07:02:18 +07:00
|
|
|
bool "TI OMAP4"
|
2013-04-23 20:30:51 +07:00
|
|
|
depends on ARCH_MULTI_V7
|
2013-05-01 05:02:26 +07:00
|
|
|
select ARCH_OMAP2PLUS
|
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 23:12:25 +07:00
|
|
|
select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
|
|
|
|
|
select ARM_CPU_SUSPEND if PM
|
|
|
|
|
select ARM_ERRATA_720789
|
|
|
|
|
select ARM_GIC
|
2013-02-28 06:28:14 +07:00
|
|
|
select HAVE_ARM_SCU if SMP
|
2013-02-16 07:02:20 +07:00
|
|
|
select HAVE_ARM_TWD if SMP
|
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 23:12:25 +07:00
|
|
|
select OMAP_INTERCONNECT
|
2015-06-06 06:38:08 +07:00
|
|
|
select OMAP_INTERCONNECT_BARRIER
|
2014-06-19 16:19:10 +07:00
|
|
|
select PL310_ERRATA_588369 if CACHE_L2X0
|
|
|
|
|
select PL310_ERRATA_727915 if CACHE_L2X0
|
2010-12-09 22:13:47 +07:00
|
|
|
select PM_OPP if PM
|
2014-12-19 21:37:54 +07:00
|
|
|
select PM if CPU_IDLE
|
2013-03-21 21:42:17 +07:00
|
|
|
select ARM_ERRATA_754322
|
|
|
|
|
select ARM_ERRATA_775420
|
2016-05-24 23:12:29 +07:00
|
|
|
select OMAP_INTERCONNECT
|
2010-07-05 20:31:47 +07:00
|
|
|
|
2012-04-03 16:24:58 +07:00
|
|
|
config SOC_OMAP5
|
|
|
|
|
bool "TI OMAP5"
|
2013-04-23 20:30:51 +07:00
|
|
|
depends on ARCH_MULTI_V7
|
2013-05-01 05:02:26 +07:00
|
|
|
select ARCH_OMAP2PLUS
|
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 23:12:25 +07:00
|
|
|
select ARM_CPU_SUSPEND if PM
|
2012-04-03 16:24:58 +07:00
|
|
|
select ARM_GIC
|
2013-06-03 20:55:41 +07:00
|
|
|
select HAVE_ARM_SCU if SMP
|
2012-11-12 21:33:44 +07:00
|
|
|
select HAVE_ARM_ARCH_TIMER
|
2013-07-25 06:55:23 +07:00
|
|
|
select ARM_ERRATA_798181 if SMP
|
2015-09-10 04:18:14 +07:00
|
|
|
select OMAP_INTERCONNECT
|
2015-06-06 06:38:08 +07:00
|
|
|
select OMAP_INTERCONNECT_BARRIER
|
2015-09-10 04:18:14 +07:00
|
|
|
select PM_OPP if PM
|
2015-10-17 02:16:21 +07:00
|
|
|
select ZONE_DMA if ARM_LPAE
|
2012-04-03 16:24:58 +07:00
|
|
|
|
2013-05-01 05:02:26 +07:00
|
|
|
config SOC_AM33XX
|
2013-08-09 04:32:08 +07:00
|
|
|
bool "TI AM33XX"
|
2013-05-01 05:02:26 +07:00
|
|
|
depends on ARCH_MULTI_V7
|
|
|
|
|
select ARCH_OMAP2PLUS
|
|
|
|
|
select ARM_CPU_SUSPEND if PM
|
|
|
|
|
|
|
|
|
|
config SOC_AM43XX
|
|
|
|
|
bool "TI AM43x"
|
|
|
|
|
depends on ARCH_MULTI_V7
|
|
|
|
|
select ARCH_OMAP2PLUS
|
|
|
|
|
select ARM_GIC
|
|
|
|
|
select MACH_OMAP_GENERIC
|
2014-04-22 15:28:03 +07:00
|
|
|
select MIGHT_HAVE_CACHE_L2X0
|
2015-07-11 04:05:48 +07:00
|
|
|
select HAVE_ARM_SCU
|
2015-12-15 03:34:05 +07:00
|
|
|
select GENERIC_CLOCKEVENTS_BROADCAST
|
2015-12-15 03:34:06 +07:00
|
|
|
select HAVE_ARM_TWD
|
2016-05-13 01:20:52 +07:00
|
|
|
select ARM_ERRATA_754322
|
|
|
|
|
select ARM_ERRATA_775420
|
2016-10-20 03:44:12 +07:00
|
|
|
select OMAP_INTERCONNECT
|
2018-02-23 22:43:56 +07:00
|
|
|
select ARM_CPU_SUSPEND if PM
|
2013-05-01 05:02:26 +07:00
|
|
|
|
2014-01-10 16:25:28 +07:00
|
|
|
config SOC_DRA7XX
|
|
|
|
|
bool "TI DRA7XX"
|
|
|
|
|
depends on ARCH_MULTI_V7
|
|
|
|
|
select ARCH_OMAP2PLUS
|
|
|
|
|
select ARM_CPU_SUSPEND if PM
|
|
|
|
|
select ARM_GIC
|
2015-09-10 04:18:13 +07:00
|
|
|
select HAVE_ARM_SCU if SMP
|
2014-01-10 16:25:28 +07:00
|
|
|
select HAVE_ARM_ARCH_TIMER
|
2013-12-03 17:27:25 +07:00
|
|
|
select IRQ_CROSSBAR
|
2015-03-26 06:25:09 +07:00
|
|
|
select ARM_ERRATA_798181 if SMP
|
2015-09-10 04:18:13 +07:00
|
|
|
select OMAP_INTERCONNECT
|
2015-06-06 06:38:08 +07:00
|
|
|
select OMAP_INTERCONNECT_BARRIER
|
2015-09-10 04:18:13 +07:00
|
|
|
select PM_OPP if PM
|
2015-10-17 02:16:21 +07:00
|
|
|
select ZONE_DMA if ARM_LPAE
|
2017-08-10 23:56:20 +07:00
|
|
|
select PINCTRL_TI_IODELAY if OF && PINCTRL
|
2014-01-10 16:25:28 +07:00
|
|
|
|
2013-05-01 05:02:26 +07:00
|
|
|
config ARCH_OMAP2PLUS
|
|
|
|
|
bool
|
|
|
|
|
select ARCH_HAS_BANDGAP
|
|
|
|
|
select ARCH_HAS_HOLES_MEMORYMODEL
|
|
|
|
|
select ARCH_OMAP
|
|
|
|
|
select CLKSRC_MMIO
|
|
|
|
|
select GENERIC_IRQ_CHIP
|
2016-06-02 19:10:16 +07:00
|
|
|
select GPIOLIB
|
2013-09-26 05:44:39 +07:00
|
|
|
select MACH_OMAP_GENERIC
|
2014-11-21 00:13:42 +07:00
|
|
|
select MEMORY
|
2015-04-21 00:36:31 +07:00
|
|
|
select MFD_SYSCON
|
2013-05-01 05:02:26 +07:00
|
|
|
select OMAP_DM_TIMER
|
2014-11-21 00:13:42 +07:00
|
|
|
select OMAP_GPMC
|
2013-05-01 05:02:26 +07:00
|
|
|
select PINCTRL
|
|
|
|
|
select SOC_BUS
|
2017-10-11 04:23:43 +07:00
|
|
|
select TI_SYSC
|
2014-09-16 04:15:02 +07:00
|
|
|
select OMAP_IRQCHIP
|
2015-10-05 23:40:58 +07:00
|
|
|
select CLKSRC_TI_32K
|
2013-05-01 05:02:26 +07:00
|
|
|
help
|
|
|
|
|
Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
|
|
|
|
|
|
2015-06-06 06:38:08 +07:00
|
|
|
config OMAP_INTERCONNECT_BARRIER
|
|
|
|
|
bool
|
|
|
|
|
select ARM_HEAVY_MB
|
|
|
|
|
|
2013-05-01 05:02:26 +07:00
|
|
|
|
|
|
|
|
if ARCH_OMAP2PLUS
|
|
|
|
|
|
|
|
|
|
menu "TI OMAP2/3/4 Specific Features"
|
|
|
|
|
|
|
|
|
|
config ARCH_OMAP2PLUS_TYPICAL
|
|
|
|
|
bool "Typical OMAP configuration"
|
|
|
|
|
default y
|
|
|
|
|
select AEABI
|
|
|
|
|
select HIGHMEM
|
|
|
|
|
select I2C
|
|
|
|
|
select I2C_OMAP
|
|
|
|
|
select MENELAUS if ARCH_OMAP2
|
2013-02-07 17:51:46 +07:00
|
|
|
select NEON if CPU_V7
|
2014-12-19 21:37:54 +07:00
|
|
|
select PM
|
2013-05-01 05:02:26 +07:00
|
|
|
select REGULATOR
|
2015-11-26 22:22:23 +07:00
|
|
|
select REGULATOR_FIXED_VOLTAGE
|
2013-05-01 05:02:26 +07:00
|
|
|
select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
|
|
|
|
|
select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
|
|
|
|
|
select VFP
|
|
|
|
|
help
|
|
|
|
|
Compile a kernel suitable for booting most boards
|
|
|
|
|
|
|
|
|
|
config SOC_HAS_OMAP2_SDRC
|
|
|
|
|
bool "OMAP2 SDRAM Controller support"
|
|
|
|
|
|
|
|
|
|
config SOC_HAS_REALTIME_COUNTER
|
|
|
|
|
bool "Real time free running counter"
|
2013-02-07 14:55:39 +07:00
|
|
|
depends on SOC_OMAP5 || SOC_DRA7XX
|
2013-05-01 05:02:26 +07:00
|
|
|
default y
|
|
|
|
|
|
2005-11-10 21:26:51 +07:00
|
|
|
comment "OMAP Core Type"
|
2012-03-06 07:02:18 +07:00
|
|
|
depends on ARCH_OMAP2
|
2005-11-10 21:26:51 +07:00
|
|
|
|
2011-01-28 07:39:40 +07:00
|
|
|
config SOC_OMAP2420
|
2005-11-10 21:26:51 +07:00
|
|
|
bool "OMAP2420 support"
|
2012-03-06 07:02:18 +07:00
|
|
|
depends on ARCH_OMAP2
|
2010-07-05 20:31:47 +07:00
|
|
|
default y
|
2006-06-27 06:16:12 +07:00
|
|
|
select OMAP_DM_TIMER
|
2012-07-05 22:05:15 +07:00
|
|
|
select SOC_HAS_OMAP2_SDRC
|
2005-11-10 21:26:51 +07:00
|
|
|
|
2011-01-28 07:39:40 +07:00
|
|
|
config SOC_OMAP2430
|
2006-12-07 08:14:05 +07:00
|
|
|
bool "OMAP2430 support"
|
2012-03-06 07:02:18 +07:00
|
|
|
depends on ARCH_OMAP2
|
2010-07-05 20:31:47 +07:00
|
|
|
default y
|
2012-07-05 22:05:15 +07:00
|
|
|
select SOC_HAS_OMAP2_SDRC
|
2006-12-07 08:14:05 +07:00
|
|
|
|
2011-01-28 07:39:40 +07:00
|
|
|
config SOC_OMAP3430
|
2008-10-09 21:51:41 +07:00
|
|
|
bool "OMAP3430 support"
|
2012-03-06 07:02:18 +07:00
|
|
|
depends on ARCH_OMAP3
|
2010-07-05 20:31:47 +07:00
|
|
|
default y
|
2012-07-05 22:05:15 +07:00
|
|
|
select SOC_HAS_OMAP2_SDRC
|
2008-10-09 21:51:41 +07:00
|
|
|
|
2012-05-11 01:10:07 +07:00
|
|
|
config SOC_TI81XX
|
2011-12-14 01:46:44 +07:00
|
|
|
bool "TI81XX support"
|
2012-03-06 07:02:18 +07:00
|
|
|
depends on ARCH_OMAP3
|
2011-02-16 23:31:39 +07:00
|
|
|
default y
|
|
|
|
|
|
2009-12-12 07:16:32 +07:00
|
|
|
config OMAP_PACKAGE_CBC
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config OMAP_PACKAGE_CBB
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config OMAP_PACKAGE_CUS
|
|
|
|
|
bool
|
|
|
|
|
|
2009-12-12 07:16:33 +07:00
|
|
|
config OMAP_PACKAGE_CBP
|
|
|
|
|
bool
|
|
|
|
|
|
2013-09-26 05:44:39 +07:00
|
|
|
comment "OMAP Legacy Platform Data Board Type"
|
2012-03-06 07:02:18 +07:00
|
|
|
depends on ARCH_OMAP2PLUS
|
2005-11-10 21:26:51 +07:00
|
|
|
|
|
|
|
|
config MACH_OMAP_GENERIC
|
2013-09-26 05:44:39 +07:00
|
|
|
bool
|
2005-11-10 21:26:51 +07:00
|
|
|
|
2009-08-29 00:51:37 +07:00
|
|
|
config MACH_OMAP2_TUSB6010
|
|
|
|
|
bool
|
2011-01-28 07:39:40 +07:00
|
|
|
depends on ARCH_OMAP2 && SOC_OMAP2420
|
2009-08-29 00:51:37 +07:00
|
|
|
default y if MACH_NOKIA_N8X0
|
|
|
|
|
|
2015-01-20 23:49:08 +07:00
|
|
|
config MACH_OMAP3517EVM
|
|
|
|
|
bool "OMAP3517/ AM3517 EVM board"
|
|
|
|
|
depends on ARCH_OMAP3
|
|
|
|
|
default y
|
|
|
|
|
|
2008-12-11 08:36:54 +07:00
|
|
|
config MACH_OMAP3_PANDORA
|
|
|
|
|
bool "OMAP3 Pandora"
|
2010-02-13 03:26:48 +07:00
|
|
|
depends on ARCH_OMAP3
|
2010-07-05 20:31:47 +07:00
|
|
|
default y
|
2009-12-12 07:16:32 +07:00
|
|
|
select OMAP_PACKAGE_CBB
|
2009-03-24 08:38:16 +07:00
|
|
|
|
2009-10-23 04:48:13 +07:00
|
|
|
config MACH_NOKIA_N810
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config MACH_NOKIA_N810_WIMAX
|
|
|
|
|
bool
|
|
|
|
|
|
2009-08-29 00:51:38 +07:00
|
|
|
config MACH_NOKIA_N8X0
|
|
|
|
|
bool "Nokia N800/N810"
|
2011-01-28 07:39:40 +07:00
|
|
|
depends on SOC_OMAP2420
|
2010-07-05 20:31:47 +07:00
|
|
|
default y
|
2009-10-23 04:48:13 +07:00
|
|
|
select MACH_NOKIA_N810
|
|
|
|
|
select MACH_NOKIA_N810_WIMAX
|
2009-08-29 00:51:38 +07:00
|
|
|
|
2009-12-09 06:33:14 +07:00
|
|
|
config OMAP3_SDRC_AC_TIMING
|
|
|
|
|
bool "Enable SDRC AC timing register changes"
|
2010-02-13 03:26:48 +07:00
|
|
|
depends on ARCH_OMAP3
|
2009-12-09 06:33:14 +07:00
|
|
|
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;
|
|
|
|
|
|
2010-07-05 20:31:47 +07:00
|
|
|
endmenu
|
|
|
|
|
|
|
|
|
|
endif
|
2014-06-10 21:06:10 +07:00
|
|
|
|
ARM: OMAP5 / DRA7: Introduce workaround for 801819
Add workaround for Cortex-A15 ARM erratum 801819 which says in summary
that "A livelock can occur in the L2 cache arbitration that might
prevent a snoop from completing. Under certain conditions this can
cause the system to deadlock. "
Recommended workaround is as follows:
Do both of the following:
1) Do not use the write-back no-allocate memory type.
2) Do not issue write-back cacheable stores at any time when the cache
is disabled (SCTLR.C=0) and the MMU is enabled (SCTLR.M=1). Because it
is implementation defined whether cacheable stores update the cache when
the cache is disabled it is not expected that any portable code will
execute cacheable stores when the cache is disabled.
For implementations of Cortex-A15 configured without the “L2 arbitration
register slice” option (typically one or two core systems), you must
also do the following:
3) Disable write-streaming in each CPU by setting ACTLR[28:25] = 0b1111
So, we provide an option to disable write streaming on OMAP5 and DRA7.
It is a rare condition to occur and may be enabled selectively based
on platform acceptance of risk.
Applies to: A15 revisions r2p0, r2p1, r2p2, r2p3 or r2p4 and REVIDR[3]
is set to 0.
Based on ARM errata Document revision 18.0 (22 Nov 2013)
Note: the configuration for the workaround needs to be done with
each CPU bringup, since CPU0 bringup is done by bootloader, it is
recommended to have the workaround in the bootloader, kernel also does
ensure that CPU0 has the workaround and makes the workaround active
when CPU1 gets active.
With CONFIG_SMP disabled, it is expected to be done by the bootloader.
This does show significant degradation in synthetic tests such as
mbw (https://packages.qa.debian.org/m/mbw.html)
mbw -n 100 100|grep AVG (on a test platform)
Without enabling the erratum:
AVG Method: MEMCPY Elapsed: 0.13406 MiB: 100.00000 Copy: 745.913 MiB/s
AVG Method: DUMB Elapsed: 0.06746 MiB: 100.00000 Copy: 1482.357 MiB/s
AVG Method: MCBLOCK Elapsed: 0.03058 MiB: 100.00000 Copy: 3270.569 MiB/s
After enabling the erratum:
AVG Method: MEMCPY Elapsed: 0.13757 MiB: 100.00000 Copy: 726.913 MiB/s
AVG Method: DUMB Elapsed: 0.12024 MiB: 100.00000 Copy: 831.668 MiB/s
AVG Method: MCBLOCK Elapsed: 0.09243 MiB: 100.00000 Copy: 1081.942 MiB/s
Most benchmarks are designed for specific performance analysis, so
overall usecase must be considered before making a decision to
enable/disable the erratum workaround.
Pending internal investigation, the erratum is kept disabled by default.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Tony Lindgren <tony@atomide.com>
Suggested-by: Richard Woodruff <r-woodruff2@ti.com>
Suggested-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-08-06 22:54:24 +07:00
|
|
|
config OMAP5_ERRATA_801819
|
|
|
|
|
bool "Errata 801819: An eviction from L1 data cache might stall indefinitely"
|
|
|
|
|
depends on SOC_OMAP5 || SOC_DRA7XX
|
|
|
|
|
help
|
|
|
|
|
A livelock can occur in the L2 cache arbitration that might prevent
|
|
|
|
|
a snoop from completing. Under certain conditions this can cause the
|
|
|
|
|
system to deadlock.
|
|
|
|
|
|
2014-06-10 21:06:10 +07:00
|
|
|
endmenu
|