linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org
Subject: Re: PWM fan control not working with Rock5B and upstream kernel
Date: Tue, 15 Jul 2025 18:14:21 +0930	[thread overview]
Message-ID: <f33da910-7e83-40a0-bfcd-a6131a356358@suse.com> (raw)
In-Reply-To: <5271313.GXAFRqVoOG@workhorse>



在 2025/7/15 17:19, Nicolas Frattaroli 写道:
> On Tuesday, 15 July 2025 06:10:45 Central European Summer Time Qu Wenruo wrote:
>> Hi,
>>
>> My Rock5B board is running edk-rk3588 firmware and (almost) upstream
>> kernel (6.14.6 kernel from ArchlinuxARM), using upstream dtbs (the
>> firmware is also switched to device-tree boot mode)
> 
> Consider using mainline u-boot instead. I think the only ones who
> insist on edk2 forks are the BSD people, as they don't want to
> write device drivers. Linux has drivers, so inventing UEFI abstractions
> for things probably only makes your experience worse.

Well, having something more user-friendly and more similar to a 
traditional PC setup is definitely more attractive to end users.

> 
> Kernel 6.14 is also quite a bit behind and not supported by upstream,
> you'll likely have a better experience compiling a kernel yourself
> using defconfig as the base. ALARM likes to roll dice when it comes to
> their kernel config and then not update their kernels for half a year.

Thankfully the latest one is 6.15.6, and unfortunately it doesn't make a 
difference.

I'm fine compiling kernels for my VMs to run tests, but for the host I'd 
leave this as the last resort method.

I'll try the Uboot if required, but no pre-compiled upstream one is not 
really inviting end users.

> 
>>
>> Before that I'm using ACPI mode thus no PMW support, but the firmware's
>> fan control is working properly although running at a fixed rpm setting.
>>
>> But after switching to the upstream kernel and device-tree mode, the pwm
>> fan control never works.
> 
> Check /sys/class/pwm, export the pwm associated with the fan in the DT,
> then manually set a period and duty cycle that corresponds to a period
> the fan supports. If it doesn't spin, then the problem is likely that
> there is a disconnect between what Linux thinks the PWM signal is and
> what it actually is.

Mind to explain it a little more?

Not an expert on device-tree, I normally use the board just as a 
headless VM host.

> 
> I'm guessing the problem here is that your firmware of choice leaves
> the clock tree in a bit of a state, and the PWM is clocked from
> something that's incorrect. If it's not the right clock period for
> the fan, it won't spin.

But my bootloader (systemd-boot) is explicitly loading the dtb, not 
really relying on the one provided by the firmware.

Or that is not really enough for this case?

Thanks,
Qu

> 
> A logic analyzer would be able to tell you definitively whether that's
> the case.
> 
>>
>> `sensors` command detects the fan, and the pwm seems to properly
>> following the temperature, but the physical fan just do not spin at all:
>>
>> center_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +80.4°C
>>
>> bigcore2_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +84.1°C
>>
>> package_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +81.3°C
>>
>> pwmfan-isa-0000
>> Adapter: ISA adapter
>> pwm1:            128%  MANUAL CONTROL <<<
>>
>> gpu_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +79.5°C
>>
>> littlecore_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +82.2°C
>>
>> bigcore0_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +83.2°C
>>
>>
>> I'm wondering is this a bug in the upstream PWM code or something else
>> is missing preventing the fan from working properly.
> 
> The upstream PWM code definitely works, and has worked for every
> Rockchip device so far. The PWM fan on my ROCK 5B (mainline u-boot,
> mainline kernel, mainline TF-A) works just fine.
> 
>>
>> Thanks,
>> Qu
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>
> 
> 
> 
> 



  reply	other threads:[~2025-07-15  9:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-15  4:10 PWM fan control not working with Rock5B and upstream kernel Qu Wenruo
2025-07-15  7:49 ` Nicolas Frattaroli
2025-07-15  8:44   ` Qu Wenruo [this message]
2025-07-15  9:01     ` Qu Wenruo
2025-07-15  9:13     ` Nicolas Frattaroli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f33da910-7e83-40a0-bfcd-a6131a356358@suse.com \
    --to=wqu@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=nicolas.frattaroli@collabora.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).