This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I'm testing TI's H.264 encoder, using the DMAI test application on a DM3730. The encode time for a 720x480 frame is on average 45ms. This is 3x the spec'd time of this encoder, which comes to 14.2ms. I'm hoping my DSP clock is simply running at 260MHz (OPP1 - OPP50), rather than the desired 800MHz (OPP4 - OPP-SB). Other forum posts claim that when the ARM OPP changes, the DSP OPP changes simultaneously, but none of the original posters have ever confirmed. I have forced the ARM OPP to 300MHz and 1GHz, and observed the expected differences in ARM operations, but with no effect on DSP time.
How is the DSP clock configured from Linux? Is it actually configured from Linux or is the DSP portion of the OPP support in Linux not yet complete? Is there anything in codec engine, or codec server, that controls DSP frequency? My understanding is the frequency in server.tcf is for reference, and doesn't actually control the DSP's frequency. I don't have an emulator setup so I can't use the "What's my DSP frequency" project from the wiki.
Any insight into determining and setting the DSP clock would be appreciated. Thanks.
I verified my theory that the DSP clock was running slow. I added the following to clock3xxx.c:
void __init omap3_clk_setup_dpll2(void)
{
struct clk *dpll2_clk;
dpll2_clk = clk_get(NULL, "dpll2_ck");
clk_set_rate(dpll2_clk, 800000000);
}
and called the function from omap3xxx_clk_init in clock3xxx_data.c. With that, I achieved the advertised H.264 encoder performance.
To play nicely with the ARM's DVFS, I believe I would need to set the governor to performance, so the arm is always at OPP1G, which can be done from the linux kernel config menus.
Ideally, I'd like to see the governor/cpu-freq driver set both the ARM and DSP frequencies, like some other posts have suggested it does. Even then, howver, I assume the governor is driven by ARM load, not DSP load? If that were the case, I still wouldn't be able to scale up the frequencies when DSP usage is high if ARM usage is low. Short of adding DSP load info collection to the governor, and changing the cpu-freq driver to adjust the DSP clock too, is there another way to accomplish what I've outlined? Or am I missing something?
Thanks for posting. I have searched many OMAP3530 and DM3730 posting for how to set the DSP clock. I couldn't get any of the suggested solutions to work. Your function posted above worked great!
Did you find a method to set the OPP/DVFS prior to this? I am setting it after booting from the command script using:
echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
(we use 800MHz for the ARM as well)
But by the time my script runs, the DSP freq has already been set, so we are not at the correct voltage for a short period of time until my script runs.
How did you solve the DVFS issue?
You can select the governor in linux menuconfig menus when compiling linux. If you set the the governor to performance, it will boot into the highest OPP, giving you the proper voltages.
Thank you Andrew for the great tips. We faced the same issue. I have a modified version of the message sample DSP/GPP program that I use to benchmark the DSP clock. I used "clk_get" and "clk_set_rate" as you described but in the initialization of a kernel module. Once we load the driver I see the clock speed bump up from 260Mhz to 800Mhz.
I also tried using "bitbake linux-gumstix -c menuconfig" (we're using a gumstix overo) and configuring the power options to default to "performance" before bitbaking the gumstix-console-image. This alone didn't give me any boost in clock speed like I saw with the above method. Am I supposed to do both to insure the correct clock frequency and voltage, or are the two tied together? I don't have a strong understanding of DVFS.
Thanks!
Hi Micah,
When you change the frequency then automatically voltage also get reduced in DVFS.
Do you have PMIC on your board and enabled in kernel ?
then you can check your voltage range by below command through SYSFS.
cat /sys/class/regulator/regulator.X/microvolts
Please refer the following useful TI wikis,
http://processors.wiki.ti.com/index.php/OMAP-L1_Linux_Drivers_Usage#Power_Management
http://processors.wiki.ti.com/index.php/DVFS_User_Guide#Voltage_Scaling
http://processors.wiki.ti.com/index.php/UserGuidePmic_PSP_03.00.00.05
Thank you Titus,
It is reassuring to know that adjusting the clock frequency does not run the core at an incorrect voltage. I was able to verify microvolts for most of the regulators. I will have to spend more time debugging to understand why increasing the DSP clock speed is crashing our application next week.
-Micah
Hey Andrew,
I was wondering what you did to display the speed of the dsp. I've made all of the changes suggested here, but I'm seeing performance worse than the omap3530. If I could check the dsp I think I could figure out what the issue is. Thanks
Farris
Farris,
I am using a custom tool built around TI's "message" sample application:
https://bitbucket.org/micahsnyder/c6x-dsp-clock-benchtest
I would love to know if there is a simpler solution.
-Micah
This is how I did it. The DSP has registers TSCL and TSCH telling you the count of the clock cycles of the DSP.
What I did was:
uint32_t startTime, endTime, cyclesPerSecond;
TSCL = 0; // enable counter (does not necessarily reset the count)
startTimeL = TSCL;
// wait 1 second
endTimeL = TSCL;
cyclesPerSecond = endTimeL - startTimeL;
I didn't take into account the TSCH register, but you could (especially since TSCL can overflow every few seconds (so watch if your endTimeL is less than your startTimeL)
Bryce