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 |
|
#
4e486a65 |
| 01-May-2023 |
Artur Weber <aweber.kernel@gmail.com> |
ARM: exynos: Re-introduce Exynos4212 support
Support for the Exynos4212 SoC was originally dropped as there were no boards using it. We will be adding a device that uses it, so add back the relevant
ARM: exynos: Re-introduce Exynos4212 support
Support for the Exynos4212 SoC was originally dropped as there were no boards using it. We will be adding a device that uses it, so add back the relevant code.
This reverts commit 9e43eca3c87476f75680f472ff3ebcd85f357b86.
Signed-off-by: Artur Weber <aweber.kernel@gmail.com> Link: https://lore.kernel.org/r/20230501195525.6268-4-aweber.kernel@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
Revision tags: 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, v5.15.37, v5.15.36 |
|
#
ac875df4 |
| 20-Apr-2022 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos config
The Samsung pinctrl drivers depend on OF_GPIO, which is part of GPIOLIB. ARMv7 Exynos platform selects GPIOLIB and Samsung pinctrl driver
pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos config
The Samsung pinctrl drivers depend on OF_GPIO, which is part of GPIOLIB. ARMv7 Exynos platform selects GPIOLIB and Samsung pinctrl drivers. ARMv8 Exynos selects only the latter leading to possible wrong configuration on ARMv8 build:
WARNING: unmet direct dependencies detected for PINCTRL_EXYNOS Depends on [n]: PINCTRL [=y] && OF_GPIO [=n] && (ARCH_EXYNOS [=y] || ARCH_S5PV210 || COMPILE_TEST [=y]) Selected by [y]: - ARCH_EXYNOS [=y]
Always select the GPIOLIB from the Samsung pinctrl drivers to fix the issue. This requires removing of OF_GPIO dependency (to avoid recursive dependency), so add dependency on OF for COMPILE_TEST cases.
Reported-by: Necip Fazil Yildiran <fazilyildiran@gmail.com> Fixes: eed6b3eb20b9 ("arm64: Split out platform options to separate Kconfig") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220420141407.470955-1-krzysztof.kozlowski@linaro.org
show more ...
|
Revision tags: 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 |
|
#
3ac5f9db |
| 21-Nov-2021 |
Sam Protsenko <semen.protsenko@linaro.org> |
ARM: samsung: Remove HAVE_S3C2410_I2C and use direct dependencies
A separate Kconfig option HAVE_S3C2410_I2C for Samsung SoCs is not really needed and the i2c-s3c24xx driver can depend on Samsung AR
ARM: samsung: Remove HAVE_S3C2410_I2C and use direct dependencies
A separate Kconfig option HAVE_S3C2410_I2C for Samsung SoCs is not really needed and the i2c-s3c24xx driver can depend on Samsung ARM architectures instead. This also enables i2c-s3c2410 for arm64 Exynos SoCs, which is required for example by Exynos850.
This is basically continuation of work made in following commits: - commit d96890fca9fd ("rtc: s3c: remove HAVE_S3C_RTC in favor of direct dependencies") - commit 7dd3cae90d85 ("ARM: samsung: remove HAVE_S3C2410_WATCHDOG and use direct dependencies")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20211121150558.21801-2-semen.protsenko@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
show more ...
|
Revision tags: v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13 |
|
#
d96890fc |
| 13-Oct-2021 |
Will McVicker <willmcvicker@google.com> |
rtc: s3c: remove HAVE_S3C_RTC in favor of direct dependencies
The config HAVE_S3C_RTC is not really needed since we can simply just add the dependencies directly to RTC_DRV_S3C. Also, one less confi
rtc: s3c: remove HAVE_S3C_RTC in favor of direct dependencies
The config HAVE_S3C_RTC is not really needed since we can simply just add the dependencies directly to RTC_DRV_S3C. Also, one less config to keep track of!
Signed-off-by: Will McVicker <willmcvicker@google.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211013212256.3425889-1-willmcvicker@google.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
show more ...
|
Revision tags: v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7 |
|
#
140bbfe7 |
| 19-Sep-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
soc: samsung: exynos-chipid: do not enforce built-in
After converting the Exynos ChipID and ASV driver to a module, allow to actually choose it to be a module, while being a default built-in. The s
soc: samsung: exynos-chipid: do not enforce built-in
After converting the Exynos ChipID and ASV driver to a module, allow to actually choose it to be a module, while being a default built-in. The side effect is that driver could be now entirely disabled even for kernel with ARCH_EXYNOS, but this is not a critical issue because driver is not necessary for the proper platform boot.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Sylwester Nawrocki <snawrocki@kernel.org> Tested-by: Sylwester Nawrocki <snawrocki@kernel.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Tested-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20210919093114.35987-4-krzysztof.kozlowski@canonical.com
show more ...
|
#
41dee183 |
| 20-Apr-2022 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos config
commit ac875df4d854ab13d9c4af682a1837a1214fecec upstream.
The Samsung pinctrl drivers depend on OF_GPIO, which is part of GPIOLIB. ARMv7
pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos config
commit ac875df4d854ab13d9c4af682a1837a1214fecec upstream.
The Samsung pinctrl drivers depend on OF_GPIO, which is part of GPIOLIB. ARMv7 Exynos platform selects GPIOLIB and Samsung pinctrl drivers. ARMv8 Exynos selects only the latter leading to possible wrong configuration on ARMv8 build:
WARNING: unmet direct dependencies detected for PINCTRL_EXYNOS Depends on [n]: PINCTRL [=y] && OF_GPIO [=n] && (ARCH_EXYNOS [=y] || ARCH_S5PV210 || COMPILE_TEST [=y]) Selected by [y]: - ARCH_EXYNOS [=y]
Always select the GPIOLIB from the Samsung pinctrl drivers to fix the issue. This requires removing of OF_GPIO dependency (to avoid recursive dependency), so add dependency on OF for COMPILE_TEST cases.
Reported-by: Necip Fazil Yildiran <fazilyildiran@gmail.com> Fixes: eed6b3eb20b9 ("arm64: Split out platform options to separate Kconfig") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220420141407.470955-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: 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, v5.10 |
|
#
352bfbb3 |
| 07-Dec-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv
The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other driv
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv
The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early.
The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID.
The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it.
This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure.
Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features.
2. Allows to use dev_info() as the SoC bus is present (since core_initcall).
3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices.
5. Makes the Chip ID code defer-probe friendly,
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
show more ...
|
#
5e545df3 |
| 14-Dec-2020 |
Mike Rapoport <rppt@linux.ibm.com> |
arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
ARM is the only architecture that defines CONFIG_ARCH_HAS_HOLES_MEMORYMODEL which in turn enables memmap_valid_within() function that is intended to ver
arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
ARM is the only architecture that defines CONFIG_ARCH_HAS_HOLES_MEMORYMODEL which in turn enables memmap_valid_within() function that is intended to verify existence of struct page associated with a pfn when there are holes in the memory map.
However, the ARCH_HAS_HOLES_MEMORYMODEL also enables HAVE_ARCH_PFN_VALID and arch-specific pfn_valid() implementation that also deals with the holes in the memory map.
The only two users of memmap_valid_within() call this function after a call to pfn_valid() so the memmap_valid_within() check becomes redundant.
Remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL and memmap_valid_within() and rely entirely on ARM's implementation of pfn_valid() that is now enabled unconditionally.
Link: https://lkml.kernel.org/r/20201101170454.9567-9-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matt Turner <mattst88@gmail.com> Cc: Meelis Roos <mroos@linux.ee> Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Tony Luck <tony.luck@intel.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: 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 |
|
#
7dd3cae9 |
| 04-Aug-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
ARM: samsung: remove HAVE_S3C2410_WATCHDOG and use direct dependencies
A separate Kconfig option HAVE_S3C2410_WATCHDOG for Samsung SoCs is not really needed and the s3c24xx watchdog driver can depen
ARM: samsung: remove HAVE_S3C2410_WATCHDOG and use direct dependencies
A separate Kconfig option HAVE_S3C2410_WATCHDOG for Samsung SoCs is not really needed and the s3c24xx watchdog driver can depend on Samsung ARM architectures instead.
The "HAVE_xxx_WATCHDOG" pattern of dependency is not popular and Samsung platforms are here exceptions. All others just depend on CONFIG_ARCH_xxx.
This makes the code slightly smaller without any change in functionality.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net>
show more ...
|
Revision tags: v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53 |
|
#
00067ca5 |
| 21-Jul-2020 |
Marek Szyprowski <m.szyprowski@samsung.com> |
soc: samsung: exynos-regulator-coupler: Add simple voltage coupler for Exynos5800
Add a simple custom voltage regulator coupler for Exynos5800 SoCs, which require coupling between "vdd_arm" and "vdd
soc: samsung: exynos-regulator-coupler: Add simple voltage coupler for Exynos5800
Add a simple custom voltage regulator coupler for Exynos5800 SoCs, which require coupling between "vdd_arm" and "vdd_int" regulators. This coupler ensures that the voltage values don't go below the bootloader-selected operation point during the boot process until the clients set their constraints. It is achieved by assuming minimal voltage value equal to the current value if no constraints are set. This also ensures proper voltage balancing if any of the client driver is missing.
The balancing code comes from the regulator/core.c with the additional logic for handling regulators without client constraints applied added.
Link: https://lore.kernel.org/r/20200721180900.13844-5-krzk@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: 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 |
|
#
8a90a322 |
| 24-Jan-2020 |
Marc Zyngier <maz@kernel.org> |
arm: Unplug KVM from the build system
As we're about to drop KVM/arm on the floor, carefully unplug it from the build system.
Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Olof Johansson <
arm: Unplug KVM from the build system
As we're about to drop KVM/arm on the floor, carefully unplug it from the build system.
Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Will Deacon <will@kernel.org> Acked-by: Vladimir Murzin <vladimir.murzin@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
show more ...
|
Revision tags: v5.4.14 |
|
#
21829ec3 |
| 21-Jan-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
ARM: exynos: Drop unneeded select of MIGHT_HAVE_CACHE_L2X0
Support for Samsung Exynos SoCs depends on ARCH_MULTI_V7, which selects ARCH_MULTI_V6_V7. As the latter selects MIGHT_HAVE_CACHE_L2X0, ther
ARM: exynos: Drop unneeded select of MIGHT_HAVE_CACHE_L2X0
Support for Samsung Exynos SoCs depends on ARCH_MULTI_V7, which selects ARCH_MULTI_V6_V7. As the latter selects MIGHT_HAVE_CACHE_L2X0, there is no need for ARCH_EXYNOS4 to select MIGHT_HAVE_CACHE_L2X0.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
Revision tags: v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7 |
|
#
b74416db |
| 24-Dec-2019 |
Hyunki Koo <hyunki00.koo@samsung.com> |
irqchip: Define EXYNOS_IRQ_COMBINER
This patch is written to clean up dependency of ARCH_EXYNOS Not all exynos device have IRQ_COMBINER, especially aarch64 EXYNOS but it is built for all exynos devi
irqchip: Define EXYNOS_IRQ_COMBINER
This patch is written to clean up dependency of ARCH_EXYNOS Not all exynos device have IRQ_COMBINER, especially aarch64 EXYNOS but it is built for all exynos devices. Thus add the config for EXYNOS_IRQ_COMBINER remove direct dependency between ARCH_EXYNOS and exynos-combiner.c and only selected on the aarch32 devices
Signed-off-by: Hyunki Koo <hyunki00.koo@samsung.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20191224211108.7128-1-hyunki00.koo@gmail.com
show more ...
|
#
45984f0c |
| 04-Jan-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
ARM: samsung: Rename Samsung and Exynos to lowercase
Fix up inconsistent usage of upper and lowercase letters in "Samsung" and "Exynos" names.
"SAMSUNG" and "EXYNOS" are not abbreviations but regul
ARM: samsung: Rename Samsung and Exynos to lowercase
Fix up inconsistent usage of upper and lowercase letters in "Samsung" and "Exynos" names.
"SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked names. Therefore they should be written with lowercase letters starting with capital letter.
The lowercase "Exynos" name is promoted by its manufacturer Samsung Electronics Co., Ltd., in advertisement materials and on website.
Although advertisement materials usually use uppercase "SAMSUNG", the lowercase version is used in all legal aspects (e.g. on Wikipedia and in privacy/legal statements on https://www.samsung.com/semiconductor/privacy-global/).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
#
ad097ab0 |
| 03-Jan-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
ARM: exynos: Correct the help text for platform Kconfig option
ARCH_EXYNOS option is used for entire ARMv7 Exynos family, including also Exynos3 SoCs.
Signed-off-by: Krzysztof Kozlowski <krzk@kerne
ARM: exynos: Correct the help text for platform Kconfig option
ARCH_EXYNOS option is used for entire ARMv7 Exynos family, including also Exynos3 SoCs.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
Revision tags: 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 |
|
#
4134b762 |
| 28-Oct-2019 |
Sylwester Nawrocki <s.nawrocki@samsung.com> |
ARM: exynos: Enable exynos-asv driver for ARCH_EXYNOS
Enable exynos-asv driver for Exynos 32-bit SoCs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski
ARM: exynos: Enable exynos-asv driver for ARCH_EXYNOS
Enable exynos-asv driver for Exynos 32-bit SoCs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
Revision tags: 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 |
|
#
13aeb3fe |
| 28-Aug-2019 |
Marek Szyprowski <m.szyprowski@samsung.com> |
ARM: exynos: Enable support for ARM architected timers
ARM architected timer can be used together with Exynos MultiCore Timer driver, so enable support for it. Support for ARM architected timers is
ARM: exynos: Enable support for ARM architected timers
ARM architected timer can be used together with Exynos MultiCore Timer driver, so enable support for it. Support for ARM architected timers is essential for enabling proper KVM support.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
Revision tags: v5.2.10, v5.2.9 |
|
#
1fa70c7f |
| 13-Aug-2019 |
Pankaj Dubey <pankaj.dubey@samsung.com> |
ARM: exynos: Enable exynos-chipid driver
As now we have Chipid driver to initialize and expose SoC related information let's include it in build by default.
Signed-off-by: Pankaj Dubey <pankaj.dube
ARM: exynos: Enable exynos-chipid driver
As now we have Chipid driver to initialize and expose SoC related information let's include it in build by default.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
Revision tags: 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 |
|
#
24d2c73f |
| 19-Jun-2019 |
Arnd Bergmann <arnd@arndb.de> |
ARM: exynos: Only build MCPM support if used
We get a link error for configurations that enable an Exynos SoC that does not require MCPM, but then manually enable MCPM anyway without also turning on
ARM: exynos: Only build MCPM support if used
We get a link error for configurations that enable an Exynos SoC that does not require MCPM, but then manually enable MCPM anyway without also turning on the arm-cci:
arch/arm/mach-exynos/mcpm-exynos.o: In function `exynos_pm_power_up_setup': mcpm-exynos.c:(.text+0x8): undefined reference to `cci_enable_port_for_self'
Change it back to only build the code we actually need, by introducing a CONFIG_EXYNOS_MCPM that serves the same purpose as the older CONFIG_EXYNOS5420_MCPM.
Fixes: 2997520c2d4e ("ARM: exynos: Set MCPM as mandatory for Exynos542x/5800 SoCs") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
Revision tags: 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, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11 |
|
#
0cca82ec |
| 29-Apr-2019 |
Krzysztof Kozlowski <krzk@kernel.org> |
ARM: exynos: Make ARCH_EXYNOS3 a default option
By default for ARMv7 Exynos platform we select all flavors. One kernel image simplifies testing and maintenance. However Exynos3 was not selected by
ARM: exynos: Make ARCH_EXYNOS3 a default option
By default for ARMv7 Exynos platform we select all flavors. One kernel image simplifies testing and maintenance. However Exynos3 was not selected by default so far (thus it was not present in multi_v7 kernel).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
Revision tags: v5.0.10, v5.0.9, v5.0.8 |
|
#
2997520c |
| 09-Apr-2019 |
Marek Szyprowski <m.szyprowski@samsung.com> |
ARM: exynos: Set MCPM as mandatory for Exynos542x/5800 SoCs
Support for Exynos5420/5422/5800 SoCs requires MCPM to properly boot all CPU cores on all currectly supported platforms: Peach Pit (Exynos
ARM: exynos: Set MCPM as mandatory for Exynos542x/5800 SoCs
Support for Exynos5420/5422/5800 SoCs requires MCPM to properly boot all CPU cores on all currectly supported platforms: Peach Pit (Exynos5420), Odroid XU3/XU3lite/XU4/HC1 (Exynos5422) and Peach Pi (Exynos5800). Without it some CPU cores fail to come online. Remove then the ability to disable MCPM and make it mandatory when Exynos542x/5800 support is enabled.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
Revision tags: 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, 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 |
|
#
4965a687 |
| 03-Apr-2018 |
Christoph Hellwig <hch@lst.de> |
arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig
Define this symbol if the architecture either uses 64-bit pointers or the PHYS_ADDR_T_64BIT is set. This covers 95% of the old ar
arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig
Define this symbol if the architecture either uses 64-bit pointers or the PHYS_ADDR_T_64BIT is set. This covers 95% of the old arch magic. We only need an additional select for Xen on ARM (why anyway?), and we now always set ARCH_DMA_ADDR_T_64BIT on mips boards with 64-bit physical addressing instead of only doing it when highmem is set.
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: James Hogan <jhogan@kernel.org>
show more ...
|
#
66df44b2 |
| 02-May-2018 |
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> |
ARM: exynos: no need to select ARCH_HAS_BANDGAP any longer
This is not needed since commit fcbb1e02ee54 ("drivers: thermal: Remove ARCH_HAS_BANDGAP dependency for samsung") from 2014.
Signed-off-by
ARM: exynos: no need to select ARCH_HAS_BANDGAP any longer
This is not needed since commit fcbb1e02ee54 ("drivers: thermal: Remove ARCH_HAS_BANDGAP dependency for samsung") from 2014.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
#
c5deb598 |
| 24-Apr-2018 |
Krzysztof Kozlowski <krzk@kernel.org> |
ARM: exynos: Remove support for Exynos5440
The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree suppo
ARM: exynos: Remove support for Exynos5440
The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|