kernel/linux.git/drivers/soc/rockchip, branch v6.1.168

pmdomain: Use device_get_match_data()

2026-01-11T14:19:22+00:00

[ Upstream commit 3ba9fdfaa550936837b50b73d6c27ac401fde875 ] Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20231006224614.444488-1-robh@kernel.org Signed-off-by: Ulf Hansson Stable-dep-of: 73cb5f6eafb0 ("pmdomain: imx: Fix reference count leak in imx_gpc_probe()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

soc: rockchip: power-domain: add power domain support for rk3588

2022-09-09T17:06:41+00:00

This driver is modified to support RK3588 SoCs. Signed-off-by: Finley Xiao [port of downstream code incl. merging in fixes] Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20220906143825.199089-7-sebastian.reichel@collabora.com Signed-off-by: Heiko Stuebner

soc: rockchip: power-domain: do not enable domain when adding it

2022-09-09T17:06:40+00:00

It's not need to power on all pd when add pm domain. Instead use PD's real status in pm_genpd_init(). Signed-off-by: Elaine Zhang Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20220906143825.199089-6-sebastian.reichel@collabora.com Signed-off-by: Heiko Stuebner

soc: rockchip: io-domain: Add RV1126 IO domains

2022-09-05T09:53:47+00:00

Add IO domains support for RV1126 SoC. Cc: Liam Girdwood Cc: Mark Brown Signed-off-by: Jianqun Xu Signed-off-by: Jagan Teki Link: https://lore.kernel.org/r/20220818124132.125304-6-jagan@edgeble.ai Signed-off-by: Heiko Stuebner

soc: rockchip: power-domain: Add RV1126 power domains

2022-09-05T09:53:46+00:00

Add power domains support for RV1126 SoC. Cypto, VO and NPU domains will add it future patches. Signed-off-by: Elaine Zhang Signed-off-by: Jagan Teki Link: https://lore.kernel.org/r/20220818124132.125304-4-jagan@edgeble.ai Signed-off-by: Heiko Stuebner

Merge tag 'v5.19-rockchip-drivers2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/late

2022-05-27T20:19:48+00:00

Refcount leak for a used of-node in the grf-init. * tag 'v5.19-rockchip-drivers2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: soc: rockchip: Fix refcount leak in rockchip_grf_init Link: https://lore.kernel.org/r/4541398.Icojqenx9y@phil Signed-off-by: Arnd Bergmann

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

2022-05-26T17:32:47+00:00

Pull ARM driver updates from Arnd Bergmann: "There are minor updates to SoC specific drivers for chips by Rockchip, Samsung, NVIDIA, TI, NXP, i.MX, Qualcomm, and Broadcom. Noteworthy driver changes include: - Several conversions of DT bindings to yaml format. - Renesas adds driver support for R-Car V4H, RZ/V2M and RZ/G2UL SoCs. - Qualcomm adds a bus driver for the SSC (Snapdragon Sensor Core), and support for more chips in the RPMh power domains and the soc-id. - NXP has a new driver for the HDMI blk-ctrl on i.MX8MP. - Apple M1 gains support for the on-chip NVMe controller, making it possible to finally use the internal disks. This also includes SoC drivers for their RTKit IPC and for the SART DMA address filter. For other subsystems that merge their drivers through the SoC tree, we have - Firmware drivers for the ARM firmware stack including TEE, OP-TEE, SCMI and FF-A get a number of smaller updates and cleanups. OP-TEE now has a cache for firmware argument structures as an optimization, and SCMI now supports the 3.1 version of the specification. - Reset controller updates to Amlogic, ASpeed, Renesas and ACPI drivers - Memory controller updates for Tegra, and a few updates for other platforms" * tag 'arm-drivers-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (159 commits) memory: tegra: Add MC error logging on Tegra186 onward memory: tegra: Add memory controller channels support memory: tegra: Add APE memory clients for Tegra234 memory: tegra: Add Tegra234 support nvme-apple: fix sparse endianess warnings soc/tegra: pmc: Document core domain fields soc: qcom: pdr: use static for servreg_* variables soc: imx: fix semicolon.cocci warnings soc: renesas: R-Car V3U is R-Car Gen4 soc: imx: add i.MX8MP HDMI blk-ctrl soc: imx: imx8m-blk-ctrl: Add i.MX8MP media blk-ctrl soc: imx: add i.MX8MP HSIO blk-ctrl soc: imx: imx8m-blk-ctrl: set power device name soc: qcom: llcc: Add sc8180x and sc8280xp configurations dt-bindings: arm: msm: Add sc8180x and sc8280xp LLCC compatibles soc/tegra: pmc: Select REGMAP dt-bindings: reset: st,sti-powerdown: Convert to yaml dt-bindings: reset: st,sti-picophyreset: Convert to yaml dt-bindings: reset: socfpga: Convert to yaml dt-bindings: reset: snps,axs10x-reset: Convert to yaml ...

soc: rockchip: Fix refcount leak in rockchip_grf_init

2022-05-17T08:49:37+00:00

of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 4c58063d4258 ("soc: rockchip: add driver handling grf setup") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220516072013.19731-1-linmq006@gmail.com Signed-off-by: Heiko Stuebner

soc: rockchip: power-domain: Manage resource conflicts with firmware

2022-05-08T18:36:52+00:00

On RK3399 platforms, power domains are managed mostly by the kernel (drivers/soc/rockchip/pm_domains.c), but there are a few exceptions where ARM Trusted Firmware has to be involved: (1) system suspend/resume (2) DRAM DVFS (a.k.a., "ddrfreq") Exception (1) does not cause much conflict, since the kernel has quiesced itself by the time we make the relevant PSCI call. Exception (2) can cause conflict, because of two actions: (a) ARM Trusted Firmware needs to read/modify/write the PMU_BUS_IDLE_REQ register to idle the memory controller domain; the kernel driver also has to touch this register for other domains. (b) ARM Trusted Firmware needs to manage the clocks associated with these domains. To elaborate on (b): idling a power domain has always required ungating an array of clocks; see this old explanation from Rockchip: https://lore.kernel.org/linux-arm-kernel/54503C19.9060607@rock-chips.com/ Historically, ARM Trusted Firmware has avoided this issue by using a special PMU_CRU_GATEDIS_CON0 register -- this register ungates all the necessary clocks -- when idling the memory controller. Unfortunately, we've found that this register is not 100% sufficient; it does not turn the relevant PLLs on [0]. So it's possible to trigger issues with something like the following: 1. enable a power domain (e.g., RK3399_PD_VDU) -- kernel will temporarily enable relevant clocks/PLLs, then turn them back off 2. a PLL (e.g., PLL_NPLL) is part of the clock tree for RK3399_PD_VDU's clocks but otherwise unused; NPLL is disabled 3. perform a ddrfreq transition (rk3399_dmcfreq_target() -> ... drivers/clk/rockchip/clk-ddr.c / ROCKCHIP_SIP_DRAM_FREQ) 4. ARM Trusted Firmware unagates VDU clocks (via PMU_CRU_GATEDIS_CON0) 5. ARM Trusted firmware idles the memory controller domain 6. Step 5 waits on the VDU domain/clocks, but NPLL is still off i.e., we hang the system. So for (b), we need to at a minimum manage the relevant PLLs on behalf of firmware. It's easier to simply manage the whole clock tree, in a similar way we do in rockchip_pd_power(). For (a), we need to provide mutual exclusion betwen rockchip_pd_power() and firmware. To resolve that, we simply grab the PMU mutex and release it when ddrfreq is done. The Chromium OS kernel has been carrying versions of part of this hack for a while, based on some new custom notifiers [1]. I've rewritten as a simple function call between the drivers, which is OK because: * the PMU driver isn't enabled, and we don't have this problem at all (the firmware should have left us in an OK state, and there are no runtime conflicts); or * the PMU driver is present, and is a single instance. And the power-domain driver cannot be removed, so there's no lifetime management to worry about. For completeness, there's a 'dmc_pmu_mutex' to guard (likely theoretical?) probe()-time races. It's OK for the memory controller driver to start running before the PMU, because the PMU will avoid any critical actions during the block() sequence. [0] The RK3399 TRM for PMU_CRU_GATEDIS_CON0 only talks about ungating clocks. Based on experimentation, we've found that it does not power up the necessary PLLs. [1] CHROMIUM: soc: rockchip: power-domain: Add notifier to dmc driver https://chromium-review.googlesource.com/q/I242dbd706d352f74ff706f5cbf42ebb92f9bcc60 Notably, the Chromium solution only handled conflict (a), not (b). In practice, item (b) wasn't a problem in many cases because we never managed to fully power off PLLs. Now that the (upstream) video decoder driver performs runtime clock management, we often power off NPLL. Signed-off-by: Brian Norris Tested-by: Peter Geis Reviewed-by: Heiko Stuebner Signed-off-by: Chanwoo Choi

soc: rockchip: power-domain: Replace dsb() with smb()

2022-04-30T13:06:14+00:00

It's unclear if these are really needed at all, but seemingly their purpose is only as a write barrier. Use the general macro instead of the ARM-specific one. This driver is partially marked for COMPILE_TEST'ing, but it doesn't build under non-ARM architectures. Fix this up before *really* enabling it for COMPILE_TEST. Signed-off-by: Brian Norris Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20220426014545.628100-2-briannorris@chromium.org Signed-off-by: Heiko Stuebner