openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
linux/arch/arm/mach-picoxcell/Kconfig

9 lines
183 B
Plaintext
Raw Normal View History

ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-07 02:41:12 +08:00
config ARCH_PICOXCELL
ARM: use "depends on" for SoC configs instead of "if" after prompt Many ARM sub-architectures use prompts followed by "if" conditional, but it is wrong. Please notice the difference between config ARCH_FOO bool "Foo SoCs" if ARCH_MULTI_V7 and config ARCH_FOO bool "Foo SoCs" depends on ARCH_MULTI_V7 These two are *not* equivalent! In the former statement, it is not ARCH_FOO, but its prompt that depends on ARCH_MULTI_V7. So, it is completely valid that ARCH_FOO is selected by another, but ARCH_MULTI_V7 is still disabled. As it is not unmet dependency, Kconfig never warns. This is probably not what you want. The former should be used only when you need to do so, and you really understand what you are doing. (In most cases, it should be wrong!) For enabling/disabling sub-architectures, the latter is always correct. As a good side effect, this commit fixes some entries over 80 columns (mach-imx, mach-integrator, mach-mbevu). [Arnd: I note that there is not really a bug here, according to the discussion that followed, but I can see value in being consistent and in making the lines shorter] Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Patrice Chotard <patrice.chotard@st.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Jun Nie <jun.nie@linaro.org> Acked-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Krzysztof Halasa <khc@piap.pl> Acked-by: Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-11-16 11:06:10 +08:00
bool "Picochip PicoXcell"
depends on ARCH_MULTI_V6
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-07 02:41:12 +08:00
select ARCH_REQUIRE_GPIOLIB
select ARM_VIC
select DW_APB_TIMER_OF
select HAVE_TCM
Kconfig: rename HAS_IOPORT to HAS_IOPORT_MAP If the renamed symbol is defined lib/iomap.c implements ioport_map and ioport_unmap and currently (nearly) all platforms define the port accessor functions outb/inb and friend unconditionally. So HAS_IOPORT_MAP is the better name for this. Consequently NO_IOPORT is renamed to NO_IOPORT_MAP. The motivation for this change is to reintroduce a symbol HAS_IOPORT that signals if outb/int et al are available. I will address that at least one merge window later though to keep surprises to a minimum and catch new introductions of (HAS|NO)_IOPORT. The changes in this commit were done using: $ git grep -l -E '(NO|HAS)_IOPORT' | xargs perl -p -i -e 's/\b((?:CONFIG_)?(?:NO|HAS)_IOPORT)\b/$1_MAP/' Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-08 06:39:19 +08:00
select NO_IOPORT_MAP