summaryrefslogtreecommitdiff
path: root/drivers/soc
AgeCommit message (Collapse)AuthorFilesLines
2020-09-18arm64: tegra: Initial Tegra234 VDK supportThierry Reding1-0/+10
The NVIDIA Tegra234 VDK is a simulation platform for the Orin SoC. It supports a subset of the peripherals that will be available in the final chip and serves as a bootstrapping platform. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-18soc/tegra: pmc: Add Tegra234 supportThierry Reding1-0/+68
The PMC block is largely similar to that found on earlier chips, but not completely compatible. Allow binding to the instantiation found on Tegra234. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-18soc/tegra: pmc: Reorder reset sources/levels definitionsThierry Reding1-39/+39
Move the definitions of reset sources and levels into a more natural location. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-18soc/tegra: misc: Add Tegra234 supportThierry Reding1-0/+1
The MISC block is largely similar to that found on earlier chips, but not completely compatible. Allow binding to the instantiation found on Tegra234. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-18soc/tegra: fuse: Add Tegra234 supportThierry Reding4-2/+45
Add support for FUSE block found on the Tegra234 SoC, which is largely similar to the IP found on previous generations. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-18soc/tegra: fuse: Implement tegra_is_silicon()Thierry Reding1-0/+19
This function can be used by drivers to determine whether code is running on silicon or on a simulation platform. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-18soc/tegra: fuse: Extract tegra_get_platform()Thierry Reding2-1/+6
This function extracts the PRE_SI_PLATFORM field from the HIDREV register and can be used to determine which platform the kernel runs on (silicon, simulation, ...). Note that while only Tegra194 and later define this field, it should be safe to call this on prior generations as well since this field should read as 0, indicating silicon. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17soc: qcom: llcc: use devm_platform_ioremap_resource_byname()Qilong Zhang1-6/+1
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately. Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20200916111517.99670-1-zhangqilong3@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-16soc: renesas: r8a779a0-sysc: Add r8a779a0 supportYoshihiro Shimoda3-0/+453
Add support for R-Car V3U (R8A779A0) SoC power areas and register access, because register specification differs from R-Car Gen2/3. Inspired by patches in the BSP by Tho Vu. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1599810232-29035-5-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-09-15soc: qcom: apr: Fixup the error displayed on lookup failureSibi Sankar1-1/+1
APR client incorrectly prints out "ret" variable on pdr_add_lookup failure, it should be printing the error value returned by the lookup instead. Fixes: 8347356626028 ("soc: qcom: apr: Add avs/audio tracking functionality") Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200915154232.27523-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-14soc: qcom: pdr: Fixup array type of get_domain_list_resp messageSibi Sankar1-1/+1
The array type of get_domain_list_resp is incorrectly marked as NO_ARRAY. Due to which the following error was observed when using pdr helpers with the downstream proprietary pd-mapper. Fix this up by marking it as VAR_LEN_ARRAY instead. Err logs: qmi_decode_struct_elem: Fault in decoding: dl(2), db(27), tl(160), i(1), el(1) failed to decode incoming message PDR: tms/servreg get domain list txn wait failed: -14 PDR: service lookup for tms/servreg failed: -14 Tested-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Reported-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200914145807.1224-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-14soc: qcom: socinfo: Add msm8992/4 and apq8094 SoC IDsKonrad Dybcio1-0/+3
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com> Link: https://lore.kernel.org/r/20200602201229.322578-1-konradybcio@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-13Merge tag 'arm-soc/for-5.10/drivers' of https://github.com/Broadcom/stblinux ↵Olof Johansson6-10/+498
into arm/drivers This pull request contains Broadcom SoCs drivers changes for 5.10, please pull the following: - Alvaro adds support for the BCM63xx (DSL) SoCs power domain controller and adds support for the 6318, 6328, 6362, 63268. - Florian adds support for tuning the Bus Interface Unit on 72164 and 72165, enables the Brahma-B53 and Cortex-A72 read-ahead cache for the 64-bit capable ARCH_BRCMSTB platforms, and finally updates the GISB driver to support breakpoint notifications. * tag 'arm-soc/for-5.10/drivers' of https://github.com/Broadcom/stblinux: bus: brcmstb_gisb: Add support for breakpoint interrupts dt-bindings: bus: Document breakpoint interrupt for gisb-arb soc: bcm: brcmstb: biuctrl: Change RAC data line prefetching after 4 consecutive lines soc: bcm: brcmstb: biuctrl: Change RAC prefetch distance from +/-1 to +/- 2 soc: bcm: brcmstb: biuctrl: Tune MCP settings for 72165 soc: bcm: brcmstb: biuctrl: Tune MCP settings for 72164 MIPS: BMIPS: dts: add BCM63268 power domain support MIPS: BMIPS: dts: add BCM6362 power domain support MIPS: BMIPS: dts: add BCM6328 power domain support soc: bcm: add BCM63xx power domain driver MIPS: BMIPS: add BCM6318 power domain definitions MIPS: BMIPS: add BCM63268 power domain definitions MIPS: BMIPS: add BCM6362 power domain definitions MIPS: BMIPS: add BCM6328 power domain definitions dt-bindings: soc: brcm: add BCM63xx power domain binding soc: bcm: brcmstb: biuctrl: Enable Read-ahead cache bus: brcmstb_gisb: Shorten prints Link: https://lore.kernel.org/r/20200912032153.1216354-3-f.fainelli@gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2020-09-13Merge tag 'omap-for-v5.10/ti-sysc-drop-pdata-signed' of ↵Olof Johansson2-8/+313
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/soc Add initial genpd support for omaps to drop more platform data We now drop legacy platform data for RTC on am3, am4 and dra7. And we add initial genpd support for PRM (Power and Reset Manager) and use it to drop legacy platform data for am3 sgx and omap4/5 l4_abe interconnect instance. * tag 'omap-for-v5.10/ti-sysc-drop-pdata-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: Drop legacy platform data for dra7 rtcss ARM: OMAP2+: Drop legacy platform data for am3 and am4 rtc soc: ti: pm33xx: Simplify RTC usage to prepare to drop platform data ARM: dts: Configure omap4 and 5 l4_abe for genpd and drop platform data ARM: dts: Configure am3 and am4 sgx for genpd and drop platform data soc: ti: omap-prm: Configure omap4 and 5 l4_abe power domain soc: ti: omap-prm: Configure sgx power domain for am3 and am4 soc: ti: omap-prm: Add basic power domain support dt-bindings: omap: Update PRM binding for genpd Link: https://lore.kernel.org/r/pull-1599132307-761202@atomide.com-2 Signed-off-by: Olof Johansson <olof@lixom.net>
2020-09-13Merge tag 'versatile-soc-v5.10-1' of ↵Olof Johansson1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into arm/soc Versatile SoC updates for the v5.10 kernel cycle: - Drop a static qualifier in integrator_soc_init() - Remove Integrator and Versatile from PHYS_OFFSET * tag 'versatile-soc-v5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator: ARM: versatile: Remove Integrator and Realview from PHYS_OFFSET soc: integrator: Drop pointless static qualifier in integrator_soc_init() Link: https://lore.kernel.org/r/CACRpkdYYDSg8FAjJAqew5yEu7H1Y3E1rPN9TL25K31T=QWATuA@mail.gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2020-09-13Merge tag 'samsung-soc-s3c-5.10' of ↵Olof Johansson4-1/+362
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc Samsung S3C24xx and S3C64xx machine code cleanup for v5.10 Big cleanup for the Samsung S3C24xx and S3C64xx platforms, although it also touches files shared with S5Pv210 and Exynos. This is mostly Arnd Bergmann work which Krzysztof Kozlowski took over, rebased and polished. The goal is to cleanup, merge and finally make the Samsung S3C24xx and S3C64xx architectures multiplatform. The multiplatform did not happen yet here - just cleaning up and merging into one arch/arm/mach-s3c directory. However this is step forward for multiplatform or at least to keep this code still maintainable. This pulls also branch with changes for Samsung SoC sound drivers from broonie/sound because the cleanups there were part of this series and all further patches depend on them. * tag 'samsung-soc-s3c-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: (62 commits) ARM: s3c: Avoid naming clash of S3C24xx and S3C64xx timer setup ARM: s3c: Cleanup from old plat-samsung include ARM: s3c: make headers local if possible ARM: s3c: move into a common directory ARM: s3c24xx: stop including mach/hardware.h from mach/io.h cpufreq: s3c24xx: move low-level clk reg access into platform code cpufreq: s3c2412: use global s3c2412_cpufreq_setrefresh ARM: s3c: remove cpufreq header dependencies cpufreq: s3c24xx: split out registers fbdev: s3c2410fb: remove mach header dependency ARM: s3c24xx: bast: avoid irq_desc array usage ARM: s3c24xx: spi: avoid hardcoding fiq number in driver ARM: s3c24xx: include mach/irqs.h where needed ARM: s3c24xx: move s3cmci pinctrl handling into board files ARM: s3c24xx: move iis pinctrl config into boards ARM: s3c24xx: move spi fiq handler into platform ARM: s3c: adc: move header to linux/soc/samsung ARM: s3c24xx: move irqchip driver back into platform ARM: s3c24xx: move regs-spi.h into spi driver ARM: s3c64xx: remove mach/hardware.h ... Link: https://lore.kernel.org/r/20200831154751.7551-1-krzk@kernel.org Signed-off-by: Olof Johansson <olof@lixom.net>
2020-09-11soc: ti: k3-socinfo: Add entry for J7200Peter Ujfalusi1-0/+1
Update K3 chipinfo driver to support new TI J7200 SoC. It's JTAG PARTNO is 0xBB6D. Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUXGrzegorz Jaszczyk1-7/+177
The IEPCLK_MUX is present on all SoCs whereas the CORECLK_MUX is present only on AM65x SoCs and J721E. Add support for both these CLK muxes. This allows the clock rates and clock parents for these to be controlled through DT leveraging the clk infrastructure for configuring the default parents and rates. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of oneTero Kristo1-130/+121
Current implementation of the genpd support over TI SCI uses a single genpd across the whole SoC, and attaches multiple devices to this. This solution has its drawbacks, like it is currently impossible to attach more than one power domain to a device; the core genpd implementation requires one genpd per power-domain entry in DT for a single device. Also, some devices like USB apparently require their own genpd during probe time, the current shared approach in use does not work at all. Switch the implementation over to use a single genpd per power domain entry in DT. The domains are registered with the onecell approach, but we also add our own xlate service due to recent introduction of the extended flag for TI SCI PM domains; genpd core xlate service requires a single cell per powerdomain, but we are using two cells. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: pruss: Enable support for ICSSG subsystems on K3 J721E SoCsSuman Anna1-0/+1
The K3 J721E family of SoCs have a revised version of the PRU-ICSS (ICSSG) processor subsystem present on K3 AM65x SoCs. These SoCs contain typically two ICSSG instances named ICSSG0 and ICSSG1. The two ICSSGs are identical to each other for the most part with minor SoC integration differences and capabilities. The ICSSG1 supports slightly enhanced features like SGMII mode Ethernet, while the ICSSG0 instance is limited to MII mode only. There is no change in the Interrupt Controller w.r.t AM65x. All other integration aspects are very similar to the ICSSGs on AM65x SoCs. The existing pruss platform driver has been updated to support these new ICSSG instances through new J721E specific compatibles. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCsSuman Anna2-1/+2
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem capable of supporting Gigabit Ethernet, and is commonly referred to as ICSSG. These SoCs contain typically three ICSSG instances named ICSSG0, ICSSG1 and ICSSG2. The three ICSSGs are identical to each other for the most part with minor SoC integration differences and capabilities. The ICSSG2 supports slightly enhanced features like SGMII mode Ethernet, while the ICSS0 and ICSSG1 instances are limited to MII mode only. The ICSSGs on K3 AM65x SoCs are in general super-sets of the PRUSS on the AM57xx/66AK2G SoCs. They include two additional auxiliary PRU cores called RTUs and few other additional sub-modules. The interrupt integration is also different on the K3 AM65x SoCs and are propagated through various SoC-level Interrupt Router and Interrupt Aggregator blocks. Other IP level differences include different constant tables, differences in system event interrupt input sources etc. They also do not have a programmable module reset line like those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. The existing pruss platform driver has been updated to support these new ICSSG instances through new AM65x specific compatibles. A build dependency with ARCH_K3 is added to enable building all the existing PRUSS platform drivers for this ARMv8 platform. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoCSuman Anna2-1/+2
The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1, each of which has two PRU processor cores. The two PRU-ICSS instances are identical to each other with few minor SoC integration differences, and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The Shared Data RAM size is larger and the number of interrupts coming into MPU INTC is like the instances on AM437x. There are also few other differences attributing to integration in Keystone architecture (like no SYSCFG register or PRCM handshake protocols). Other IP level differences include different constant table, differences in system event interrupt input sources etc. They also do not have a programmable module reset line like those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. The existing PRUSS platform driver has been enhanced to support these 66AK2G PRU-ICSS instances through new 66AK2G specific compatible for properly probing and booting all the different PRU cores in each PRU-ICSS processor subsystem. A build dependency with ARCH_KEYSTONE is added to enable the driver to be built in K2G-only configuration. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCsSuman Anna2-1/+2
The AM57xx family of SoCs supports two PRU-ICSS instances, each of which has two PRU processor cores. The two PRU-ICSS instances are identical to each other, and are very similar to the PRU-ICSS1 of AM33xx/AM43xx except for a few minor differences like the RAM sizes and the number of interrupts coming into the MPU INTC. They do not have a programmable module reset line unlike those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. Each PRU-ICSS's INTC is also preceded by a Crossbar that enables multiple external events to be routed to a specific number of input interrupt events. Any interrupt event directed towards PRUSS needs this crossbar to be setup properly on the firmware side. The existing PRUSS platform driver has been enhanced to support these AM57xx PRU-ICSS instances through new AM57xx specific compatible for properly probing and booting all the different PRU cores in each PRU-ICSS processor subsystem. A build dependency with SOC_DRA7XX is also added to enable the driver to be built in AM57xx-only configuration (there is no separate Kconfig option for AM57xx vs DRA7xx). Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCsSuman Anna2-2/+35
The AM437x SoCs have two different PRU-ICSS subsystems: PRU-ICSS1 and a smaller PRU-ICSS0. Enhance the PRUSS platform driver to support both the PRU-ICSS sub-systems on these SoCs. The PRU-ICSS1 on AM437x is very similar to the PRU-ICSS on AM33xx except for few minor differences - increased Instruction RAM, increased Shared Data RAM2, and 1 less interrupt (PRUSS host interrupt 7 which is redirected to the other PRUSS) towards the MPU INTC. The PRU-ICSS0 is a cut-down version of the IP, with less DRAM per PRU, no Shared DRAM etc. It also does not have direct access to L3 bus regions, there is a single interface to L3 for both PRUSS0 and PRUSS1, and it would have to go through the PRUSS1's interface. The PRUSS_SYSCFG register is reserved on PRUSS0, so any external access requires the programming the corresponding PRUSS_SYSCFG register in PRUSS1. It does have its own dedicated I/O lines though. Note that this instance does not support any PRU Ethernet related use cases. The adaptation uses SoC-specific compatibles in the driver and uses a newly introduced pruss_match_private_data structure and the pruss_get_private_data() function to retrieve a PRUSS instance specific data using a device-name based lookup logic. The reset and the L3 external access are managed by the parent interconnect ti-sysc bus driver so that PRUSS1 and PRUSS0 can be independently supported. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: pruss: Add a platform driver for PRUSS in TI SoCsSuman Anna3-0/+159
The Programmable Real-Time Unit - Industrial Communication Subsystem (PRU-ICSS) is present on various TI SoCs such as AM335x or AM437x or the Keystone 66AK2G. Each SoC can have one or more PRUSS instances that may or may not be identical. For example, AM335x SoCs have a single PRUSS, while AM437x has two PRUSS instances PRUSS1 and PRUSS0, with the PRUSS0 being a cut-down version of the PRUSS1. The PRUSS consists of dual 32-bit RISC cores called the Programmable Real-Time Units (PRUs), some shared, data and instruction memories, some internal peripheral modules, and an interrupt controller. The programmable nature of the PRUs provide flexibility to implement custom peripheral interfaces, fast real-time responses, or specialized data handling. The PRU-ICSS functionality is achieved through three different platform drivers addressing a specific portion of the PRUSS. Some sub-modules of the PRU-ICSS IP reuse some of the existing drivers (like davinci mdio driver or the generic syscon driver). This design provides flexibility in representing the different modules of PRUSS accordingly, and at the same time allowing the PRUSS driver to add some instance specific configuration within an SoC. The PRUSS platform driver deals with the overall PRUSS and is used for managing the subsystem level resources like various memories and the CFG module. It is responsible for the creation and deletion of the platform devices for the child PRU devices and other child devices (like Interrupt Controller, MDIO node and some syscon nodes) so that they can be managed by specific platform drivers. The PRUSS interrupt controller is managed by an irqchip driver, while the individual PRU RISC cores are managed by a PRU remoteproc driver. The driver currently supports the AM335x SoC, and support for other TI SoCs will be added in subsequent patches. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: ti: k3: ringacc: add am65x sr2.0 supportGrygorii Strashko1-3/+30
The AM65x SR2.0 Ringacc has fixed errata i2023 "RINGACC, UDMA: RINGACC and UDMA Ring State Interoperability Issue after Channel Teardown". This errata also fixed for J271E SoC. Use SOC bus data for K3 SoC identification and enable i2023 errate w/a only for the AM65x SR1.0. This also makes obsolete "ti,dma-ring-reset-quirk" DT property. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-11soc: sunxi: sram: remove unneeded semicolonJason Yan1-1/+1
Eliminate the following coccicheck warning: drivers/soc/sunxi/sunxi_sram.c:197:2-3: Unneeded semicolon Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200910140546.1191280-1-yanaijie@huawei.com
2020-09-10soc: qcom: rpmh-rsc: Sleep waiting for tcs slots to be freeStephen Boyd2-61/+58
The busy loop in rpmh_rsc_send_data() is written with the assumption that the udelay will be preempted by the tcs_tx_done() irq handler when the TCS slots are all full. This doesn't hold true when the calling thread is an irqthread and the tcs_tx_done() irq is also an irqthread. That's because kernel irqthreads are SCHED_FIFO and thus need to voluntarily give up priority by calling into the scheduler so that other threads can run. I see RCU stalls when I boot with irqthreads on the kernel commandline because the modem remoteproc driver is trying to send an rpmh async message from an irqthread that needs to give up the CPU for the rpmh irqthread to run and clear out tcs slots. rcu: INFO: rcu_preempt self-detected stall on CPU rcu: 0-....: (1 GPs behind) idle=402/1/0x4000000000000002 softirq=2108/2109 fqs=4920 (t=21016 jiffies g=2933 q=590) Task dump for CPU 0: irq/11-smp2p R running task 0 148 2 0x00000028 Call trace: dump_backtrace+0x0/0x154 show_stack+0x20/0x2c sched_show_task+0xfc/0x108 dump_cpu_task+0x44/0x50 rcu_dump_cpu_stacks+0xa4/0xf8 rcu_sched_clock_irq+0x7dc/0xaa8 update_process_times+0x30/0x54 tick_sched_handle+0x50/0x64 tick_sched_timer+0x4c/0x8c __hrtimer_run_queues+0x21c/0x36c hrtimer_interrupt+0xf0/0x22c arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x114/0x25c __handle_domain_irq+0x84/0xc4 gic_handle_irq+0xd0/0x178 el1_irq+0xbc/0x180 save_return_addr+0x18/0x28 return_address+0x54/0x88 preempt_count_sub+0x40/0x88 _raw_spin_unlock_irqrestore+0x4c/0x6c ___ratelimit+0xd0/0x128 rpmh_rsc_send_data+0x24c/0x378 __rpmh_write+0x1b0/0x208 rpmh_write_async+0x90/0xbc rpmhpd_send_corner+0x60/0x8c rpmhpd_aggregate_corner+0x8c/0x124 rpmhpd_set_performance_state+0x8c/0xbc _genpd_set_performance_state+0xdc/0x1b8 dev_pm_genpd_set_performance_state+0xb8/0xf8 q6v5_pds_disable+0x34/0x60 [qcom_q6v5_mss] qcom_msa_handover+0x38/0x44 [qcom_q6v5_mss] q6v5_handover_interrupt+0x24/0x3c [qcom_q6v5] handle_nested_irq+0xd0/0x138 qcom_smp2p_intr+0x188/0x200 irq_thread_fn+0x2c/0x70 irq_thread+0xfc/0x14c kthread+0x11c/0x12c ret_from_fork+0x10/0x18 This busy loop naturally lends itself to using a wait queue so that each thread that tries to send a message will sleep waiting on the waitqueue and only be woken up when a free slot is available. This should make things more predictable too because the scheduler will be able to sleep tasks that are waiting on a free tcs instead of the busy loop we currently have today. Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Maulik Shah <mkshah@codeaurora.org> Cc: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200724211711.810009-1-sboyd@kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-10soc: qcom: socinfo: add SC7180 entry to soc_id arrayDouglas Anderson1-0/+1
Add an entry for SC7180 SoC. Reviewed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200813080345.1.I85bb28f9ea3fa3bf797ecaf0a5218ced4cfaa6e2@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-10soc: qcom: socinfo: add soc id for IPQ6018Kathiravan T1-0/+1
Add the SoC ID for IPQ6018 variant. Signed-off-by: Kathiravan T <kathirav@codeaurora.org> Link: https://lore.kernel.org/r/1597645830-30409-1-git-send-email-kathirav@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-10soc: renesas: rcar-rst: Add support for R-Car V3UYoshihiro Shimoda1-0/+6
Add support for R-Car V3U (R8A779A0) to the R-Car RST driver. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1599470390-29719-12-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-09-10soc: renesas: Identify R-Car V3UYoshihiro Shimoda2-0/+14
Add support for identifying the R-Car V3U (R8A779A0) SoC. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1599470390-29719-10-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-09-10soc: renesas: Sort driver description titleKuninori Morimoto1-159/+157
This patch sorts each driver by description title in alphabetical order. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87a6y2v54o.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-09-10soc: renesas: Use ARM32/ARM64 for menu descriptionKuninori Morimoto1-32/+32
For easy understanding of architecture and alphabetical merging, this patch uses ARM32/ARM64 for description. This prepares for sorting the menu. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87bliiv54u.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-09-06soc: bcm: brcmstb: biuctrl: Change RAC data line prefetching after 4 ↵Florian Fainelli1-2/+6
consecutive lines Change the RACPREFDATA(x) setting to prefetch the next 256-byte line after 4 consecutive lines have been used, instead of after 2 consecutive lines. This does improve the synthetic memcpy benchmark by an additional +0.5% on top of the previous change for Cortex-A72 CPUs. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-04soc: bcm: brcmstb: biuctrl: Change RAC prefetch distance from +/-1 to +/- 2Florian Fainelli1-4/+16
Change the RAC prefetch distance from +/- 1 to +/- 2 for Cortex-A72 CPUs since this provides an average of a 3.8% performance increase for synthetic memcpy benchmarks. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-04soc: bcm: brcmstb: biuctrl: Tune MCP settings for 72165Florian Fainelli1-0/+1
72165 uses a Brahma-B53 CPU and its Bus Interface Unit, tune it according to the existing values we have. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-04soc: bcm: brcmstb: biuctrl: Tune MCP settings for 72164Florian Fainelli1-0/+1
72164 uses a Brahma-B53 CPU and its Bus Interface Unit, tune it according to the existing values we have. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-03Merge branch 'omap-for-v5.10/prm-genpd' into omap-for-v5.10/ti-sysc-drop-pdataTony Lindgren1-3/+271
2020-09-01soc: renesas: Align driver description titlesKuninori Morimoto1-56/+56
Now, Renesas SoC drivers are under menu, but current descriptions are not aligned. This patch aligns them. - Emma Mobile EV2 - RZ/A1H (R7S72100) ... - R-Car H2 (R8A77900) ... - Renesas R-Car H3 ES1.x SoC Platform ... - R-Car H2 System Controller support - R-Car M2-W/N System Controller support - R-Car V2H System Controller support - R-Car E2 System Controller support - R-Car H3 System Controller support - R-Car M3-W System Controller support - R-Car M3-W+ System Controller support - R-Car M3-N System Controller support + SoC Platform support for Emma Mobile EV2 + SoC Platform support for RZ/A1H+ ... + SoC Platform support for R-Car H2 ... + SoC Platform support for R-Car H3 ES1.x ... + System Controller support for R-Car H2 + System Controller support for R-Car M2-W/N + System Controller support for R-Car V2H + System Controller support for R-Car E2 + System Controller support for R-Car H3 + System Controller support for R-Car M3-W + System Controller support for R-Car M3-W+ + System Controller support for R-Car M3-N Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87zh6kyedc.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-08-25soc: renesas: Use menu for Renesas SoCKuninori Morimoto1-1/+1
Renesas related SoC settings are located on TOP level menu, thus it is very verbose. This patch groups Renesas related settings into "Renesas SoC driver support" menu. And it aligns config menu names. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87k0xxho7t.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-08-25opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFERStephan Gerhold1-1/+1
The OPP core manages various resources, e.g. clocks or interconnect paths. These resources are looked up when the OPP table is allocated once dev_pm_opp_get_opp_table() is called the first time (either directly or indirectly through one of the many helper functions). At this point, the resources may not be available yet, i.e. looking them up will result in -EPROBE_DEFER. Unfortunately, dev_pm_opp_get_opp_table() is currently unable to propagate this error code since it only returns the allocated OPP table or NULL. This means that all consumers of the OPP core are required to make sure that all necessary resources are available. Usually this happens by requesting them, checking the result and releasing them immediately after. For example, we have added "dev_pm_opp_of_find_icc_paths(dev, NULL)" to several drivers now just to make sure the interconnect providers are ready before the OPP table is allocated. If this call is missing, the OPP core will only warn about this and then attempt to continue without interconnect. This will eventually fail horribly, e.g.: cpu cpu0: _allocate_opp_table: Error finding interconnect paths: -517 ... later ... of: _read_bw: Mismatch between opp-peak-kBps and paths (1 0) cpu cpu0: _opp_add_static_v2: opp key field not found cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22 This example happens when trying to use interconnects for a CPU OPP table together with qcom-cpufreq-nvmem.c. qcom-cpufreq-nvmem calls dev_pm_opp_set_supported_hw(), which ends up allocating the OPP table early. To fix the problem with the current approach we would need to add yet another call to dev_pm_opp_of_find_icc_paths(dev, NULL). But actually qcom-cpufreq-nvmem.c has nothing to do with interconnects... This commit attempts to make this more robust by allowing dev_pm_opp_get_opp_table() to return an error pointer. Fixing all the usages is trivial because the function is usually used indirectly through another helper (e.g. dev_pm_opp_set_supported_hw() above). These other helpers already return an error pointer. The example above then works correctly because set_supported_hw() will return -EPROBE_DEFER, and qcom-cpufreq-nvmem.c already propagates that error. It should also be possible to remove the remaining usages of "dev_pm_opp_of_find_icc_paths(dev, NULL)" from other drivers as well. Note that this commit currently only handles -EPROBE_DEFER for the clock/interconnects within _allocate_opp_table(). Other errors are just ignored as before. Eventually those should be propagated as well. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> [ Viresh: skip checking return value of dev_pm_opp_get_opp_table() for EPROBE_DEFER in domain.c, fix NULL return value and reorder code a bit in core.c, and update exynos-asv.c ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-08-24soc: ti: pm33xx: Simplify RTC usage to prepare to drop platform dataTony Lindgren1-5/+42
We must re-enable the RTC module clock enabled in RTC+DDR suspend, and pm33xx has been using platform data callbacks for that. Looks like for retention suspend the RTC module clock must not be re-enabled. To remove the legacy platform data callbacks, and eventually be able to drop the RTC legacy platform data, let's manage the RTC module clock and register range directly in pm33xx. Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-08-23treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva2-12/+12
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-22soc: imx: gpcv2: Use dev_err_probe() to simplify error handlingAnson Huang1-10/+5
dev_err_probe() can reduce code size, uniform error handling and record the defer probe reason etc., use it to simplify the code. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-08-20soc: integrator: Drop pointless static qualifier in integrator_soc_init()YueHaibing1-1/+1
There is no need to have the 'struct regmap *syscon_regmap' variable static since new value always be assigned before use it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200715024701.28356-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-08-19ARM: samsung: move pm check code to drivers/socArnd Bergmann4-1/+362
This is the only part of plat-samsung that is really shared between the s3c and s5p ports. Moving it to drivers/soc/ lets us make them completely independent. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200806182059.2431-16-krzk@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-08-18soc: ti: omap-prm: Configure omap4 and 5 l4_abe power domainTony Lindgren1-0/+22
Let's add omap4 and 5 l4_abe interconnect instance for the power domain. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-08-18soc: ti: omap-prm: Configure sgx power domain for am3 and am4Tony Lindgren1-2/+22
Let's configure only sgx power domain for am3 and am4 to start with. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-08-18soc: ti: omap-prm: Add basic power domain supportTony Lindgren1-1/+227
The PRM controller has currently only support for resets while the power domains are still handled in the platform code. Let's add basic power domain support to enable and disable a PRM controlled power domain if configured in the devicetree. This can be used for various hardware accelerators, and interconnect instances. Further support can be added later on as needed for runtime configuration based on domain-idle-states. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-19 04:16:24 +0000