linux_dsm_epyc7002/arch/arm/mach-omap2/Kconfig

341 lines
7.8 KiB
Plaintext
Raw Normal View History

menu "TI OMAP/AM/DM/DRA Family"
depends on ARCH_MULTI_V6 || ARCH_MULTI_V7
config ARCH_OMAP2
bool "TI OMAP2"
depends on ARCH_MULTI_V6
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-05-01 05:02:26 +07:00
select ARCH_OMAP2PLUS
select CPU_V6
select SOC_HAS_OMAP2_SDRC
config ARCH_OMAP3
bool "TI OMAP3"
depends on ARCH_MULTI_V7
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-05-01 05:02:26 +07:00
select ARCH_OMAP2PLUS
select ARM_CPU_SUSPEND if PM
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
select PM_RUNTIME if CPU_IDLE
select SOC_HAS_OMAP2_SDRC
config ARCH_OMAP4
bool "TI OMAP4"
depends on ARCH_MULTI_V7
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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
select HAVE_ARM_SCU if SMP
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
select PL310_ERRATA_588369 if CACHE_L2X0
select PL310_ERRATA_727915 if CACHE_L2X0
select PM_OPP if PM
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_RUNTIME if CPU_IDLE
select ARM_ERRATA_754322
select ARM_ERRATA_775420
config SOC_OMAP5
bool "TI OMAP5"
depends on ARCH_MULTI_V7
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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
select ARM_GIC
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select HAVE_ARM_ARCH_TIMER
select ARM_ERRATA_798181 if SMP
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-05-01 05:02:26 +07:00
config SOC_AM33XX
bool "TI AM33XX"
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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
select MIGHT_HAVE_CACHE_L2X0
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-05-01 05:02:26 +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
select HAVE_ARM_ARCH_TIMER
select IRQ_CROSSBAR
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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 ARCH_REQUIRE_GPIOLIB
select CLKSRC_MMIO
select GENERIC_IRQ_CHIP
select MACH_OMAP_GENERIC
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-05-01 05:02:26 +07:00
select OMAP_DM_TIMER
select PINCTRL
select SOC_BUS
select TI_PRIV_EDMA
select OMAP_IRQCHIP
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-05-01 05:02:26 +07:00
help
Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
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
select NEON if CPU_V7
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-05-01 05:02:26 +07:00
select PM_RUNTIME
select REGULATOR
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"
depends on SOC_OMAP5 || SOC_DRA7XX
ARM: OMAP: build mach-omap code only if needed If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-05-01 05:02:26 +07:00
default y
comment "OMAP Core Type"
depends on ARCH_OMAP2
config SOC_OMAP2420
bool "OMAP2420 support"
depends on ARCH_OMAP2
default y
select OMAP_DM_TIMER
select SOC_HAS_OMAP2_SDRC
config SOC_OMAP2430
bool "OMAP2430 support"
depends on ARCH_OMAP2
default y
select SOC_HAS_OMAP2_SDRC
config SOC_OMAP3430
bool "OMAP3430 support"
depends on ARCH_OMAP3
default y
select SOC_HAS_OMAP2_SDRC
config SOC_TI81XX
bool "TI81XX support"
depends on ARCH_OMAP3
default y
config OMAP_PACKAGE_CBC
bool
config OMAP_PACKAGE_CBB
bool
config OMAP_PACKAGE_CUS
bool
config OMAP_PACKAGE_CBP
bool
comment "OMAP Legacy Platform Data Board Type"
depends on ARCH_OMAP2PLUS
config MACH_OMAP_GENERIC
bool
config MACH_OMAP2_TUSB6010
bool
depends on ARCH_OMAP2 && SOC_OMAP2420
default y if MACH_NOKIA_N8X0
config MACH_OMAP3_BEAGLE
bool "OMAP3 BEAGLE board"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
config MACH_DEVKIT8000
bool "DEVKIT8000 board"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CUS
config MACH_OMAP_LDP
bool "OMAP3 LDP board"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
config MACH_OMAP3530_LV_SOM
bool "OMAP3 Logic 3530 LV SOM board"
depends on ARCH_OMAP3
default y
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_PACKAGE_CBB
help
Support for the LogicPD OMAP3530 SOM Development kit
for full description please see the products webpage at
http://www.logicpd.com/products/development-kits/texas-instruments-zoom%E2%84%A2-omap35x-development-kit
config MACH_OMAP3_TORPEDO
bool "OMAP3 Logic 35x Torpedo board"
depends on ARCH_OMAP3
default y
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_PACKAGE_CBB
help
Support for the LogicPD OMAP35x Torpedo Development kit
for full description please see the products webpage at
http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit
config MACH_OVERO
bool "Gumstix Overo board"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
config MACH_OMAP3517EVM
bool "OMAP3517/ AM3517 EVM board"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
config MACH_CRANEBOARD
bool "AM3517/05 CRANE board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
config MACH_OMAP3_PANDORA
bool "OMAP3 Pandora"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
config MACH_TOUCHBOOK
bool "OMAP3 Touch Book"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
config MACH_OMAP_3430SDP
bool "OMAP 3430 SDP board"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
config MACH_NOKIA_N810
bool
config MACH_NOKIA_N810_WIMAX
bool
config MACH_NOKIA_N8X0
bool "Nokia N800/N810"
depends on SOC_OMAP2420
default y
select MACH_NOKIA_N810
select MACH_NOKIA_N810_WIMAX
config MACH_NOKIA_RX51
bool "Nokia N900 (RX-51) phone"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
config MACH_CM_T35
bool "CompuLab CM-T35/CM-T3730 modules"
depends on ARCH_OMAP3
default y
select MACH_CM_T3730
select OMAP_PACKAGE_CUS
config MACH_CM_T3517
bool "CompuLab CM-T3517 module"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
config MACH_CM_T3730
bool
config MACH_SBC3530
bool "OMAP3 SBC STALKER board"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CUS
config MACH_TI8168EVM
bool "TI8168 Evaluation Module"
depends on SOC_TI81XX
default y
config MACH_TI8148EVM
bool "TI8148 Evaluation Module"
depends on SOC_TI81XX
default y
config OMAP3_EMU
bool "OMAP3 debugging peripherals"
depends on ARCH_OMAP3
ARM: OMAP2: select ARM_AMBA if OMAP3_EMU is defined This patch selects ARM_AMBA if OMAP3_EMU is defined because OC_ETM depends on ARM_AMBA, so fix the link failure[1]. [1], arch/arm/kernel/built-in.o: In function `etm_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:409: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etm_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:640: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:646: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:648: undefined reference to `amba_driver_unregister' arch/arm/kernel/built-in.o: In function `etm_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:545: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:595: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:347: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:392: undefined reference to `amba_release_regions' arch/arm/mach-omap2/built-in.o: In function `emu_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:62: undefined reference to `amba_device_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:63: undefined reference to `amba_device_register' make: *** [.tmp_vmlinux1] Error 1 making modules Signed-off-by: Ming Lei <tom.leiming@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-11-24 05:44:50 +07:00
select ARM_AMBA
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-09 06:33:14 +07: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-09 06:33:14 +07: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;
ARM: OMAP4: Fix errata i688 with MPU interconnect barriers. On OMAP4 SOC, intecronnects has many write buffers in the async bridges and they need to be drained before CPU enters into standby state. Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support but OMAP errata i688 (Async Bridge Corruption) needs to be taken care to avoid issues like system freeze, CPU deadlocks, random crashes with register accesses, synchronisation loss on initiators operating on both interconnect port simultaneously. As per the errata, if a data is stalled inside asynchronous bridge because of back pressure, it may be accepted multiple times, creating pointer misalignment that will corrupt next transfers on that data path until next reset of the system (No recovery procedure once the issue is hit, the path remains consistently broken). Async bridge can be found on path between MPU to EMIF and MPU to L3 interconnect. This situation can happen only when the idle is initiated by a Master Request Disconnection (which is trigged by software when executing WFI on CPU). The work-around for this errata needs all the initiators connected through async bridge must ensure that data path is properly drained before issuing WFI. This condition will be met if one Strongly ordered access is performed to the target right before executing the WFI. In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure that there is no synchronisation loss on initiators operating on both interconnect port simultaneously. Thanks to Russell for a tip to conver assembly function to C fuction there by reducing 40 odd lines of code from the patch. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Richard Woodruff <r-woodruff2@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-06-26 08:04:31 +07:00
config OMAP4_ERRATA_I688
bool "OMAP4 errata: Async Bridge Corruption"
depends on (ARCH_OMAP4 || SOC_OMAP5) && !ARCH_MULTIPLATFORM
ARM: OMAP4: Fix errata i688 with MPU interconnect barriers. On OMAP4 SOC, intecronnects has many write buffers in the async bridges and they need to be drained before CPU enters into standby state. Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support but OMAP errata i688 (Async Bridge Corruption) needs to be taken care to avoid issues like system freeze, CPU deadlocks, random crashes with register accesses, synchronisation loss on initiators operating on both interconnect port simultaneously. As per the errata, if a data is stalled inside asynchronous bridge because of back pressure, it may be accepted multiple times, creating pointer misalignment that will corrupt next transfers on that data path until next reset of the system (No recovery procedure once the issue is hit, the path remains consistently broken). Async bridge can be found on path between MPU to EMIF and MPU to L3 interconnect. This situation can happen only when the idle is initiated by a Master Request Disconnection (which is trigged by software when executing WFI on CPU). The work-around for this errata needs all the initiators connected through async bridge must ensure that data path is properly drained before issuing WFI. This condition will be met if one Strongly ordered access is performed to the target right before executing the WFI. In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure that there is no synchronisation loss on initiators operating on both interconnect port simultaneously. Thanks to Russell for a tip to conver assembly function to C fuction there by reducing 40 odd lines of code from the patch. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Richard Woodruff <r-woodruff2@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-06-26 08:04:31 +07:00
select ARCH_HAS_BARRIERS
help
If a data is stalled inside asynchronous bridge because of back
pressure, it may be accepted multiple times, creating pointer
misalignment that will corrupt next transfers on that data path
until next reset of the system (No recovery procedure once the
issue is hit, the path remains consistently broken). Async bridge
can be found on path between MPU to EMIF and MPU to L3 interconnect.
This situation can happen only when the idle is initiated by a
Master Request Disconnection (which is trigged by software when
executing WFI on CPU).
The work-around for this errata needs all the initiators connected
through async bridge must ensure that data path is properly drained
before issuing WFI. This condition will be met if one Strongly ordered
access is performed to the target right before executing the WFI.
In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained.
IO barrier ensure that there is no synchronisation loss on initiators
operating on both interconnect port simultaneously.
endmenu
endif
endmenu