Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

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

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:~#

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

Where is the 4.19 kernel based from? It doesn't appear to have working cpufreq.

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

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.

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

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.

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

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.

Link to OMAP-L138 datasheet

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

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