Forums » Software Development »
Increasing CPU clock OMAPL138
Added by Kim Nielsen almost 2 years ago
Hi,
I'm using a "L138-FI-236-RL" SOM board with SYS/BIOS running on the DSP and Linux on the ARM.
The Linux is built by ourselves, but it is based on davinci Linux.
I have attached the config file I use and dmesg log.
Issue:
I would like to increase the CPU clock speed via Linux with "cpufreq".
These are the steps I use:
$ cd /sys/devices/system/cpu/cpu0/cpufreq/policy0
$ echo userspace > scaling_governor
$ echo 372000 > scaling_setspeed
But when I do this, the "cpuinfo_cur_freq" file still displays 300000.
I also see this warning in dmesg
"Warning: CPU frequency out of sync: cpufreq and timing core thinks of 456000, is 300000 kHz"
I had similar issues like this post: https://support.criticallink.com/redmine/boards/10/topics/3893?r=3895#message-3895
I have added "CONFIG_REGULATOR_TPS65023" and "CONFIG_REGULATOR" and also the patch for "board-mityomapl138.c".
Thanks,
Kim
Replies (12)
RE: Increasing CPU clock OMAPL138 - Added by Michael Williamson almost 2 years ago
Hi Kim,
What do you get when you dump out the scaling_available_frequencies (I don't remember the exact name off the top of my head, but the file that lists the available frequencies that may be selected)?
-Mike
RE: Increasing CPU clock OMAPL138 - Added by Jonathan Cormier almost 2 years ago
Hi Kim, What kernel version are you using? Testing this on our released 3.2 kernel appears to be working for me.
Note my module tested is only rated up to 372000khz. I can try to find a L138-F... module which should be good up to 456000khz, but 372000khz should still be a valid step.
root@mityomapl138:~# uname -a Linux mityomapl138 3.2.0 #1 PREEMPT Mon Jan 13 11:06:16 EST 2014 armv5tejl GNU/Linux root@mityomapl138:~# factoryconfig dump Part Number : L138-DG-225-RI ... root@mityomapl138:~# tail /sys/devices/system/cpu/cpu0/cpufreq/* ==> /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus <== 0 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq <== 300000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq <== 372000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq <== 96000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency <== 2000000 ==> /sys/devices/system/cpu/cpu0/cpufreq/related_cpus <== 0 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies <== 372000 300000 200000 96000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors <== userspace ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq <== 300000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver <== davinci ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor <== userspace ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq <== 372000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq <== 96000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed <== 300000 ==> /sys/devices/system/cpu/cpu0/cpufreq/stats <== tail: read error: Is a directory root@mityomapl138:~# echo 372000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_ setspeed root@mityomapl138:~# tail /sys/devices/system/cpu/cpu0/cpufreq/* ==> /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus <== 0 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq <== 372000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq <== 372000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq <== 96000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency <== 2000000 ==> /sys/devices/system/cpu/cpu0/cpufreq/related_cpus <== 0 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies <== 372000 300000 200000 96000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors <== userspace ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq <== 372000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver <== davinci ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor <== userspace ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq <== 372000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq <== 96000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed <== 372000 ==> /sys/devices/system/cpu/cpu0/cpufreq/stats <== tail: read error: Is a directory root@mityomapl138:~#
RE: Increasing CPU clock OMAPL138 - Added by Kim Nielsen almost 2 years ago
Hi Mike & Jonathan,
Thank you for the fast reply :-)
I have the following frequencies available according to the "scaling_available_frequencies" file.
456000 408000 372000 300000 200000 96000
We are actually using a newer kernel (4.19), but it is still under testing.
/Kim
RE: Increasing CPU clock OMAPL138 - Added by Jonathan Cormier almost 2 years ago
Where is the 4.19 kernel based from? It doesn't appear to have working cpufreq.
RE: Increasing CPU clock OMAPL138 - Added by Kim Nielsen almost 2 years ago
It's our own "experimental" kernel.
It seems to be working now. The issue was that the pll0 registers were apparently locked by CFGCHIP0.
Thank you for your time.
/Kim
RE: Increasing CPU clock OMAPL138 - Added by Jonathan Cormier almost 2 years ago
Kim Nielsen wrote in RE: Increasing CPU clock OMAPL138:
It's our own "experimental" kernel.
It seems to be working now. The issue was that the pll0 registers were apparently locked by CFGCHIP0.Thank you for your time.
/Kim
Gotcha, just curious if your based off of 4.19 from mainline or if you started from a TI kernel. Glad you got it working though.
RE: Increasing CPU clock OMAPL138 - Added by Kim Nielsen over 1 year ago
I actually got another question.
By default, the cpu frequency seems to always be 300 MHz.
Is this value hardcoded in the kernel somewhere?
Can't seem to find it.
/Kim
RE: Increasing CPU clock OMAPL138 - Added by Jonathan Cormier over 1 year ago
I don't see an obvious default frequency config in the kernel, I'd guess that it stays with whatever frequency was setup by u-boot. But that would need to be tested.
You could use the ONDEMAND governor as default if you want it to scale up/down depending on load. Or the PERFORMANCE governor if you just want max frequency all the time.
RE: Increasing CPU clock OMAPL138 - Added by Michael Williamson over 1 year ago
Hi Kim,
I think the issue is that the voltage scaling needs to be done to default
to a higher frequency.
The PMIC defaults the core voltage to support 300 MHz and I don't think
uBoot adjusts it -- it starts all the PLLs, etc., at 300 MHz.
So the kernel probably starts at 300MHz to be safe. Not sure if you can
force it to adjust with a kernel command line or not.
-Mike
RE: Increasing CPU clock OMAPL138 - Added by Kim Nielsen over 1 year ago
Alright.
Is there is no way to change the default frequency from 300Mhz to e.g. 372MHz with U-Boot?
As far as I can see, according to Table 6-5. Maximum Internal Clock Frequencies at Each Voltage Operating Point in OMAP-L138 C6000 DSP+ARM Processor datasheet (Rev. J)
voltage of 1.2V should be ok for 300MHz and 372MHz, but 300MHz seems to be selected at boot.
RE: Increasing CPU clock OMAPL138 - Added by Michael Williamson over 1 year ago
Hi Kim,
I think the reason why the uBoot Critical Link publishes is using 300 MHz is because the Revision 1 silicon was only rated to 300 MHz for 1.2V operation. See Note (7) of section 5.3 of the datasheet. For Revision 1 silicon, 372 MHz was not allowed.
I think we may have revision 1.x silicon SOMs in the field, so we've not changed it. Generally, customers have been OK with boosting it to higher frequencies immediately following linux boot with an init V or systemd script.
It is certainly possible to modify uBoot to alter the PLL settings for speed the system up to 372 Mhz and/or send the I2C command to the PMIC to bump the voltage. If you need help altering the code, we can look into it, but we would have to provide it on an alternative / custom branch due to the issues mentioned above.
With regards,
Mike
RE: Increasing CPU clock OMAPL138 - Added by Kim Nielsen over 1 year ago
Hi Mike,
Ah, makes sense.
For the time being I'll stick with controlling the clock frequency with Linux.
Thank you for your time.
Regards,
Kim
