On 11.10.24 10:48, Joel GUITTET wrote:
I faced some issue related to scaling frequency on ZynqMP device using v5.15.167 kernel. As an exemple setting the scaling frequency below show it's not properly set:
cat /sys/devices/system/cpu/cpufreq/policy0/ scaling_available_frequencies 299999 399999 599999 1199999
echo 399999 > /sys/devices/system/cpu/cpufreq/policy0/ scaling_setspeed
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 399999
cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 299999 ====> Should be 399999
After analysis of this issue with the help of Xilinx, it appears that a commit was backported on the 5.15.y branch, but probably it should not, or not as is. The commit is 9117fc44fd3a9538261e530ba5a022dfc9519620 modifying drivers/clk/ zynqmp/divider.c.
FWIW, that is 1fe15be1fb6135 ("drivers: clk: zynqmp: update divider round rate logic") [v6.8-rc1].
Is anybody reading this message able to answer why it was backported ?
Looks like because it fixes a bug. I CCed the original author and those that handled the patch, maybe they can help us out and tell us what's the best strategy forward here.
The information I have until now is that it is intended recent kernel version. Dependencies for this modification is currently under clarification with Xilinx (maybe another commit to backport).
By the way, reverting this commit fix the issue shown above.
Does 6.12-rc work fine for you? Because if not, we should fix the problem there.
Ciao, Thorsten
Thanks for the reply Thorsten.
So is anybody able to indicate why this commit 1fe15be1fb6135 has been backported to 5.15.y? Actually this creates a bug on v5.15 (see commands executed in my original message). I don't know for 6.8 or 6.12 release, I'm not able to update my target with such gap.
Regards Joel
________________________________________ De : Thorsten Leemhuis regressions@leemhuis.info Envoyé : lundi 14 octobre 2024 08h45 À : Jay Buddhabhatti jay.buddhabhatti@amd.com Cc : Greg KH gregkh@linuxfoundation.org; Linux kernel regressions list regressions@lists.linux.dev; Sasha Levin sashal@kernel.org; Stephen Boyd sboyd@kernel.org; Joel GUITTET jguittet.opensource@witekio.com; linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org; stable@vger.kernel.org stable@vger.kernel.org Objet : Re: Bad commit backported on the v5.15.y branch ? [Vous ne recevez pas souvent de courriers de regressions@leemhuis.info. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification%C2%A0]
On 11.10.24 10:48, Joel GUITTET wrote:
I faced some issue related to scaling frequency on ZynqMP device using v5.15.167 kernel. As an exemple setting the scaling frequency below show it's not properly set:
cat /sys/devices/system/cpu/cpufreq/policy0/ scaling_available_frequencies 299999 399999 599999 1199999
echo 399999 > /sys/devices/system/cpu/cpufreq/policy0/ scaling_setspeed
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 399999
cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 299999 ====> Should be 399999
After analysis of this issue with the help of Xilinx, it appears that a commit was backported on the 5.15.y branch, but probably it should not, or not as is. The commit is 9117fc44fd3a9538261e530ba5a022dfc9519620 modifying drivers/clk/ zynqmp/divider.c.
FWIW, that is 1fe15be1fb6135 ("drivers: clk: zynqmp: update divider round rate logic") [v6.8-rc1].
Is anybody reading this message able to answer why it was backported ?
Looks like because it fixes a bug. I CCed the original author and those that handled the patch, maybe they can help us out and tell us what's the best strategy forward here.
The information I have until now is that it is intended recent kernel version. Dependencies for this modification is currently under clarification with Xilinx (maybe another commit to backport).
By the way, reverting this commit fix the issue shown above.
Does 6.12-rc work fine for you? Because if not, we should fix the problem there.
Ciao, Thorsten
On Wed, Oct 16, 2024 at 09:23:10AM +0000, Joel GUITTET wrote:
Thanks for the reply Thorsten.
So is anybody able to indicate why this commit 1fe15be1fb6135 has been backported to 5.15.y?
Because it has a "Fixes:" tag on it. Is that tag not correct?
Actually this creates a bug on v5.15 (see commands executed in my original message).
What "original message"?
I don't know for 6.8 or 6.12 release, I'm not able to update my target with such gap.
It's already in the following releases: 5.10.209 5.15.148 6.1.75 6.6.14 6.7.2 6.8 so if it needs to be reverted somewhere, please send the reverts with the reason why.
thanks,
greg k-h
Because it has a "Fixes:" tag on it. Is that tag not correct?
understood why it's backported. Probably yes. Or maybe another commit should be introduced to not create a new issue.
What "original message"?
My original message in this mailing list, see below commands that show the problem (last line is wrong):
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 299999 399999 599999 1199999
echo 399999 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 399999
cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 299999 ====> Should be 399999
On Wed, Oct 16, 2024 at 01:13:42PM +0000, Joel GUITTET wrote:
Because it has a "Fixes:" tag on it. Is that tag not correct?
understood why it's backported. Probably yes. Or maybe another commit should be introduced to not create a new issue.
Perhaps, but I have no clue what is going on here, sorry.
Is this an issue in Linus's tree? Is it in the other stable releases? If not, are we missing a change? Or does the issue show up there as well?
What "original message"?
My original message in this mailing list, see below commands that show the problem (last line is wrong):
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 299999 399999 599999 1199999
echo 399999 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 399999
cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 299999 ====> Should be 399999
Ok, so someone needs to tell me what to do here as I'm confused :)
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Joel GUITTET -
Thorsten Leemhuis