Hello,
Is it possible to change clockspeed on the fly with mainline kernel? I want to do this to lower my power consumption on imx28.
I have seen somewhere on this community that it was possible with the 2.6 kernel from Freescale but I can't find anything on how to do it with a newer 3.x kernel.
Meanwhile changing CPUFREQ is supported in kernel 3.x (see above). Are there also activities in kernel 4.x?
Hallo Michael,
i think i need to clarify. The cpufreq support for i.MX28 is still in development and not in mainline, but my patches works with Kernel 3.x and 4.x. There are no fundamental changes between 3.x and 4.x.
Hi rajtantajtan,
currently there is no support for cpufreq on i.MX28 in mainline according to this thread: http://www.spinics.net/lists/cpufreq/msg10430.html .
First of all, the mxs-regulator driver must be ported to mainline. My first trial for Linux 3.17-rc3 is here: http://thread.gmane.org/gmane.linux.ports.arm.kernel/354223
Any feedback is appreciated
BR Stefan
Hi Victorien,
you will find in this Github repository the cpufreq-dt support (formely known as cpufreq-cpu0) for i.MX23/28:
lategoodbye/linux-mxs-power · GitHub
Edit: Please keep in mind this repo is for development so i can't guarantee any stability or compatiblity to the final version.
Here are the necessary steps:
Searching for tester of Linux Kernel drivers
Regards Stefan
I made some tests on the driver and I saw an issue. The gouvernor is userspace and the initial frequency is 454735, I use this command to test processor performance "dd if=/dev/zero of=/dev/null bs=512 count=1000000" and I change the frequency of cpu :
454735 => 6.771169 seconds, 72.1MB/s
392728 => 7.658884 seconds, 63.8MB/s
360000 => 8.207378 seconds, 59.5MB/s
261819 => 11.302969 seconds, 43.2MB/s
360000 => 8.205697 seconds, 59.5MB/s
392728 => 7.660851 seconds, 63.7MB/s
454735 => 12.211602 seconds, 40.0MB/s
It's seems that the cpu can't come back to maximal frequency. Do you have the same issue ?
Hi Victorien,
thanks for testing. The frequency of 454735 sounds strange to me, it should be 454737.
Which branch do you took from the github repo? The current and correct branch would be "dcdc-clk". Sorry, for the confusion.
Did you apply your clk-frac patch?
Hi Stefan,
we have the patch running and can use the cpufreq utilities. But the lowest possible CPU frequency is 261.819 MHz. We would like to lower the frequency to 64 MHz. The freescale linux manual explains that both USB nor LCD can be used then, so we build a kernel without USB and LCD support but nothing changed. Have you tried to do this?
By the way we have the same problem with freescale kernel 2.x.
Hi Michael,
i'm sorry but i supend the work on cpufreq support, because the some constraints (EMI clk, VDDD) which need to handle and cpufreq-dt isn't able to handle that.
Currently i'm working to make the lower layer (regulator, power supply) to work properly, before working on cpufreq again.Adding 64 MHz into the OPPs is simple, but from my understanding it needs a little bit more of that.
Hello Victorien,
thanks for the patch, its running. Do you - or perhaps Stefan - know how to lower the AHB Clk frequency? The iMX28_Power_Calculator_RevB.xls shows great power reduction from operating point 261MHz to 64MHz but we saw only a reduction from 68mA to 55mA so I suppose I must reduce AHB Clock frequency, too. Of course its not the same as at the moment in our case only Linux is running on a custom board. As my application only use Audio I think I can lower AHB Clock to 64MHz as in the power calculator example.
Hello Michael,
i think it's a problem of the iMX28_Power_Calculator_RevB.xls. Looking at the frequency table shows TBD for 64 MHz in row VDDA.
From my understand the hbus (AHB) frequency is changed because it's a child node of cpu. Please look at /sys/kernel/debug/clk/clk_summary
We will save more power on reducing emi frequency, but that's not trivial anymore because of DRAM controller and DMA handling.
Btw the VDDD setting for 64 MHz in Victorien's patch is too conservative. According to the datasheet 1300 mV is recommend and the cpufreq driver from 2.6.35 uses only 1275 mV.
Stefan
Edit: I see there is problem in the regulator constraints preventing us to define 1300 mV as VDDD. I will fix that.
Thanks for the patch.
Could you please explain the reason for changing the clock (ref_cpu to cpu)?
I can really explain why but with clock #4, 64MHz frequency doesn't work. I remarked that HW_CLKCTRL_FRAC1 register says that divider is not stable for 64Mhz. Then I think something is wrong with this frequency.