[v5,0/8] RK3588 and Rock 5B dts additions: thermal, OPP and fan

Message

Alexey Charkov June 17, 2024, 6:28 p.m. UTC

This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
active cooling on Radxa Rock 5B via the provided PWM fan.

Some RK3588 boards use separate regulators to supply CPUs and their
respective memory interfaces, so this is handled by coupling those
regulators in affected boards' device trees to ensure that their
voltage is adjusted in step.

This also enables the built-in thermal sensor (TSADC) for all boards
that don't currently have it enabled, using the default CRU based
emergency thermal reset. This default configuration only uses on-SoC
devices and doesn't rely on any external wiring, thus it should work
for all devices (tested only on Rock 5B though).

The boards that have TSADC_SHUT signal wired to the PMIC reset line
can choose to override the default reset logic in favour of GPIO
driven (PMIC assisted) reset, but in my testing it didn't work on
Radxa Rock 5B - maybe I'm reading the schematic wrong and it doesn't
support PMIC assisted reset after all.

Fan control on Rock 5B has been split into two intervals: let it spin
at the minimum cooling state between 55C and 65C, and then accelerate
if the system crosses the 65C mark - thanks to Dragan for suggesting.
This lets some cooling setups with beefier heatsinks and/or larger
fan fins to stay in the quietest non-zero fan state while still
gaining potential benefits from the airflow it generates, and
possibly avoiding noisy speeds altogether for some workloads.

OPPs help actually scale CPU frequencies up and down for both cooling
and performance - tested on Rock 5B under varied loads. I've dropped
those OPPs that cause frequency reductions without accompanying decrease
in CPU voltage, as they don't seem to be adding much benefit in day to
day use, while the kernel log gets a number of "OPP is inefficient" lines.

Note that this submission doesn't touch the SRAM read margin updates or
the OPP calibration based on silicon quality which the downstream driver
does and which were mentioned in [1]. It works as it is (also confirmed by
Sebastian in his follow-up message [2]), and it is stable in my testing on
Rock 5B, so it sounds better to merge a simple version first and then
extend when/if required.

This patch series has been rebased on top of Heiko's recent for-next branch
with Dragan's patch [3] which rearranges the .dtsi files for per-variant OPPs.
As a result, it now includes separate CPU OPP tables for RK3588(s) and RK3588j.

GPU OPPs have also been split out to accommodate for the difference in RK3588j.

[1] https://lore.kernel.org/linux-rockchip/CABjd4YzTL=5S7cS8ACNAYVa730WA3iGd5L_wP1Vn9=[e-mail]/
[2] https://lore.kernel.org/linux-rockchip/pkyne4g2cln27dcdu3jm7bqdqpmd2kwkbguiolmozntjuiajrb@gvq4nupzna4o/
[3] https://lore.kernel.org/linux-rockchip/[e-mail]/

Signed-off-by: Alexey Charkov <[e-mail]>
---
Changes in v5:
- Rebased against linux-rockchip/for-next with Dragan's .dtsi reshuffling on top
- Added separate OPP values for RK3588j (these also apply to RK3588m)
- Separated GPU OPP values for RK3588j (RK3588m ones differ slightly, not included here)
- Dragan's patch: https://lore.kernel.org/linux-rockchip/[e-mail]/
- Link to v4: https://lore.kernel.org/r/[e-mail]

Changes in v4:
- Rebased against linux-rockchip/for-next
- Reordered DT nodes alphabetically as pointed out by Diederik
- Moved the TSADC enablement to per-board .dts/.dtsi files
- Dropped extra "inefficient" OPPs (same voltage - lower frequencies)
- Dropped second passive cooling trips altogether to keep things simple
- Added a cooling map for passive GPU cooling (in a separate patch)
- Link to v3: https://lore.kernel.org/r/[e-mail]

Changes in v3:
- Added regulator coupling for EVB1 and QuartzPro64
- Enabled the TSADC for all boards in .dtsi, not just Rock 5B (thanks ChenYu)
- Added comments regarding two passive cooling trips in each zone (thanks Dragan)
- Fixed active cooling map numbering for Radxa Rock 5B (thanks Dragan)
- Dropped Daniel's Acked-by tag from the Rock 5B fan patch, as there's been quite some
  churn there since the version he acknowledged
- Link to v2: https://lore.kernel.org/r/[e-mail]

Changes in v2:
- Dropped the rfkill patch which Heiko has already applied
- Set higher 'polling-delay-passive' (100 instead of 20)
- Name all cooling maps starting from map0 in each respective zone
- Drop 'contribution' properties from passive cooling maps
- Link to v1: https://lore.kernel.org/r/[e-mail]

---
Alexey Charkov (8):
      arm64: dts: rockchip: add thermal zones information on RK3588
      arm64: dts: rockchip: enable thermal management on all RK3588 boards
      arm64: dts: rockchip: add passive GPU cooling on RK3588
      arm64: dts: rockchip: enable automatic fan control on Rock 5B
      arm64: dts: rockchip: Add CPU/memory regulator coupling for RK3588
      arm64: dts: rockchip: Add OPP data for CPU cores on RK3588
      arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
      arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j

 .../boot/dts/rockchip/rk3588-armsom-sige7.dts      |   4 +
 arch/arm64/boot/dts/rockchip/rk3588-base.dtsi      | 197 +++++++++++++++++----
 .../dts/rockchip/rk3588-edgeble-neu6a-common.dtsi  |   4 +
 arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts   |  16 ++
 arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts   |   4 +
 arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi       | 190 ++++++++++++++++++++
 .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |  12 ++
 arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts    |  34 +++-
 .../arm64/boot/dts/rockchip/rk3588-toybrick-x0.dts |   4 +
 .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |   4 +
 arch/arm64/boot/dts/rockchip/rk3588.dtsi           |   1 +
 arch/arm64/boot/dts/rockchip/rk3588j.dtsi          | 141 +++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts   |   4 +
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi          |   1 +
 14 files changed, 577 insertions(+), 39 deletions(-)
---
base-commit: 5cc74606bf40a2bbaccd3e3bb2781f637baebde5
change-id: 20240124-rk-dts-additions-a6d7b52787b9

Best regards,

Comments

Dragan Simic June 17, 2024, 6:56 p.m. UTC | #1

Hello Alexey,

On 2024-06-17 20:28, Alexey Charkov wrote:
> This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
> active cooling on Radxa Rock 5B via the provided PWM fan.
> 
> Some RK3588 boards use separate regulators to supply CPUs and their
> respective memory interfaces, so this is handled by coupling those
> regulators in affected boards' device trees to ensure that their
> voltage is adjusted in step.
> 
> This also enables the built-in thermal sensor (TSADC) for all boards
> that don't currently have it enabled, using the default CRU based
> emergency thermal reset. This default configuration only uses on-SoC
> devices and doesn't rely on any external wiring, thus it should work
> for all devices (tested only on Rock 5B though).
> 
> The boards that have TSADC_SHUT signal wired to the PMIC reset line
> can choose to override the default reset logic in favour of GPIO
> driven (PMIC assisted) reset, but in my testing it didn't work on
> Radxa Rock 5B - maybe I'm reading the schematic wrong and it doesn't
> support PMIC assisted reset after all.
> 
> Fan control on Rock 5B has been split into two intervals: let it spin
> at the minimum cooling state between 55C and 65C, and then accelerate
> if the system crosses the 65C mark - thanks to Dragan for suggesting.
> This lets some cooling setups with beefier heatsinks and/or larger
> fan fins to stay in the quietest non-zero fan state while still
> gaining potential benefits from the airflow it generates, and
> possibly avoiding noisy speeds altogether for some workloads.

I should be able to test an RK3588 cooling setup with a really beefy
heatsink in the near future, so we'll see how well the "silent zone"
performs in practice and not just in theory. :)

> OPPs help actually scale CPU frequencies up and down for both cooling
> and performance - tested on Rock 5B under varied loads. I've dropped
> those OPPs that cause frequency reductions without accompanying 
> decrease
> in CPU voltage, as they don't seem to be adding much benefit in day to
> day use, while the kernel log gets a number of "OPP is inefficient" 
> lines.
> 
> Note that this submission doesn't touch the SRAM read margin updates or
> the OPP calibration based on silicon quality which the downstream 
> driver
> does and which were mentioned in [1]. It works as it is (also confirmed 
> by
> Sebastian in his follow-up message [2]), and it is stable in my testing 
> on
> Rock 5B, so it sounds better to merge a simple version first and then
> extend when/if required.
> 
> This patch series has been rebased on top of Heiko's recent for-next 
> branch
> with Dragan's patch [3] which rearranges the .dtsi files for 
> per-variant OPPs.
> As a result, it now includes separate CPU OPP tables for RK3588(s) and 
> RK3588j.

Thanks for the current iteration of this series!  I'll review it
in detail and perform thorough stress testing on my ROCK 5B as soon
as possible.

> GPU OPPs have also been split out to accommodate for the difference in 
> RK3588j.
> 
> [1] 
> https://lore.kernel.org/linux-rockchip/CABjd4YzTL=5S7cS8ACNAYVa730WA3iGd5L_wP1Vn9=[e-mail]/
> [2] 
> https://lore.kernel.org/linux-rockchip/pkyne4g2cln27dcdu3jm7bqdqpmd2kwkbguiolmozntjuiajrb@gvq4nupzna4o/
> [3] 
> https://lore.kernel.org/linux-rockchip/[e-mail]/
> 
> Signed-off-by: Alexey Charkov <[e-mail]>
> ---
> Changes in v5:
> - Rebased against linux-rockchip/for-next with Dragan's .dtsi 
> reshuffling on top
> - Added separate OPP values for RK3588j (these also apply to RK3588m)
> - Separated GPU OPP values for RK3588j (RK3588m ones differ slightly,
> not included here)
> - Dragan's patch:
> https://lore.kernel.org/linux-rockchip/[e-mail]/
> - Link to v4:
> https://lore.kernel.org/r/[e-mail]
> 
> Changes in v4:
> - Rebased against linux-rockchip/for-next
> - Reordered DT nodes alphabetically as pointed out by Diederik
> - Moved the TSADC enablement to per-board .dts/.dtsi files
> - Dropped extra "inefficient" OPPs (same voltage - lower frequencies)
> - Dropped second passive cooling trips altogether to keep things simple
> - Added a cooling map for passive GPU cooling (in a separate patch)
> - Link to v3:
> https://lore.kernel.org/r/[e-mail]
> 
> Changes in v3:
> - Added regulator coupling for EVB1 and QuartzPro64
> - Enabled the TSADC for all boards in .dtsi, not just Rock 5B (thanks 
> ChenYu)
> - Added comments regarding two passive cooling trips in each zone
> (thanks Dragan)
> - Fixed active cooling map numbering for Radxa Rock 5B (thanks Dragan)
> - Dropped Daniel's Acked-by tag from the Rock 5B fan patch, as there's
> been quite some
>   churn there since the version he acknowledged
> - Link to v2:
> https://lore.kernel.org/r/[e-mail]
> 
> Changes in v2:
> - Dropped the rfkill patch which Heiko has already applied
> - Set higher 'polling-delay-passive' (100 instead of 20)
> - Name all cooling maps starting from map0 in each respective zone
> - Drop 'contribution' properties from passive cooling maps
> - Link to v1:
> https://lore.kernel.org/r/[e-mail]
> 
> ---
> Alexey Charkov (8):
>       arm64: dts: rockchip: add thermal zones information on RK3588
>       arm64: dts: rockchip: enable thermal management on all RK3588 
> boards
>       arm64: dts: rockchip: add passive GPU cooling on RK3588
>       arm64: dts: rockchip: enable automatic fan control on Rock 5B
>       arm64: dts: rockchip: Add CPU/memory regulator coupling for 
> RK3588
>       arm64: dts: rockchip: Add OPP data for CPU cores on RK3588
>       arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
>       arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j
> 
>  .../boot/dts/rockchip/rk3588-armsom-sige7.dts      |   4 +
>  arch/arm64/boot/dts/rockchip/rk3588-base.dtsi      | 197 
> +++++++++++++++++----
>  .../dts/rockchip/rk3588-edgeble-neu6a-common.dtsi  |   4 +
>  arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts   |  16 ++
>  arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts   |   4 +
>  arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi       | 190 
> ++++++++++++++++++++
>  .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |  12 ++
>  arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts    |  34 +++-
>  .../arm64/boot/dts/rockchip/rk3588-toybrick-x0.dts |   4 +
>  .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |   4 +
>  arch/arm64/boot/dts/rockchip/rk3588.dtsi           |   1 +
>  arch/arm64/boot/dts/rockchip/rk3588j.dtsi          | 141 
> +++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts   |   4 +
>  arch/arm64/boot/dts/rockchip/rk3588s.dtsi          |   1 +
>  14 files changed, 577 insertions(+), 39 deletions(-)
> ---
> base-commit: 5cc74606bf40a2bbaccd3e3bb2781f637baebde5
> change-id: 20240124-rk-dts-additions-a6d7b52787b9
> 
> Best regards,

Heiko Stübner June 20, 2024, 8:39 p.m. UTC | #2

On Mon, 17 Jun 2024 22:28:50 +0400, Alexey Charkov wrote:
> This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
> active cooling on Radxa Rock 5B via the provided PWM fan.
> 
> Some RK3588 boards use separate regulators to supply CPUs and their
> respective memory interfaces, so this is handled by coupling those
> regulators in affected boards' device trees to ensure that their
> voltage is adjusted in step.
> 
> [...]

Applied, thanks!

[1/8] arm64: dts: rockchip: add thermal zones information on RK3588
      commit: 97d61227d6bb0023a325ab2f87e4438a858207a2
[2/8] arm64: dts: rockchip: enable thermal management on all RK3588 boards
      commit: 4afa9056ed9e3d9ff036f3576cb137a011448295
[3/8] arm64: dts: rockchip: add passive GPU cooling on RK3588
      commit: d64d337f1856bd0e5cbfc60b6f0458ad4951d05e
[4/8] arm64: dts: rockchip: enable automatic fan control on Rock 5B
      commit: 2aab8905a843aef624565c014a34d155f8702135


Don't worry, I'll look at the other patches too.
Was just easier on my mind to this in blocks ;-) .


Best regards,

Alexey Charkov June 21, 2024, 6:15 a.m. UTC | #3

On Fri, Jun 21, 2024 at 12:40 AM Heiko Stuebner <[e-mail]> wrote:
>
> On Mon, 17 Jun 2024 22:28:50 +0400, Alexey Charkov wrote:
> > This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
> > active cooling on Radxa Rock 5B via the provided PWM fan.
> >
> > Some RK3588 boards use separate regulators to supply CPUs and their
> > respective memory interfaces, so this is handled by coupling those
> > regulators in affected boards' device trees to ensure that their
> > voltage is adjusted in step.
> >
> > [...]
>
> Applied, thanks!
>
> [1/8] arm64: dts: rockchip: add thermal zones information on RK3588
>       commit: 97d61227d6bb0023a325ab2f87e4438a858207a2
> [2/8] arm64: dts: rockchip: enable thermal management on all RK3588 boards
>       commit: 4afa9056ed9e3d9ff036f3576cb137a011448295
> [3/8] arm64: dts: rockchip: add passive GPU cooling on RK3588
>       commit: d64d337f1856bd0e5cbfc60b6f0458ad4951d05e
> [4/8] arm64: dts: rockchip: enable automatic fan control on Rock 5B
>       commit: 2aab8905a843aef624565c014a34d155f8702135
>
>
> Don't worry, I'll look at the other patches too.
> Was just easier on my mind to this in blocks ;-) .

Great, thanks a lot Heiko!

Best regards,
Alexey

Heiko Stübner June 24, 2024, 4:20 p.m. UTC | #4

On Mon, 17 Jun 2024 22:28:50 +0400, Alexey Charkov wrote:
> This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
> active cooling on Radxa Rock 5B via the provided PWM fan.
> 
> Some RK3588 boards use separate regulators to supply CPUs and their
> respective memory interfaces, so this is handled by coupling those
> regulators in affected boards' device trees to ensure that their
> voltage is adjusted in step.
> 
> [...]

Applied, thanks!

[5/8] arm64: dts: rockchip: Add CPU/memory regulator coupling for RK3588
      commit: 0ba0560982bc8d0c3fb3ca209fd0ed29f81402ac
[6/8] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588
      commit: 276856db91b46eaa7a4c19226c096a9dc899a3e9
[7/8] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
      commit: 667885a6865832eb0678c7e02e47a3392f177ecb
[8/8] arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j
      commit: a7b2070505a2a09ea65fa0c8c480c97f62d1978d

Best regards,

Piotr Oniszczuk July 7, 2024, 9:39 a.m. UTC | #5

Alexey,
I’m playing with this series on rock5c on 6.10-rc6.

Is code in this series enough to get working pwm-fan on rock5c?
(of course after adding required changes from rokc5b dts to rock5c dts)

In my case i’m getting constantly full speed of fan on my rock5c.

hw seems ok as echo 96 > /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1 changes fans speed as expected.

May you pls hint me what i’m missing here?
 

> Wiadomość napisana przez Alexey Charkov <[e-mail]> w dniu 17.06.2024, o godz. 20:28:
> 
> This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
> active cooling on Radxa Rock 5B via the provided PWM fan.
> 
> Some RK3588 boards use separate regulators to supply CPUs and their
> respective memory interfaces, so this is handled by coupling those
> regulators in affected boards' device trees to ensure that their
> voltage is adjusted in step.
> 
> This also enables the built-in thermal sensor (TSADC) for all boards
> that don't currently have it enabled, using the default CRU based
> emergency thermal reset. This default configuration only uses on-SoC
> devices and doesn't rely on any external wiring, thus it should work
> for all devices (tested only on Rock 5B though).
> 
> The boards that have TSADC_SHUT signal wired to the PMIC reset line
> can choose to override the default reset logic in favour of GPIO
> driven (PMIC assisted) reset, but in my testing it didn't work on
> Radxa Rock 5B - maybe I'm reading the schematic wrong and it doesn't
> support PMIC assisted reset after all.
> 
> Fan control on Rock 5B has been split into two intervals: let it spin
> at the minimum cooling state between 55C and 65C, and then accelerate
> if the system crosses the 65C mark - thanks to Dragan for suggesting.
> This lets some cooling setups with beefier heatsinks and/or larger
> fan fins to stay in the quietest non-zero fan state while still
> gaining potential benefits from the airflow it generates, and
> possibly avoiding noisy speeds altogether for some workloads.
> 
> OPPs help actually scale CPU frequencies up and down for both cooling
> and performance - tested on Rock 5B under varied loads. I've dropped
> those OPPs that cause frequency reductions without accompanying decrease
> in CPU voltage, as they don't seem to be adding much benefit in day to
> day use, while the kernel log gets a number of "OPP is inefficient" lines.
> 
> Note that this submission doesn't touch the SRAM read margin updates or
> the OPP calibration based on silicon quality which the downstream driver
> does and which were mentioned in [1]. It works as it is (also confirmed by
> Sebastian in his follow-up message [2]), and it is stable in my testing on
> Rock 5B, so it sounds better to merge a simple version first and then
> extend when/if required.
> 
> This patch series has been rebased on top of Heiko's recent for-next branch
> with Dragan's patch [3] which rearranges the .dtsi files for per-variant OPPs.
> As a result, it now includes separate CPU OPP tables for RK3588(s) and RK3588j.
> 
> GPU OPPs have also been split out to accommodate for the difference in RK3588j.
> 
> [1] https://lore.kernel.org/linux-rockchip/CABjd4YzTL=5S7cS8ACNAYVa730WA3iGd5L_wP1Vn9=[e-mail]/
> [2] https://lore.kernel.org/linux-rockchip/pkyne4g2cln27dcdu3jm7bqdqpmd2kwkbguiolmozntjuiajrb@gvq4nupzna4o/
> [3] https://lore.kernel.org/linux-rockchip/[e-mail]/
> 
> Signed-off-by: Alexey Charkov <[e-mail]>
> ---
> Changes in v5:
> - Rebased against linux-rockchip/for-next with Dragan's .dtsi reshuffling on top
> - Added separate OPP values for RK3588j (these also apply to RK3588m)
> - Separated GPU OPP values for RK3588j (RK3588m ones differ slightly, not included here)
> - Dragan's patch: https://lore.kernel.org/linux-rockchip/[e-mail]/
> - Link to v4: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v4:
> - Rebased against linux-rockchip/for-next
> - Reordered DT nodes alphabetically as pointed out by Diederik
> - Moved the TSADC enablement to per-board .dts/.dtsi files
> - Dropped extra "inefficient" OPPs (same voltage - lower frequencies)
> - Dropped second passive cooling trips altogether to keep things simple
> - Added a cooling map for passive GPU cooling (in a separate patch)
> - Link to v3: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v3:
> - Added regulator coupling for EVB1 and QuartzPro64
> - Enabled the TSADC for all boards in .dtsi, not just Rock 5B (thanks ChenYu)
> - Added comments regarding two passive cooling trips in each zone (thanks Dragan)
> - Fixed active cooling map numbering for Radxa Rock 5B (thanks Dragan)
> - Dropped Daniel's Acked-by tag from the Rock 5B fan patch, as there's been quite some
>  churn there since the version he acknowledged
> - Link to v2: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v2:
> - Dropped the rfkill patch which Heiko has already applied
> - Set higher 'polling-delay-passive' (100 instead of 20)
> - Name all cooling maps starting from map0 in each respective zone
> - Drop 'contribution' properties from passive cooling maps
> - Link to v1: https://lore.kernel.org/r/[e-mail]
> 
> ---
> Alexey Charkov (8):
>      arm64: dts: rockchip: add thermal zones information on RK3588
>      arm64: dts: rockchip: enable thermal management on all RK3588 boards
>      arm64: dts: rockchip: add passive GPU cooling on RK3588
>      arm64: dts: rockchip: enable automatic fan control on Rock 5B
>      arm64: dts: rockchip: Add CPU/memory regulator coupling for RK3588
>      arm64: dts: rockchip: Add OPP data for CPU cores on RK3588
>      arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
>      arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j
> 
> .../boot/dts/rockchip/rk3588-armsom-sige7.dts      |   4 +
> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi      | 197 +++++++++++++++++----
> .../dts/rockchip/rk3588-edgeble-neu6a-common.dtsi  |   4 +
> arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts   |  16 ++
> arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts   |   4 +
> arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi       | 190 ++++++++++++++++++++
> .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |  12 ++
> arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts    |  34 +++-
> .../arm64/boot/dts/rockchip/rk3588-toybrick-x0.dts |   4 +
> .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |   4 +
> arch/arm64/boot/dts/rockchip/rk3588.dtsi           |   1 +
> arch/arm64/boot/dts/rockchip/rk3588j.dtsi          | 141 +++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts   |   4 +
> arch/arm64/boot/dts/rockchip/rk3588s.dtsi          |   1 +
> 14 files changed, 577 insertions(+), 39 deletions(-)
> ---
> base-commit: 5cc74606bf40a2bbaccd3e3bb2781f637baebde5
> change-id: 20240124-rk-dts-additions-a6d7b52787b9
> 
> Best regards,
> -- 
> Alexey Charkov <[e-mail]>
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> [e-mail]
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Heiko Stübner July 7, 2024, 11:11 a.m. UTC | #6

Hey,

Am Sonntag, 7. Juli 2024, 11:39:57 CEST schrieb Piotr Oniszczuk:
> Alexey,
> I’m playing with this series on rock5c on 6.10-rc6.
> 
> Is code in this series enough to get working pwm-fan on rock5c?
> (of course after adding required changes from rokc5b dts to rock5c dts)
> 
> In my case i’m getting constantly full speed of fan on my rock5c.
> 
> hw seems ok as echo 96 > /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1 changes fans speed as expected.
> 
> May you pls hint me what i’m missing here?

at least on my rock 5 itx patches, I get varying fan-speeds.
The fan starts high and then lowers its speed once the cpu-regulators
and every is set up.

While I was working on the dts and the cpu-supplies were not yet working,
the fan speed stayed high, so maybe check that frequency scaling actually
works? And of course you need the thermal map to handle the fan.

Also of course I don't see a rock5c patch anywhere, so where did that
board dts come from? 


Heiko

> > Wiadomość napisana przez Alexey Charkov <[e-mail]> w dniu 17.06.2024, o godz. 20:28:
> > 
> > This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
> > active cooling on Radxa Rock 5B via the provided PWM fan.
> > 
> > Some RK3588 boards use separate regulators to supply CPUs and their
> > respective memory interfaces, so this is handled by coupling those
> > regulators in affected boards' device trees to ensure that their
> > voltage is adjusted in step.
> > 
> > This also enables the built-in thermal sensor (TSADC) for all boards
> > that don't currently have it enabled, using the default CRU based
> > emergency thermal reset. This default configuration only uses on-SoC
> > devices and doesn't rely on any external wiring, thus it should work
> > for all devices (tested only on Rock 5B though).
> > 
> > The boards that have TSADC_SHUT signal wired to the PMIC reset line
> > can choose to override the default reset logic in favour of GPIO
> > driven (PMIC assisted) reset, but in my testing it didn't work on
> > Radxa Rock 5B - maybe I'm reading the schematic wrong and it doesn't
> > support PMIC assisted reset after all.
> > 
> > Fan control on Rock 5B has been split into two intervals: let it spin
> > at the minimum cooling state between 55C and 65C, and then accelerate
> > if the system crosses the 65C mark - thanks to Dragan for suggesting.
> > This lets some cooling setups with beefier heatsinks and/or larger
> > fan fins to stay in the quietest non-zero fan state while still
> > gaining potential benefits from the airflow it generates, and
> > possibly avoiding noisy speeds altogether for some workloads.
> > 
> > OPPs help actually scale CPU frequencies up and down for both cooling
> > and performance - tested on Rock 5B under varied loads. I've dropped
> > those OPPs that cause frequency reductions without accompanying decrease
> > in CPU voltage, as they don't seem to be adding much benefit in day to
> > day use, while the kernel log gets a number of "OPP is inefficient" lines.
> > 
> > Note that this submission doesn't touch the SRAM read margin updates or
> > the OPP calibration based on silicon quality which the downstream driver
> > does and which were mentioned in [1]. It works as it is (also confirmed by
> > Sebastian in his follow-up message [2]), and it is stable in my testing on
> > Rock 5B, so it sounds better to merge a simple version first and then
> > extend when/if required.
> > 
> > This patch series has been rebased on top of Heiko's recent for-next branch
> > with Dragan's patch [3] which rearranges the .dtsi files for per-variant OPPs.
> > As a result, it now includes separate CPU OPP tables for RK3588(s) and RK3588j.
> > 
> > GPU OPPs have also been split out to accommodate for the difference in RK3588j.
> > 
> > [1] https://lore.kernel.org/linux-rockchip/CABjd4YzTL=5S7cS8ACNAYVa730WA3iGd5L_wP1Vn9=[e-mail]/
> > [2] https://lore.kernel.org/linux-rockchip/pkyne4g2cln27dcdu3jm7bqdqpmd2kwkbguiolmozntjuiajrb@gvq4nupzna4o/
> > [3] https://lore.kernel.org/linux-rockchip/[e-mail]/
> > 
> > Signed-off-by: Alexey Charkov <[e-mail]>
> > ---
> > Changes in v5:
> > - Rebased against linux-rockchip/for-next with Dragan's .dtsi reshuffling on top
> > - Added separate OPP values for RK3588j (these also apply to RK3588m)
> > - Separated GPU OPP values for RK3588j (RK3588m ones differ slightly, not included here)
> > - Dragan's patch: https://lore.kernel.org/linux-rockchip/[e-mail]/
> > - Link to v4: https://lore.kernel.org/r/[e-mail]
> > 
> > Changes in v4:
> > - Rebased against linux-rockchip/for-next
> > - Reordered DT nodes alphabetically as pointed out by Diederik
> > - Moved the TSADC enablement to per-board .dts/.dtsi files
> > - Dropped extra "inefficient" OPPs (same voltage - lower frequencies)
> > - Dropped second passive cooling trips altogether to keep things simple
> > - Added a cooling map for passive GPU cooling (in a separate patch)
> > - Link to v3: https://lore.kernel.org/r/[e-mail]
> > 
> > Changes in v3:
> > - Added regulator coupling for EVB1 and QuartzPro64
> > - Enabled the TSADC for all boards in .dtsi, not just Rock 5B (thanks ChenYu)
> > - Added comments regarding two passive cooling trips in each zone (thanks Dragan)
> > - Fixed active cooling map numbering for Radxa Rock 5B (thanks Dragan)
> > - Dropped Daniel's Acked-by tag from the Rock 5B fan patch, as there's been quite some
> >  churn there since the version he acknowledged
> > - Link to v2: https://lore.kernel.org/r/[e-mail]
> > 
> > Changes in v2:
> > - Dropped the rfkill patch which Heiko has already applied
> > - Set higher 'polling-delay-passive' (100 instead of 20)
> > - Name all cooling maps starting from map0 in each respective zone
> > - Drop 'contribution' properties from passive cooling maps
> > - Link to v1: https://lore.kernel.org/r/[e-mail]
> > 
> > ---
> > Alexey Charkov (8):
> >      arm64: dts: rockchip: add thermal zones information on RK3588
> >      arm64: dts: rockchip: enable thermal management on all RK3588 boards
> >      arm64: dts: rockchip: add passive GPU cooling on RK3588
> >      arm64: dts: rockchip: enable automatic fan control on Rock 5B
> >      arm64: dts: rockchip: Add CPU/memory regulator coupling for RK3588
> >      arm64: dts: rockchip: Add OPP data for CPU cores on RK3588
> >      arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
> >      arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j
> > 
> > .../boot/dts/rockchip/rk3588-armsom-sige7.dts      |   4 +
> > arch/arm64/boot/dts/rockchip/rk3588-base.dtsi      | 197 +++++++++++++++++----
> > .../dts/rockchip/rk3588-edgeble-neu6a-common.dtsi  |   4 +
> > arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts   |  16 ++
> > arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts   |   4 +
> > arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi       | 190 ++++++++++++++++++++
> > .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |  12 ++
> > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts    |  34 +++-
> > .../arm64/boot/dts/rockchip/rk3588-toybrick-x0.dts |   4 +
> > .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |   4 +
> > arch/arm64/boot/dts/rockchip/rk3588.dtsi           |   1 +
> > arch/arm64/boot/dts/rockchip/rk3588j.dtsi          | 141 +++++++++++++++
> > arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts   |   4 +
> > arch/arm64/boot/dts/rockchip/rk3588s.dtsi          |   1 +
> > 14 files changed, 577 insertions(+), 39 deletions(-)
> > ---
> > base-commit: 5cc74606bf40a2bbaccd3e3bb2781f637baebde5
> > change-id: 20240124-rk-dts-additions-a6d7b52787b9
> > 
> > Best regards,
> 
>

Piotr Oniszczuk July 7, 2024, 12:37 p.m. UTC | #7

Heiko,
pls see inline

> Wiadomość napisana przez Heiko Stübner <[e-mail]> w dniu 07.07.2024, o godz. 13:11:
> 
> Hey,
> 
> Am Sonntag, 7. Juli 2024, 11:39:57 CEST schrieb Piotr Oniszczuk:
>> Alexey,
>> I’m playing with this series on rock5c on 6.10-rc6.
>> 
>> Is code in this series enough to get working pwm-fan on rock5c?
>> (of course after adding required changes from rokc5b dts to rock5c dts)
>> 
>> In my case i’m getting constantly full speed of fan on my rock5c.
>> 
>> hw seems ok as echo 96 > /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1 changes fans speed as expected.
>> 
>> May you pls hint me what i’m missing here?
> 
> at least on my rock 5 itx patches, I get varying fan-speeds.
> The fan starts high and then lowers its speed once the cpu-regulators
> and every is set up.

Ah - ok.
I verified and it looks there was typo from my side in dts fan stanza :-/
Now it works as expected :-)

Many thx for your time!

> 
> While I was working on the dts and the cpu-supplies were not yet working,
> the fan speed stayed high, so maybe check that frequency scaling actually
> works?
> And of course you need the thermal map to handle the fan. 

> 
> Also of course I don't see a rock5c patch anywhere, so where did that
> board dts come from? 

rock5c is my development: https://gist.github.com/warpme/6b2fa9004d8b28c0e43fa16b0b6595f3

> 
> 
> Heiko
> 
>>> Wiadomość napisana przez Alexey Charkov <[e-mail]> w dniu 17.06.2024, o godz. 20:28:
>>> 
>>> This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
>>> active cooling on Radxa Rock 5B via the provided PWM fan.
>>> 
>>> Some RK3588 boards use separate regulators to supply CPUs and their
>>> respective memory interfaces, so this is handled by coupling those
>>> regulators in affected boards' device trees to ensure that their
>>> voltage is adjusted in step.
>>> 
>>> This also enables the built-in thermal sensor (TSADC) for all boards
>>> that don't currently have it enabled, using the default CRU based
>>> emergency thermal reset. This default configuration only uses on-SoC
>>> devices and doesn't rely on any external wiring, thus it should work
>>> for all devices (tested only on Rock 5B though).
>>> 
>>> The boards that have TSADC_SHUT signal wired to the PMIC reset line
>>> can choose to override the default reset logic in favour of GPIO
>>> driven (PMIC assisted) reset, but in my testing it didn't work on
>>> Radxa Rock 5B - maybe I'm reading the schematic wrong and it doesn't
>>> support PMIC assisted reset after all.
>>> 
>>> Fan control on Rock 5B has been split into two intervals: let it spin
>>> at the minimum cooling state between 55C and 65C, and then accelerate
>>> if the system crosses the 65C mark - thanks to Dragan for suggesting.
>>> This lets some cooling setups with beefier heatsinks and/or larger
>>> fan fins to stay in the quietest non-zero fan state while still
>>> gaining potential benefits from the airflow it generates, and
>>> possibly avoiding noisy speeds altogether for some workloads.
>>> 
>>> OPPs help actually scale CPU frequencies up and down for both cooling
>>> and performance - tested on Rock 5B under varied loads. I've dropped
>>> those OPPs that cause frequency reductions without accompanying decrease
>>> in CPU voltage, as they don't seem to be adding much benefit in day to
>>> day use, while the kernel log gets a number of "OPP is inefficient" lines.
>>> 
>>> Note that this submission doesn't touch the SRAM read margin updates or
>>> the OPP calibration based on silicon quality which the downstream driver
>>> does and which were mentioned in [1]. It works as it is (also confirmed by
>>> Sebastian in his follow-up message [2]), and it is stable in my testing on
>>> Rock 5B, so it sounds better to merge a simple version first and then
>>> extend when/if required.
>>> 
>>> This patch series has been rebased on top of Heiko's recent for-next branch
>>> with Dragan's patch [3] which rearranges the .dtsi files for per-variant OPPs.
>>> As a result, it now includes separate CPU OPP tables for RK3588(s) and RK3588j.
>>> 
>>> GPU OPPs have also been split out to accommodate for the difference in RK3588j.
>>> 
>>> [1] https://lore.kernel.org/linux-rockchip/CABjd4YzTL=5S7cS8ACNAYVa730WA3iGd5L_wP1Vn9=[e-mail]/
>>> [2] https://lore.kernel.org/linux-rockchip/pkyne4g2cln27dcdu3jm7bqdqpmd2kwkbguiolmozntjuiajrb@gvq4nupzna4o/
>>> [3] https://lore.kernel.org/linux-rockchip/[e-mail]/
>>> 
>>> Signed-off-by: Alexey Charkov <[e-mail]>
>>> ---
>>> Changes in v5:
>>> - Rebased against linux-rockchip/for-next with Dragan's .dtsi reshuffling on top
>>> - Added separate OPP values for RK3588j (these also apply to RK3588m)
>>> - Separated GPU OPP values for RK3588j (RK3588m ones differ slightly, not included here)
>>> - Dragan's patch: https://lore.kernel.org/linux-rockchip/[e-mail]/
>>> - Link to v4: https://lore.kernel.org/r/[e-mail]
>>> 
>>> Changes in v4:
>>> - Rebased against linux-rockchip/for-next
>>> - Reordered DT nodes alphabetically as pointed out by Diederik
>>> - Moved the TSADC enablement to per-board .dts/.dtsi files
>>> - Dropped extra "inefficient" OPPs (same voltage - lower frequencies)
>>> - Dropped second passive cooling trips altogether to keep things simple
>>> - Added a cooling map for passive GPU cooling (in a separate patch)
>>> - Link to v3: https://lore.kernel.org/r/[e-mail]
>>> 
>>> Changes in v3:
>>> - Added regulator coupling for EVB1 and QuartzPro64
>>> - Enabled the TSADC for all boards in .dtsi, not just Rock 5B (thanks ChenYu)
>>> - Added comments regarding two passive cooling trips in each zone (thanks Dragan)
>>> - Fixed active cooling map numbering for Radxa Rock 5B (thanks Dragan)
>>> - Dropped Daniel's Acked-by tag from the Rock 5B fan patch, as there's been quite some
>>> churn there since the version he acknowledged
>>> - Link to v2: https://lore.kernel.org/r/[e-mail]
>>> 
>>> Changes in v2:
>>> - Dropped the rfkill patch which Heiko has already applied
>>> - Set higher 'polling-delay-passive' (100 instead of 20)
>>> - Name all cooling maps starting from map0 in each respective zone
>>> - Drop 'contribution' properties from passive cooling maps
>>> - Link to v1: https://lore.kernel.org/r/[e-mail]
>>> 
>>> ---
>>> Alexey Charkov (8):
>>>     arm64: dts: rockchip: add thermal zones information on RK3588
>>>     arm64: dts: rockchip: enable thermal management on all RK3588 boards
>>>     arm64: dts: rockchip: add passive GPU cooling on RK3588
>>>     arm64: dts: rockchip: enable automatic fan control on Rock 5B
>>>     arm64: dts: rockchip: Add CPU/memory regulator coupling for RK3588
>>>     arm64: dts: rockchip: Add OPP data for CPU cores on RK3588
>>>     arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
>>>     arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j
>>> 
>>> .../boot/dts/rockchip/rk3588-armsom-sige7.dts      |   4 +
>>> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi      | 197 +++++++++++++++++----
>>> .../dts/rockchip/rk3588-edgeble-neu6a-common.dtsi  |   4 +
>>> arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts   |  16 ++
>>> arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts   |   4 +
>>> arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi       | 190 ++++++++++++++++++++
>>> .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |  12 ++
>>> arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts    |  34 +++-
>>> .../arm64/boot/dts/rockchip/rk3588-toybrick-x0.dts |   4 +
>>> .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |   4 +
>>> arch/arm64/boot/dts/rockchip/rk3588.dtsi           |   1 +
>>> arch/arm64/boot/dts/rockchip/rk3588j.dtsi          | 141 +++++++++++++++
>>> arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts   |   4 +
>>> arch/arm64/boot/dts/rockchip/rk3588s.dtsi          |   1 +
>>> 14 files changed, 577 insertions(+), 39 deletions(-)
>>> ---
>>> base-commit: 5cc74606bf40a2bbaccd3e3bb2781f637baebde5
>>> change-id: 20240124-rk-dts-additions-a6d7b52787b9
>>> 
>>> Best regards,
>> 
>> 
> 
> 
> 
>

Piotr Oniszczuk July 7, 2024, 6:32 p.m. UTC | #8

Heiko, Alexey,

After some more tests: is varying fan-speeds working stable for you?

In my case - 1 per few reboots results with board enters state with: constant full speed and no any reaction for cpu temp.
In such state - I need multiple hw poweroffs (remove usb-c plug) to get fan-speeds working again.
When board is such state - all seems to work ok (frequency scaling, etc) except fan is constantly full speed…

Is it varying fan-speed working stable for you?
Maybe my issue is some kernel modules loading race?


> Wiadomość napisana przez Piotr Oniszczuk <[e-mail]> w dniu 07.07.2024, o godz. 14:37:
> 
> Heiko,
> pls see inline
> 
>> Wiadomość napisana przez Heiko Stübner <[e-mail]> w dniu 07.07.2024, o godz. 13:11:
>> 
>> Hey,
>> 
>> Am Sonntag, 7. Juli 2024, 11:39:57 CEST schrieb Piotr Oniszczuk:
>>> Alexey,
>>> I’m playing with this series on rock5c on 6.10-rc6.
>>> 
>>> Is code in this series enough to get working pwm-fan on rock5c?
>>> (of course after adding required changes from rokc5b dts to rock5c dts)
>>> 
>>> In my case i’m getting constantly full speed of fan on my rock5c.
>>> 
>>> hw seems ok as echo 96 > /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1 changes fans speed as expected.
>>> 
>>> May you pls hint me what i’m missing here?
>> 
>> at least on my rock 5 itx patches, I get varying fan-speeds.
>> The fan starts high and then lowers its speed once the cpu-regulators
>> and every is set up.
> 
> Ah - ok.
> I verified and it looks there was typo from my side in dts fan stanza :-/
> Now it works as expected :-)
> 
> Many thx for your time!
> 
>> 
>> While I was working on the dts and the cpu-supplies were not yet working,
>> the fan speed stayed high, so maybe check that frequency scaling actually
>> works?
>> And of course you need the thermal map to handle the fan. 
> 
>> 
>> Also of course I don't see a rock5c patch anywhere, so where did that
>> board dts come from? 
> 
> rock5c is my development: https://gist.github.com/warpme/6b2fa9004d8b28c0e43fa16b0b6595f3
> 
>> 
>> 
>> Heiko
>> 
>>>> Wiadomość napisana przez Alexey Charkov <[e-mail]> w dniu 17.06.2024, o godz. 20:28:
>>>> 
>>>> This enables thermal monitoring and CPU DVFS on RK3588(s), as well as
>>>> active cooling on Radxa Rock 5B via the provided PWM fan.
>>>> 
>>>> Some RK3588 boards use separate regulators to supply CPUs and their
>>>> respective memory interfaces, so this is handled by coupling those
>>>> regulators in affected boards' device trees to ensure that their
>>>> voltage is adjusted in step.
>>>> 
>>>> This also enables the built-in thermal sensor (TSADC) for all boards
>>>> that don't currently have it enabled, using the default CRU based
>>>> emergency thermal reset. This default configuration only uses on-SoC
>>>> devices and doesn't rely on any external wiring, thus it should work
>>>> for all devices (tested only on Rock 5B though).
>>>> 
>>>> The boards that have TSADC_SHUT signal wired to the PMIC reset line
>>>> can choose to override the default reset logic in favour of GPIO
>>>> driven (PMIC assisted) reset, but in my testing it didn't work on
>>>> Radxa Rock 5B - maybe I'm reading the schematic wrong and it doesn't
>>>> support PMIC assisted reset after all.
>>>> 
>>>> Fan control on Rock 5B has been split into two intervals: let it spin
>>>> at the minimum cooling state between 55C and 65C, and then accelerate
>>>> if the system crosses the 65C mark - thanks to Dragan for suggesting.
>>>> This lets some cooling setups with beefier heatsinks and/or larger
>>>> fan fins to stay in the quietest non-zero fan state while still
>>>> gaining potential benefits from the airflow it generates, and
>>>> possibly avoiding noisy speeds altogether for some workloads.
>>>> 
>>>> OPPs help actually scale CPU frequencies up and down for both cooling
>>>> and performance - tested on Rock 5B under varied loads. I've dropped
>>>> those OPPs that cause frequency reductions without accompanying decrease
>>>> in CPU voltage, as they don't seem to be adding much benefit in day to
>>>> day use, while the kernel log gets a number of "OPP is inefficient" lines.
>>>> 
>>>> Note that this submission doesn't touch the SRAM read margin updates or
>>>> the OPP calibration based on silicon quality which the downstream driver
>>>> does and which were mentioned in [1]. It works as it is (also confirmed by
>>>> Sebastian in his follow-up message [2]), and it is stable in my testing on
>>>> Rock 5B, so it sounds better to merge a simple version first and then
>>>> extend when/if required.
>>>> 
>>>> This patch series has been rebased on top of Heiko's recent for-next branch
>>>> with Dragan's patch [3] which rearranges the .dtsi files for per-variant OPPs.
>>>> As a result, it now includes separate CPU OPP tables for RK3588(s) and RK3588j.
>>>> 
>>>> GPU OPPs have also been split out to accommodate for the difference in RK3588j.
>>>> 
>>>> [1] https://lore.kernel.org/linux-rockchip/CABjd4YzTL=5S7cS8ACNAYVa730WA3iGd5L_wP1Vn9=[e-mail]/
>>>> [2] https://lore.kernel.org/linux-rockchip/pkyne4g2cln27dcdu3jm7bqdqpmd2kwkbguiolmozntjuiajrb@gvq4nupzna4o/
>>>> [3] https://lore.kernel.org/linux-rockchip/[e-mail]/
>>>> 
>>>> Signed-off-by: Alexey Charkov <[e-mail]>
>>>> ---
>>>> Changes in v5:
>>>> - Rebased against linux-rockchip/for-next with Dragan's .dtsi reshuffling on top
>>>> - Added separate OPP values for RK3588j (these also apply to RK3588m)
>>>> - Separated GPU OPP values for RK3588j (RK3588m ones differ slightly, not included here)
>>>> - Dragan's patch: https://lore.kernel.org/linux-rockchip/[e-mail]/
>>>> - Link to v4: https://lore.kernel.org/r/[e-mail]
>>>> 
>>>> Changes in v4:
>>>> - Rebased against linux-rockchip/for-next
>>>> - Reordered DT nodes alphabetically as pointed out by Diederik
>>>> - Moved the TSADC enablement to per-board .dts/.dtsi files
>>>> - Dropped extra "inefficient" OPPs (same voltage - lower frequencies)
>>>> - Dropped second passive cooling trips altogether to keep things simple
>>>> - Added a cooling map for passive GPU cooling (in a separate patch)
>>>> - Link to v3: https://lore.kernel.org/r/[e-mail]
>>>> 
>>>> Changes in v3:
>>>> - Added regulator coupling for EVB1 and QuartzPro64
>>>> - Enabled the TSADC for all boards in .dtsi, not just Rock 5B (thanks ChenYu)
>>>> - Added comments regarding two passive cooling trips in each zone (thanks Dragan)
>>>> - Fixed active cooling map numbering for Radxa Rock 5B (thanks Dragan)
>>>> - Dropped Daniel's Acked-by tag from the Rock 5B fan patch, as there's been quite some
>>>> churn there since the version he acknowledged
>>>> - Link to v2: https://lore.kernel.org/r/[e-mail]
>>>> 
>>>> Changes in v2:
>>>> - Dropped the rfkill patch which Heiko has already applied
>>>> - Set higher 'polling-delay-passive' (100 instead of 20)
>>>> - Name all cooling maps starting from map0 in each respective zone
>>>> - Drop 'contribution' properties from passive cooling maps
>>>> - Link to v1: https://lore.kernel.org/r/[e-mail]
>>>> 
>>>> ---
>>>> Alexey Charkov (8):
>>>>    arm64: dts: rockchip: add thermal zones information on RK3588
>>>>    arm64: dts: rockchip: enable thermal management on all RK3588 boards
>>>>    arm64: dts: rockchip: add passive GPU cooling on RK3588
>>>>    arm64: dts: rockchip: enable automatic fan control on Rock 5B
>>>>    arm64: dts: rockchip: Add CPU/memory regulator coupling for RK3588
>>>>    arm64: dts: rockchip: Add OPP data for CPU cores on RK3588
>>>>    arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
>>>>    arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j
>>>> 
>>>> .../boot/dts/rockchip/rk3588-armsom-sige7.dts      |   4 +
>>>> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi      | 197 +++++++++++++++++----
>>>> .../dts/rockchip/rk3588-edgeble-neu6a-common.dtsi  |   4 +
>>>> arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts   |  16 ++
>>>> arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts   |   4 +
>>>> arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi       | 190 ++++++++++++++++++++
>>>> .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |  12 ++
>>>> arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts    |  34 +++-
>>>> .../arm64/boot/dts/rockchip/rk3588-toybrick-x0.dts |   4 +
>>>> .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |   4 +
>>>> arch/arm64/boot/dts/rockchip/rk3588.dtsi           |   1 +
>>>> arch/arm64/boot/dts/rockchip/rk3588j.dtsi          | 141 +++++++++++++++
>>>> arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts   |   4 +
>>>> arch/arm64/boot/dts/rockchip/rk3588s.dtsi          |   1 +
>>>> 14 files changed, 577 insertions(+), 39 deletions(-)
>>>> ---
>>>> base-commit: 5cc74606bf40a2bbaccd3e3bb2781f637baebde5
>>>> change-id: 20240124-rk-dts-additions-a6d7b52787b9
>>>> 
>>>> Best regards,

Alexey Charkov July 8, 2024, 7:59 a.m. UTC | #9

Hi Piotr,

On Sun, Jul 7, 2024 at 9:32 PM Piotr Oniszczuk
<[e-mail]> wrote:
>
> Heiko, Alexey,
>
> After some more tests: is varying fan-speeds working stable for you?

Yes, in my testing on Rock 5B it's been stable.

> In my case - 1 per few reboots results with board enters state with: constant full speed and no any reaction for cpu temp.
> In such state - I need multiple hw poweroffs (remove usb-c plug) to get fan-speeds working again.
> When board is such state - all seems to work ok (frequency scaling, etc) except fan is constantly full speed…

One thought: could you please check which thermal governor gets
loaded? I used stepwise in my testing.

Best regards,
Alexey

Piotr Oniszczuk July 8, 2024, 10:29 a.m. UTC | #10

Alexey,
pls see inline

> Wiadomość napisana przez Alexey Charkov <[e-mail]> w dniu 08.07.2024, o godz. 09:59:
> 
> Hi Piotr,
> 
> On Sun, Jul 7, 2024 at 9:32 PM Piotr Oniszczuk
> <[e-mail]> wrote:
>> 
>> Heiko, Alexey,
>> 
>> After some more tests: is varying fan-speeds working stable for you?
> 
> Yes, in my testing on Rock 5B it's been stable.
> 
>> In my case - 1 per few reboots results with board enters state with: constant full speed and no any reaction for cpu temp.
>> In such state - I need multiple hw poweroffs (remove usb-c plug) to get fan-speeds working again.
>> When board is such state - all seems to work ok (frequency scaling, etc) except fan is constantly full speed…
> 
> One thought: could you please check which thermal governor gets
> loaded? I used stepwise in my testing.
> 

this is from system when - after boot - i have constant full speed of fan 

root@myth-frontend-3614ae04f23f:~ # cat /sys/class/thermal/thermal_zone0/policy
step_wise
root@myth-frontend-3614ae04f23f:~ # cat /sys/class/thermal/thermal_zone1/policy
step_wise
root@myth-frontend-3614ae04f23f:~ # cat /sys/class/thermal/thermal_zone2/policy
step_wise
root@myth-frontend-3614ae04f23f:~ # cat /sys/class/thermal/thermal_zone3/policy
step_wise
root@myth-frontend-3614ae04f23f:~ # cat /sys/class/thermal/thermal_zone4/policy
step_wise
root@myth-frontend-3614ae04f23f:~ # cat /sys/class/thermal/thermal_zone5/policy
step_wise
root@myth-frontend-3614ae04f23f:~ # cat /sys/class/thermal/thermal_zone6/policy
step_wise
root@myth-frontend-3614ae04f23f:~ # cat /sys/class/thermal/thermal_zone7/policy

dmesg: https://gist.github.com/warpme/5d12df382ce353205c6ff0c37f5b4791

lsmod: https://gist.github.com/warpme/1c74b3be2cabe85366f227594d8a3e90

pls let me know is there anything else i can provide to investigate this issue...