linux.git/drivers/soc/rockchip, branch v6.5

soc: rockchip: dtpm: use C99 array init syntax

2023-06-11T20:38:04+00:00

Eliminate sparse warnings in soc/rockchip/dtpm.c:

drivers/soc/rockchip/dtpm.c:15:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:17:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:20:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:23:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:26:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:29:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:32:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:35:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:38:12: sparse: warning: obsolete array initializer, use C99 syntax
drivers/soc/rockchip/dtpm.c:41:12: sparse: warning: obsolete array initializer, use C99 syntax

Fixes: b9d6c47a2be8 ("rockchip/soc/drivers: Add DTPM description for rk3399")
Signed-off-by: Randy Dunlap 
Cc: Daniel Lezcano 
Cc: Heiko Stuebner 
Cc: linux-rockchip@lists.infradead.org
Acked-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20230501024950.31518-1-rdunlap@infradead.org
Signed-off-by: Heiko Stuebner

soc: rockchip: power-domain: add rk3588 mem module support

2023-05-07T21:47:02+00:00

On RK3588 it's also possible to power down the memory used by the
particular power domains via PMU_MEM_PWR_GATE_SFTCON. This adds
support for this feature.

Tested-by: Vincent Legoll 
Co-Developed-by: Finley Xiao 
Signed-off-by: Finley Xiao 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sebastian Reichel 
Link: https://lore.kernel.org/r/20230403193250.108693-3-sebastian.reichel@collabora.com
Signed-off-by: Heiko Stuebner

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