linux/arch/arm/mach-shmobile/Kconfig

103 lines
1.8 KiB
Plaintext
Raw Normal View History

config ARCH_SHMOBILE
bool
config ARCH_SHMOBILE_MULTI
bool
config PM_RMOBILE
bool
select PM
select PM_GENERIC_DOMAINS
config ARCH_RCAR_GEN1
bool
select PM
select PM_GENERIC_DOMAINS
select RENESAS_INTC_IRQPIN
select SYS_SUPPORTS_SH_TMU
config ARCH_RCAR_GEN2
bool
select PM
select PM_GENERIC_DOMAINS
select RENESAS_IRQC
select SYS_SUPPORTS_SH_CMT
select PCI_DOMAINS if PCI
config ARCH_RMOBILE
bool
select PM_RMOBILE
select SYS_SUPPORTS_SH_CMT
select SYS_SUPPORTS_SH_TMU
menuconfig ARCH_RENESAS
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 "Renesas ARM SoCs"
depends on ARCH_MULTI_V7 && MMU
select ARCH_SHMOBILE
select ARCH_SHMOBILE_MULTI
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select ARM_GIC
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select NO_IOPORT_MAP
select PINCTRL
select ARCH_REQUIRE_GPIOLIB
select ZONE_DMA if ARM_LPAE
if ARCH_RENESAS
#comment "Renesas ARM SoCs System Type"
config ARCH_EMEV2
bool "Emma Mobile EV2"
select SYS_SUPPORTS_EM_STI
config ARCH_R7S72100
bool "RZ/A1H (R7S72100)"
select PM
select PM_GENERIC_DOMAINS
select SYS_SUPPORTS_SH_MTU2
config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
select ARCH_RMOBILE
select RENESAS_IRQC
config ARCH_R8A7740
bool "R-Mobile A1 (R8A77400)"
select ARCH_RMOBILE
select RENESAS_INTC_IRQPIN
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
select ARCH_RCAR_GEN1
config ARCH_R8A7790
bool "R-Car H2 (R8A77900)"
select ARCH_RCAR_GEN2
ARM: shmobile: R-Car Gen2: Add da9063/da9210 regulator quirk The r8a7790/lager and r8a7791/koelsch development boards have da9063 and da9210 regulators. Both regulators have their interrupt request lines tied to the same interrupt pin (IRQ2) on the SoC. After cold boot or da9063-induced restart, both the da9063 and da9210 seem to assert their interrupt request lines. Hence as soon as one driver requests this irq, it gets stuck in an interrupt storm, as it only manages to deassert its own interrupt request line, and the other driver hasn't installed an interrupt handler yet. To handle this, install a quirk that masks the interrupts in both the da9063 and da9210. This quirk has to run after the i2c master driver has been initialized, but before the i2c slave drivers are initialized. As it depends on i2c, select I2C if one of the affected platforms is enabled in the kernel config. On koelsch, the following happens: - Cold boot or reboot using the da9063 restart handler: IRQ2 is asserted, installing da9063/da9210 regulator quirk ... i2c i2c-6: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb i2c 6-0058: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb i2c 6-0058: Detected da9063 i2c 6-0058: Masking da9063 interrupt sources i2c 6-0068: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb i2c 6-0068: Detected da9210 i2c 6-0068: Masking da9210 interrupt sources i2c 6-0068: IRQ2 is not asserted, removing quirk - Warm boot (reset button): rcar_gen2_regulator_quirk: IRQ2 is not asserted, not installing quirk Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2015-03-10 03:50:40 +08:00
select I2C
config ARCH_R8A7791
bool "R-Car M2-W (R8A77910)"
select ARCH_RCAR_GEN2
ARM: shmobile: R-Car Gen2: Add da9063/da9210 regulator quirk The r8a7790/lager and r8a7791/koelsch development boards have da9063 and da9210 regulators. Both regulators have their interrupt request lines tied to the same interrupt pin (IRQ2) on the SoC. After cold boot or da9063-induced restart, both the da9063 and da9210 seem to assert their interrupt request lines. Hence as soon as one driver requests this irq, it gets stuck in an interrupt storm, as it only manages to deassert its own interrupt request line, and the other driver hasn't installed an interrupt handler yet. To handle this, install a quirk that masks the interrupts in both the da9063 and da9210. This quirk has to run after the i2c master driver has been initialized, but before the i2c slave drivers are initialized. As it depends on i2c, select I2C if one of the affected platforms is enabled in the kernel config. On koelsch, the following happens: - Cold boot or reboot using the da9063 restart handler: IRQ2 is asserted, installing da9063/da9210 regulator quirk ... i2c i2c-6: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb i2c 6-0058: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb i2c 6-0058: Detected da9063 i2c 6-0058: Masking da9063 interrupt sources i2c 6-0068: regulator_quirk_notify: 1, IRQC_MONITOR = 0x3fb i2c 6-0068: Detected da9210 i2c 6-0068: Masking da9210 interrupt sources i2c 6-0068: IRQ2 is not asserted, removing quirk - Warm boot (reset button): rcar_gen2_regulator_quirk: IRQ2 is not asserted, not installing quirk Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2015-03-10 03:50:40 +08:00
select I2C
config ARCH_R8A7793
bool "R-Car M2-N (R8A7793)"
select ARCH_RCAR_GEN2
select I2C
config ARCH_R8A7794
bool "R-Car E2 (R8A77940)"
select ARCH_RCAR_GEN2
config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
select RENESAS_INTC_IRQPIN
endif