linux-toradex.git/drivers/thermal/rockchip_thermal.c, branch v6.18

thermal/drivers/rockchip: Shut up GRF warning

2025-09-25T20:11:00+00:00

Most of the recent Rockchip devices do not have a GRF associated
with the tsadc IP. Let's avoid printing a warning on those devices.

Signed-off-by: Sebastian Reichel 
Reviewed-by: Dragan Simic 
Tested-by: Diederik de Haas 
Reviewed-by: Heiko Stuebner 
Link: https://lore.kernel.org/r/20250820-thermal-rockchip-grf-warning-v2-2-c7e2d35017b8@kernel.org
Signed-off-by: Daniel Lezcano

thermal/drivers/rockchip: Unify struct rockchip_tsadc_chip format

2025-09-25T20:11:00+00:00

Unify all chip descriptions to the version without any empty
lines.

Suggested-by: Heiko Stuebner 
Signed-off-by: Sebastian Reichel 
Reviewed-by: Dragan Simic 
Reviewed-by: Heiko Stuebner 
Link: https://lore.kernel.org/r/20250820-thermal-rockchip-grf-warning-v2-1-c7e2d35017b8@kernel.org
Signed-off-by: Daniel Lezcano

thermal/drivers/rockchip: Support reading trim values from OTP

2025-07-16T20:11:27+00:00

Many of the Rockchip SoCs support storing trim values for the sensors in
factory programmable memory. These values specify a fixed offset from
the sensor's returned temperature to get a more accurate picture of what
temperature the silicon is actually at.

The way this is implemented is with various OTP cells, which may be
absent. There may both be whole-TSADC trim values, as well as per-sensor
trim values.

In the downstream driver, whole-chip trim values override the per-sensor
trim values. This rewrite of the functionality changes the semantics to
something I see as slightly more useful: allow the whole-chip trim
values to serve as a fallback for lacking per-sensor trim values,
instead of overriding already present sensor trim values.

Additionally, the chip may specify an offset (trim_base, trim_base_frac)
in degrees celsius and degrees decicelsius respectively which defines
what the basis is from which the trim, if any, should be calculated
from. By default, this is 30 degrees Celsius, but the chip can once
again specify a different value through OTP cells.

The implementation of these trim calculations have been tested
extensively on an RK3576, where it was confirmed to get rid of pesky 1.8
degree Celsius offsets between certain sensors.

Signed-off-by: Nicolas Frattaroli 
Link: https://lore.kernel.org/r/20250610-rk3576-tsadc-upstream-v6-5-b6e9efbf1015@collabora.com
Signed-off-by: Daniel Lezcano

thermal/drivers/rockchip: Support RK3576 SoC in the thermal driver

2025-07-16T20:11:19+00:00

The RK3576 SoC has six TS-ADC channels: TOP, BIG_CORE, LITTLE_CORE,
DDR, NPU and GPU.

Signed-off-by: Ye Zhang 
[ported to mainline, reworded commit message]
Signed-off-by: Nicolas Frattaroli 
Reviewed-by: Heiko Stuebner 
Link: https://lore.kernel.org/r/20250610-rk3576-tsadc-upstream-v6-3-b6e9efbf1015@collabora.com
Signed-off-by: Daniel Lezcano

thermal/drivers/rockchip: Rename rk_tsadcv3_tshut_mode

2025-07-16T20:11:10+00:00

The "v" version specifier here refers to the hardware IP revision.
Mainline deviated from downstream here by calling the v4 revision v3 as
it didn't support the v3 hardware revision at all.

This creates needless confusion, so rename it to rk_tsadcv4_tshut_mode
to be consistent with what the hardware wants to be called.

Signed-off-by: Nicolas Frattaroli 
Reviewed-by: Heiko Stuebner 
Link: https://lore.kernel.org/r/20250610-rk3576-tsadc-upstream-v6-1-b6e9efbf1015@collabora.com
Signed-off-by: Daniel Lezcano

thermal/drivers/rockchip: Add missing rk3328 mapping entry

2025-03-25T19:52:04+00:00

The mapping table for the rk3328 is missing the entry for -25C which is
found in the TRM section 9.5.2 "Temperature-to-code mapping".

NOTE: the kernel uses the tsadc_q_sel=1'b1 mode which is defined as:
      4096-. Whereas the table in the TRM gives the code
      "3774" for -25C, the kernel uses 4096-3774=322.

[Dragan Simic] : "After going through the RK3308 and RK3328 TRMs, as
  well as through the downstream kernel code, it seems we may have
  some troubles at our hands.  Let me explain, please.

  To sum it up, part 1 of the RK3308 TRM v1.1 says on page 538 that
  the equation for the output when tsadc_q_sel equals 1 is (4096 -
  tsadc_q), while part 1 of the RK3328 TRM v1.2 says that the output
  equation is (1024 - tsadc_q) in that case.

  The downstream kernel code, however, treats the RK3308 and RK3328
  tables and their values as being the same.  It even mentions 1024 as
  the "offset" value in a comment block for the rk_tsadcv3_control()
  function, just like the upstream code does, which is obviously wrong
  "offset" value when correlated with the table on page 544 of part 1
  of the RK3308 TRM v1.1.

  With all this in mind, it's obvious that more work is needed to make
  it clear where's the actual mistake (it could be that the TRM is
  wrong), which I'll volunteer for as part of the SoC binning project.
  In the meantime, this patch looks fine as-is to me, by offering
  what's a clear improvement to the current state of the upstream
  code"

Link: https://opensource.rock-chips.com/images/9/97/Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf
Cc: stable@vger.kernel.org
Fixes: eda519d5f73e ("thermal: rockchip: Support the RK3328 SOC in thermal driver")
Signed-off-by: Trevor Woerner 
Reviewed-by: Dragan Simic 
Link: https://lore.kernel.org/r/20250207175048.35959-1-twoerner@gmail.com
Signed-off-by: Daniel Lezcano



thermal: Switch back to struct platform_driver::remove()
2024-11-13T15:17:57+00:00

After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.

Convert all platform drivers below drivers/thermal to use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.

On the way make a few whitespace changes to make indention consistent.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20241019163412.304422-2-u.kleine-koenig@baylibre.com
Signed-off-by: Daniel Lezcano 




thermal: rockchip: Convert to platform remove callback returning void
2023-10-02T12:23:30+00:00

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
Acked-by: Daniel Lezcano 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Rafael J. Wysocki 




thermal/drivers/rockchip: use devm_reset_control_array_get_exclusive()
2023-04-07T08:31:33+00:00

Switch devm_reset_control_array_get() to
devm_reset_control_array_get_exclusive().

Signed-off-by: Ye Xingchen 
Reviewed-by: Philipp Zabel 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/202303241108553006227@zte.com.cn




thermal/drivers/rockchip: Support RK3588 SoC in the thermal driver
2023-04-07T08:31:33+00:00

The RK3588 SoC has seven temperature sensor ADC channels:

- Chip Center
- CPU Cluster 1 (Dual A76 "Big" Cores)
- CPU Cluster 2 (Dual A76 "Big" Cores)
- CPU Cluster 0 (Quad A55 "Little" Cores)
- Power Domain Center
- Graphics Processing Unit
- Neural Processing Unit

Signed-off-by: Finley Xiao 
[rebase, squash fixes]
Reviewed-by: Heiko Stuebner 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20230308112253.15659-7-sebastian.reichel@collabora.com