DM3730 IVA2 (DSP) Clock - Determining and Setting Frequency

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