linux/drivers/soc/samsung/Kconfig

106 lines
3.5 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0
#
# Samsung SoC drivers
#
menuconfig SOC_SAMSUNG
bool "Samsung SoC driver support" if COMPILE_TEST
if SOC_SAMSUNG
# There is no need to enable these drivers for ARMv8
config EXYNOS_ASV_ARM
bool "Exynos ASV ARMv7-specific driver extensions" if COMPILE_TEST
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>
2020-12-07 18:54:57 +00:00
depends on EXYNOS_CHIPID
config EXYNOS_CHIPID
tristate "Exynos ChipID controller and ASV driver"
depends on ARCH_EXYNOS || COMPILE_TEST
default ARCH_EXYNOS
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>
2020-12-07 18:54:57 +00:00
select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
select MFD_SYSCON
select SOC_BUS
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>
2020-12-07 18:54:57 +00:00
help
Support for Samsung Exynos SoC ChipID and Adaptive Supply Voltage.
This driver can also be built as module (exynos_chipid).
soc: samsung: Add USI driver USIv2 IP-core is found on modern ARM64 Exynos SoCs (like Exynos850) and provides selectable serial protocol (one of: UART, SPI, I2C). USIv2 registers usually reside in the same register map as a particular underlying protocol it implements, but have some particular offset. E.g. on Exynos850 the USI_UART has 0x13820000 base address, where UART registers have 0x00..0x40 offsets, and USI registers have 0xc0..0xdc offsets. Desired protocol can be chosen via SW_CONF register from System Register block of the same domain as USI. Before starting to use a particular protocol, USIv2 must be configured properly: 1. Select protocol to be used via System Register 2. Clear "reset" flag in USI_CON 3. Configure HWACG behavior (e.g. for UART Rx the HWACG must be disabled, so that the IP clock is not gated automatically); this is done using USI_OPTION register 4. Keep both USI clocks (PCLK and IPCLK) running during USI registers modification This driver implements the above behavior. Of course, USIv2 driver should be probed before UART/I2C/SPI drivers. It can be achieved by embedding UART/I2C/SPI nodes inside of the USI node (in Device Tree); driver then walks underlying nodes and instantiates those. Driver also handles USI configuration on PM resume, as register contents can be lost during CPU suspend. This driver is designed with different USI versions in mind. So it should be relatively easy to add new USI revisions to it later. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20211204195757.8600-3-semen.protsenko@linaro.org Tested-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-12-04 19:57:54 +00:00
config EXYNOS_USI
tristate "Exynos USI (Universal Serial Interface) driver"
default ARCH_EXYNOS && ARM64
depends on ARCH_EXYNOS || COMPILE_TEST
select MFD_SYSCON
help
Enable support for USI block. USI (Universal Serial Interface) is an
IP-core found in modern Samsung Exynos SoCs, like Exynos850 and
ExynosAutoV0. USI block can be configured to provide one of the
following serial protocols: UART, SPI or High Speed I2C.
This driver allows one to configure USI for desired protocol, which
is usually done in USI node in Device Tree.
config EXYNOS_PMU
bool "Exynos PMU controller driver" if COMPILE_TEST
depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
select EXYNOS_PMU_ARM_DRIVERS if ARM && ARCH_EXYNOS
select MFD_CORE
# There is no need to enable these drivers for ARMv8
config EXYNOS_PMU_ARM_DRIVERS
bool "Exynos PMU ARMv7-specific driver extensions" if COMPILE_TEST
depends on EXYNOS_PMU
config EXYNOS_PM_DOMAINS
bool "Exynos PM domains" if COMPILE_TEST
depends on (ARCH_EXYNOS && PM_GENERIC_DOMAINS) || COMPILE_TEST
config SAMSUNG_PM_DEBUG
bool "Samsung PM Suspend debug"
depends on PM && DEBUG_KERNEL
depends on PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210
depends on DEBUG_S3C24XX_UART || DEBUG_S3C2410_UART
Samsung mach/soc changes for v5.10 1. Clear unneeded L2C-310 flag which presenc was triggering warning message. 2. Fix build of SAMSUNG_PM_DEBUG without MMU. 3. Minor cleanups and update of linux-samsung-soc mailing list in Maintainers. -----BEGIN PGP SIGNATURE----- iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAl9ner0QHGtyemtAa2Vy bmVsLm9yZwAKCRDBN2bmhouD1xRiEACRlwd8oXmvTjSvFAlw8Z8/WTDpwxbfX4ra XZXjkVzoNw9IO3c5dfCvV4np0bJM6hepNKUoHHE8FsP0aNB81Geg/FhmQeIOtz4v BAfrGIbJp+2gRTQU9BhMLw3BhzWxp0TAe+0mXNTLER2BrTrF3/M5K2Rm7/W9k4wo fT8epub4X4CB927Mp/mkovqXKk5h+KfsMxFZNBHYUW/fsyDmScL6MOYXBxsalKx6 fC+XMqI6VBiEgpO42FZ6YuEMK1o9eAkpHGSFCIjFyTkqm/O7/Z536Ho/D9CHeCuT WDdtK04b0r7vSCToTpiHr+qgZtbnJl/pgJ673/zlxik9UvLLGw7DqtnSEtPJep1l Z8aEuhRlWuUrvcAkslJvMMqHRx495DThs+axbxYCxfG+u+ivFjHGAxSLLlM9f3Fy ftZ70sBMCu+EtniaXGzcFLxyKQA1S99uJH7SYVj2G9e3Lq+Eo64FK3KKSN6bBy6R wuIySiwlgMgfrhHgs5khe6VZcwrjVssLjBtWF+EWEs1KpYiwcDGl1mifJG9vWIXm ngrJBLiloqKPBApKcbR+4lLxRkMsYJC1r9svRKNElb/AqaWlz75TAkNADVaf0W6d ZmKAWYBd6J7Ll5wXD8nqSc5XN3TZl33gkGmBi8pJV81iB+S2FE/I29afcMQVtEgO 7zl4VQbG+Q== =Bkfy -----END PGP SIGNATURE----- Merge tag 'samsung-soc-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc Samsung mach/soc changes for v5.10 1. Clear unneeded L2C-310 flag which presenc was triggering warning message. 2. Fix build of SAMSUNG_PM_DEBUG without MMU. 3. Minor cleanups and update of linux-samsung-soc mailing list in Maintainers. * tag 'samsung-soc-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: s3c64xx: bring back notes from removed debug-macro.S ARM: s3c24xx: fix Wunused-variable warning on !MMU ARM: samsung: fix PM debug build with DEBUG_LL but !MMU MAINTAINERS: mark linux-samsung-soc list non-moderated ARM: exynos: clear L310_AUX_CTRL_NS_LOCKDOWN in default l2c_aux_val Signed-off-by: Olof Johansson <olof@lixom.net>
2020-09-26 19:55:43 +00:00
depends on DEBUG_LL && MMU
help
Say Y here if you want verbose debugging from the PM Suspend and
Resume code. See <file:Documentation/arm/samsung-s3c24xx/suspend.rst>
for more information.
config S3C_PM_DEBUG_LED_SMDK
bool "SMDK LED suspend/resume debugging"
depends on PM && (MACH_SMDK6410)
help
Say Y here to enable the use of the SMDK LEDs on the baseboard
for debugging of the state of the suspend and resume process.
Note, this currently only works for S3C64XX based SMDK boards.
config SAMSUNG_PM_CHECK
bool "S3C2410 PM Suspend Memory CRC"
depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210)
select CRC32
help
Enable the PM code's memory area checksum over sleep. This option
will generate CRCs of all blocks of memory, and store them before
going to sleep. The blocks are then checked on resume for any
errors.
Note, this can take several seconds depending on memory size
and CPU speed.
See <file:Documentation/arm/samsung-s3c24xx/suspend.rst>
config SAMSUNG_PM_CHECK_CHUNKSIZE
int "S3C2410 PM Suspend CRC Chunksize (KiB)"
depends on PM && SAMSUNG_PM_CHECK
default 64
help
Set the chunksize in Kilobytes of the CRC for checking memory
corruption over suspend and resume. A smaller value will mean that
the CRC data block will take more memory, but will identify any
faults with better precision.
See <file:Documentation/arm/samsung-s3c24xx/suspend.rst>
config EXYNOS_REGULATOR_COUPLER
bool "Exynos SoC Regulator Coupler" if COMPILE_TEST
depends on ARCH_EXYNOS || COMPILE_TEST
endif