lwn.git/arch/arm/mach-exynos/Kconfig, branch v6.8-rc5

ARM: exynos: Re-introduce Exynos4212 support

2023-05-09T17:44:30+00:00

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 Link: https://lore.kernel.org/r/20230501195525.6268-4-aweber.kernel@gmail.com Signed-off-by: Krzysztof Kozlowski

Merge tag 'arm-multiplatform-5.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2022-05-26T17:43:09+00:00

Pull ARMv4T/v5 multiplatform support from Arnd Bergmann: "This series has been 12 years in the making, it mostly finishes the work that was started with the founding of Linaro to clean up platform support in the kernel. The largest change here is a cleanup of the omap1 platform, which is the final ARM machine type to get converted to the common-clk subsystem. All the omap1 specific drivers are now made independent of the mach/*.h headers to allow the platform to be part of a generic ARMv4/v5 multiplatform kernel. The last bit that enables this support is still missing here while we wait for some last dependencies to make it into the mainline kernel through other subsystems. The s3c24xx, ixp4xx, iop32x, ep93xx and dove platforms were all almost at the point of allowing multiplatform kernels, this work gets completed here along with a few additional cleanup. At the same time, the s3c24xx and s3c64xx are now deprecated and expected to get removed in the future. The PXA and OMAP1 bits are in a separate branch because of dependencies. Once both branches are merged, only the three Intel StrongARM platforms (RiscPC, Footbridge/NetWinder and StrongARM1100) need separate kernels, and there are no plans to include these" * tag 'arm-multiplatform-5.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (61 commits) ARM: ixp4xx: Consolidate Kconfig fixing issue ARM: versatile: Add missing of_node_put in dcscb_init ARM: config: Refresh IXP4xx config after multiplatform ARM: omap1: add back omap_set_dma_priority() stub ARM: omap: fix missing declaration warnings ARM: omap: fix address space warnings from sparse ARM: spear: remove include/mach/ subdirectory ARM: davinci: remove include/mach/ subdirectory ARM: omap2: remove include/mach/ subdirectory integrator: remove empty ap_init_early() ARM: s3c: fix include path MAINTAINERS: omap1: Add Janusz as an additional maintainer ARM: omap1: htc_herald: fix typos in comments ARM: OMAP1: fix typos in comments ARM: OMAP1: clock: Remove noop code ARM: OMAP1: clock: Remove unused code ARM: OMAP1: clock: Fix UART rate reporting algorithm ARM: OMAP1: clock: Fix early UART rate issues ARM: OMAP1: Prepare for conversion of OMAP1 clocks to CCF ARM: omap1: fix build with no SoC selected ...

pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos config

2022-04-21T06:58:54+00:00

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 Fixes: eed6b3eb20b9 ("arm64: Split out platform options to separate Kconfig") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20220420141407.470955-1-krzysztof.kozlowski@linaro.org

ARM: rework endianess selection

2022-04-08T15:20:54+00:00

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

ARM: samsung: Remove HAVE_S3C2410_I2C and use direct dependencies

2021-11-21T16:46:18+00:00

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 Link: https://lore.kernel.org/r/20211121150558.21801-2-semen.protsenko@linaro.org Signed-off-by: Krzysztof Kozlowski

rtc: s3c: remove HAVE_S3C_RTC in favor of direct dependencies

2021-10-17T17:15:12+00:00

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 Acked-by: Alexandre Belloni Link: https://lore.kernel.org/r/20211013212256.3425889-1-willmcvicker@google.com Signed-off-by: Krzysztof Kozlowski

soc: samsung: exynos-chipid: do not enforce built-in

2021-09-29T13:50:34+00:00

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 Reviewed-by: Sylwester Nawrocki Tested-by: Sylwester Nawrocki Reviewed-by: Alim Akhtar Tested-by: Alim Akhtar Link: https://lore.kernel.org/r/20210919093114.35987-4-krzysztof.kozlowski@canonical.com

soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

2021-01-03T16:08:45+00:00

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 Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey

arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL

2020-12-15T20:13:42+00:00

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 Cc: Alexey Dobriyan Cc: Catalin Marinas Cc: Geert Uytterhoeven Cc: Greg Ungerer Cc: John Paul Adrian Glaubitz Cc: Jonathan Corbet Cc: Matt Turner Cc: Meelis Roos Cc: Michael Schmitz Cc: Russell King Cc: Tony Luck Cc: Vineet Gupta Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ARM: samsung: remove HAVE_S3C2410_WATCHDOG and use direct dependencies

2020-08-19T18:57:35+00:00

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 Acked-by: Guenter Roeck