History log of /openbmc/linux/arch/arm/mach-sunxi/Kconfig (Results 1 – 25 of 69)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38
# d421fd6d 08-May-2022 Samuel Holland <samuel@sholland.org>

irqchip: Add Kconfig symbols for sunxi drivers

Not all of these drivers are needed on every ARCH_SUNXI platform. In
particular, the ARCH_SUNXI symbol will be reused for the Allwinner D1,
a RISC-V So

irqchip: Add Kconfig symbols for sunxi drivers

Not all of these drivers are needed on every ARCH_SUNXI platform. In
particular, the ARCH_SUNXI symbol will be reused for the Allwinner D1,
a RISC-V SoC which contains none of these irqchips.

Introduce Kconfig symbols so we can select only the drivers actually
used by a particular set of platforms. This also lets us move the
irqchip driver dependencies to a more appropriate location.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220509034941.30704-1-samuel@sholland.org

show more ...


Revision tags: v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33
# 5d6f5267 04-Apr-2022 Arnd Bergmann <arnd@arndb.de>

ARM: rework endianess selection

Choosing big-endian vs little-endian kernels in Kconfig has not worked
correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long
time ago.

The problems is

ARM: rework endianess selection

Choosing big-endian vs little-endian kernels in Kconfig has not worked
correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long
time ago.

The problems is that CONFIG_BIG_ENDIAN depends on
ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform
in the config, but would actually have to be supported by all
of them.

This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and
tend to just work aside from problems in nonportable device drivers.
For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM
were never set together, so this was disabled on all those machines
except for IXP4xx.

As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to
formalize this logic: all ARMv4/v5 platforms get an explicit dependency
on being either big-endian (ixp4xx) or little-endian (the rest). We may
want to fix ixp4xx in the future to support both, but it does not work
in LE mode at the moment.

For the ARMv6/v7 platforms, there are two ways this could be handled

a) allow both modes only for platforms selecting
'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the
others, given that these were added intentionally at some
point.

b) allow both modes everwhere, given that it was already possible
to build that way by e.g. selecting ARCH_VIRT, and that the
list is not an accurate reflection of which platforms may or
may not work.

Out of these, I picked b) because it seemed slighly more logical
to me.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...


Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14
# 4e346146 17-Jan-2021 Samuel Holland <samuel@sholland.org>

irqchip/sun6i-r: Use a stacked irqchip driver

The R_INTC in the A31 and newer sun8i/sun50i SoCs is more similar to the
original sun4i interrupt controller than the sun7i/sun9i NMI controller.
It is

irqchip/sun6i-r: Use a stacked irqchip driver

The R_INTC in the A31 and newer sun8i/sun50i SoCs is more similar to the
original sun4i interrupt controller than the sun7i/sun9i NMI controller.
It is used for two distinct purposes:
- To control the trigger, latch, and mask for the NMI input pin
- To provide the interrupt input for the ARISC coprocessor

As this interrupt controller is not documented, information about it
comes from vendor-provided firmware blobs and from experimentation.

Differences from the sun4i interrupt controller appear to be:
- It only has one or two registers of each kind (max 32 or 64 IRQs)
- Multiplexing logic is added to support additional inputs
- There is no FIQ-related logic
- There is no interrupt priority logic

In order to fulfill its two purposes, this hardware block combines four
types of IRQs. First, the NMI pin is routed to the "IRQ 0" input on this
chip, with a trigger type controlled by the NMI_CTRL_REG. The "IRQ 0
pending" output from this chip, if enabled, is then routed to a SPI IRQ
input on the GIC. In other words, bit 0 of IRQ_ENABLE_REG *does* affect
the NMI IRQ seen at the GIC.

The NMI is followed by a contiguous block of 15 "direct" (my name for
them) IRQ inputs that are connected in parallel to both R_INTC and the
GIC. Or in other words, these bits of IRQ_ENABLE_REG *do not* affect the
IRQs seen at the GIC.

Following the direct IRQs are the ARISC's copy of banked IRQs for shared
peripherals. These are not relevant to Linux. The remaining IRQs are
connected to a multiplexer and provide access to the first (up to) 128
SPIs from the ARISC. This range of SPIs overlaps with the direct IRQs.

Because of the 1:1 correspondence between R_INTC and GIC inputs, this is
a perfect scenario for using a stacked irqchip driver. We want to hook
into setting the NMI trigger type, but not actually handle any IRQ here.

To allow access to all multiplexed IRQs, this driver requires a new
binding where the interrupt number matches the GIC interrupt number.
(This moves the NMI from number 0 to 32 or 96, depending on the SoC.)
For simplicity, copy the three-cell GIC binding; this disambiguates
interrupt 0 in the old binding (the NMI) from interrupt 0 in the new
binding (SPI 0) by the number of cells.

Since R_INTC is in the always-on power domain, and its output is visible
to the power management coprocessor, a stacked irqchip driver provides a
simple way to add wakeup support to any of its IRQs. That is the next
patch; for now, just the NMI is moved over.

This commit mostly reverts commit 173bda53b340 ("irqchip/sunxi-nmi:
Support sun6i-a31-r-intc compatible").

Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210118055040.21910-4-samuel@sholland.org

show more ...


Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4
# ec8f24b7 19-May-2019 Thomas Gleixner <tglx@linutronix.de>

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


Revision tags: v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7
# ba08dcc8 02-Dec-2018 Mesih Kilinc <mesihkilinc@gmail.com>

ARM: sunxi: add Allwinner ARMv5 SoCs

Add option for Allwinner ARMv5 SoCs and SoC F1C100s (which has a die
used for many new F-series products, including F1C100A, F1C100s, F1C200s,
F1C500, F1C600).

ARM: sunxi: add Allwinner ARMv5 SoCs

Add option for Allwinner ARMv5 SoCs and SoC F1C100s (which has a die
used for many new F-series products, including F1C100A, F1C100s, F1C200s,
F1C500, F1C600).

Signed-off-by: Mesih Kilinc <mesihkilinc@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>

show more ...


# 2391f4ad 02-Dec-2018 Mesih Kilinc <mesihkilinc@gmail.com>

ARM: Check ARCH_MULTI_V7 to differentiate ARMv5/v7 Allwinner SoCs

Allwinner also has some ARMv5 SoCs.

In order to add support for them, check ARM_MULTI_V7 before enabling
ARMv7 SoC's. Add help text

ARM: Check ARCH_MULTI_V7 to differentiate ARMv5/v7 Allwinner SoCs

Allwinner also has some ARMv5 SoCs.

In order to add support for them, check ARM_MULTI_V7 before enabling
ARMv7 SoC's. Add help text for ARCH_SUNXI menuconfig.

Signed-off-by: Mesih Kilinc <mesihkilinc@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>

show more ...


Revision tags: v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17
# 6961275e 04-May-2018 Mylène Josserand <mylene.josserand@bootlin.com>

ARM: sun8i: smp: Add support for A83T

Add the support for A83T.

A83T SoC has an additional register than A80 to handle CPU configurations:
R_CPUS_CFG. Information about the register comes from Allw

ARM: sun8i: smp: Add support for A83T

Add the support for A83T.

A83T SoC has an additional register than A80 to handle CPU configurations:
R_CPUS_CFG. Information about the register comes from Allwinner's BSP
driver.
An important difference is the Power Off Gating register for clusters
which is BIT(4) in case of SUN9I-A80 and BIT(0) in case of SUN8I-A83T.
There is also a bit swap between sun8i-a83t and sun9i-a80 that must be
handled.

Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>

show more ...


Revision tags: v4.16, v4.15
# 745373e3 17-Jan-2018 Chen-Yu Tsai <wens@csie.org>

ARM: sun9i: Support SMP bring-up on A80

The A80 is a big.LITTLE SoC with 1 cluster of 4 Cortex-A7s and
1 cluster of 4 Cortex-A15s.

This patch adds support to bring up the second cluster and thus al

ARM: sun9i: Support SMP bring-up on A80

The A80 is a big.LITTLE SoC with 1 cluster of 4 Cortex-A7s and
1 cluster of 4 Cortex-A15s.

This patch adds support to bring up the second cluster and thus all
cores using custom platform SMP code. Core/cluster power down has not
been implemented, thus CPU hotplugging is not supported.

Parts of the trampoline and re-entry code for the boot cpu was adapted
from the MCPM framework.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>

show more ...


Revision tags: v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10
# 202fc71b 09-Feb-2017 Maxime Ripard <maxime.ripard@free-electrons.com>

ARM: sunxi: Select PM_OPP

Device frequency scaling is implemented through devfreq in the kernel,
which requires CONFIG_PM_OPP.

Let's select it.

Signed-off-by: Maxime Ripard <maxime.ripard@free-ele

ARM: sunxi: Select PM_OPP

Device frequency scaling is implemented through devfreq in the kernel,
which requires CONFIG_PM_OPP.

Let's select it.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


Revision tags: v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20
# 3515c1bb 22-Aug-2016 Michael Weiser <michael.weiser@gmx.de>

ARM: sunxi: enable big-endian

With previous fixes to stmmac, sun4i-emac and sun4i-mmc at least the
Cubieboard2 incarnation of sunxi works correctly in big-endian mode.
Allow the selection of big-end

ARM: sunxi: enable big-endian

With previous fixes to stmmac, sun4i-emac and sun4i-mmc at least the
Cubieboard2 incarnation of sunxi works correctly in big-endian mode.
Allow the selection of big-endian.

Tested using a Cubieboard2 DualCard and the following
hardware-components:
- GMAC (stmmac)
- EMAC (sun4i-emac)
- SATA
- SPI
- UART
- security system
- touchscreen controller hwmon functionality
- pinctrl (custom interrupt for SPI ethernet controller)
- watchdog as reset controller
- onboard RTC
- DS1307 I2C RTC
- sound codec and with this indirectly the DMA engine

Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


Revision tags: v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1
# 5c34a4e8 02-Jun-2016 Linus Walleij <linus.walleij@linaro.org>

ARM: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB

This replaces:

- "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB" as this can
now be selected directly.

- "select ARCH_WANT_OPTIONAL_GPI

ARM: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB

This replaces:

- "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB" as this can
now be selected directly.

- "select ARCH_WANT_OPTIONAL_GPIOLIB" with no dependency: GPIOLIB
is now selectable by everyone, so we need not declare our
intent to select it.

When ordering the symbols the following rationale was used:
if the selects were in alphabetical order, I moved select GPIOLIB
to be in alphabetical order, but if the selects were not
maintained in alphabetical order, I just replaced
"select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB".

Cc: Michael Büsch <m@bues.ch>
Cc: arm@kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>

show more ...


Revision tags: v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1
# e3246542 15-Nov-2015 Masahiro Yamada <yamada.masahiro@socionext.com>

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

co

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>

show more ...


Revision tags: openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4
# 14a882df 15-May-2015 Jens Kuske <jenskuske@gmail.com>

ARM: sunxi: Introduce Allwinner H3 support

The Allwinner H3 is a quad-core Cortex-A7-based SoC. It is very similar
to other sun8i family SoCs like the A23.

Signed-off-by: Jens Kuske <jenskuske@gmai

ARM: sunxi: Introduce Allwinner H3 support

The Allwinner H3 is a quad-core Cortex-A7-based SoC. It is very similar
to other sun8i family SoCs like the A23.

Signed-off-by: Jens Kuske <jenskuske@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


Revision tags: v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1
# fdc0074c 09-Feb-2015 Chen-Yu Tsai <wens@csie.org>

ARM: sunxi: Have ARCH_SUNXI select RESET_CONTROLLER for clock driver usage

As the sunxi usb clocks all contain a reset controller, it is not
possible to build the sunxi clock driver without RESET_CO

ARM: sunxi: Have ARCH_SUNXI select RESET_CONTROLLER for clock driver usage

As the sunxi usb clocks all contain a reset controller, it is not
possible to build the sunxi clock driver without RESET_CONTROLLER
enabled. Doing so results in an undefined symbol error:

drivers/built-in.o: In function `sunxi_gates_clk_setup':
linux/drivers/clk/sunxi/clk-sunxi.c:1071: undefined reference to
`reset_controller_register'

This is possible if building a minimal kernel without PHY_SUN4I_USB.

The dependency issue is made visible at compile time instead of
link time by the new A80 mmc clocks, which also use a reset control
itself.

This patch makes ARCH_SUNXI select ARCH_HAS_RESET_CONTROLLER and
RESET_CONTROLLER.

Fixes: 559482d1f950 ARM: sunxi: Split the various SoCs support in Kconfig
Cc: <stable@vger.kernel.org> # 3.16+
Reported-by: Lourens Rozema <ik@lourensrozema.nl>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


Revision tags: v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1
# 2f4bc734 12-Oct-2014 Chen-Yu Tsai <wens@csie.org>

ARM: sunxi: Select ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER for sun9i

The A80 SoC has reset controls matching bus clock gates.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxim

ARM: sunxi: Select ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER for sun9i

The A80 SoC has reset controls matching bus clock gates.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


# 3d4c2f1c 08-Oct-2014 Chen-Yu Tsai <wens@csie.org>

ARM: sunxi: Introduce Allwinner A80 support

The Allwinner A80 is a new Cortex octo-core A7/A15 big.LITTLE SoC.
While it's processor cores and interconnecting bus are new, it
re-uses many peripherals

ARM: sunxi: Introduce Allwinner A80 support

The Allwinner A80 is a new Cortex octo-core A7/A15 big.LITTLE SoC.
While it's processor cores and interconnecting bus are new, it
re-uses many peripherals found in earlier Allwinner SoCs.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Andreas Färber <afaerber@suse.de>

show more ...


Revision tags: v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3
# d9ff081d 29-Jun-2014 Maxime Ripard <maxime.ripard@free-electrons.com>

pinctrl: sunxi: Remove PINCTRL_SUNXI

The PINCTRL_SUNXI configuration was kept only to deal with the introduction of
per-machine symbols and the various pintrl drivers through different tree.

Now th

pinctrl: sunxi: Remove PINCTRL_SUNXI

The PINCTRL_SUNXI configuration was kept only to deal with the introduction of
per-machine symbols and the various pintrl drivers through different tree.

Now that it's not useful anymore, we can just remove it.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

show more ...


# 5ba1657e 03-Jul-2014 Chen-Yu Tsai <wens@csie.org>

ARM: sunxi: select MFD_SUN6I_PRCM when sun8i arch support is enabled

Select the MFD_SUN6I_PRCM option when sun8i arch is enabled in order to
get the PRCM (Power/Reset/Clock Management) related drive

ARM: sunxi: select MFD_SUN6I_PRCM when sun8i arch support is enabled

Select the MFD_SUN6I_PRCM option when sun8i arch is enabled in order to
get the PRCM (Power/Reset/Clock Management) related drivers compiled.

Also select ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER to make sure
the reset controller drivers are compiled.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


Revision tags: v3.16-rc2
# ac84b79f 20-Jun-2014 Chen-Yu Tsai <wens@csie.org>

ARM: sunxi: Introduce Allwinner A23 support

The Allwinner A23 is a dual-core Cortex-A7-based SoC. It re-uses most of
the IPs found in previous SoCs, notably the A31.

Signed-off-by: Chen-Yu Tsai <we

ARM: sunxi: Introduce Allwinner A23 support

The Allwinner A23 is a dual-core Cortex-A7-based SoC. It re-uses most of
the IPs found in previous SoCs, notably the A31.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


Revision tags: v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6
# 324da938 15-May-2014 Boris BREZILLON <boris.brezillon@free-electrons.com>

ARM: sunxi: select MFD_SUN6I_PRCM when sun6i arch support is enabled

Select the MFD_SUN6I_PRCM option when sun6i arch is enabled in order to get
the PRCM (Power/Reset/Clock Management) related drive

ARM: sunxi: select MFD_SUN6I_PRCM when sun6i arch support is enabled

Select the MFD_SUN6I_PRCM option when sun6i arch is enabled in order to get
the PRCM (Power/Reset/Clock Management) related drivers compiled.

Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


Revision tags: v3.15-rc5, v3.15-rc4
# 559482d1 28-Apr-2014 Maxime Ripard <maxime.ripard@free-electrons.com>

ARM: sunxi: Split the various SoCs support in Kconfig

This will allow to better isolate various options, and reduce the overall
kernel size if we're interested in only one of the SoCs.

Signed-off-b

ARM: sunxi: Split the various SoCs support in Kconfig

This will allow to better isolate various options, and reduce the overall
kernel size if we're interested in only one of the SoCs.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


Revision tags: v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14
# 9233087d 27-Mar-2014 Maxime Ripard <maxime.ripard@free-electrons.com>

ARM: sunxi: Select HAVE_ARM_ARCH_TIMER

In order for the architected timers support to be enabled in the kernel, this
option has to be enabled. Otherwise, the architected timers driver won't be
compi

ARM: sunxi: Select HAVE_ARM_ARCH_TIMER

In order for the architected timers support to be enabled in the kernel, this
option has to be enabled. Otherwise, the architected timers driver won't be
compiled in, and we will not get to use them.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>

show more ...


Revision tags: v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1
# 90bc8ac7 31-Jan-2014 Rob Herring <robh@kernel.org>

ARM: select HAVE_SMP for V7 multi-platform

All V7 platforms can run SMP kernels, so make CONFIG_SMP visible for V7
multi-platform builds.

Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Step

ARM: select HAVE_SMP for V7 multi-platform

All V7 platforms can run SMP kernels, so make CONFIG_SMP visible for V7
multi-platform builds.

Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>

show more ...


Revision tags: v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1
# ddb902cc 22-Nov-2013 Rob Herring <robh@kernel.org>

ARM: centralize common multi-platform kconfig options

Multi-platform requires various kconfig options to be selected, so
platforms don't need to select them individually.

Signed-off-by: Rob Herring

ARM: centralize common multi-platform kconfig options

Multi-platform requires various kconfig options to be selected, so
platforms don't need to select them individually.

Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>

show more ...


# 75cac6ab 01-Jan-2014 Zalan Blenessy <zalan.blenessy@gmail.com>

ARM: sunxi: select ARM_PSCI

On Allwinner sun7i (A20) SoCs, the SMP operations are implemented in
u-boot, and exposed to the kernel through PSCI.

We thus need to enable PSCI support for Allwinner So

ARM: sunxi: select ARM_PSCI

On Allwinner sun7i (A20) SoCs, the SMP operations are implemented in
u-boot, and exposed to the kernel through PSCI.

We thus need to enable PSCI support for Allwinner SoCs so that the
kernel uses it to bring up the additionnal cores.

Signed-off-by: Signed-off-by: Zalan Blenessy <zalan.blenessy@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

show more ...


123