Apparent DSP Clock Rate configuration issue

Wiley Black1

Other Parts Discussed in Thread: DM3730

As best I can tell, my DSP clock rate is running very slow compared to expectations. Based on other posts such as [http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/62658/225772.aspx#225772], setting the clock rate on ARM/Linux side should also ramp up the DSP. If I execute

echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

and check the cpufreq-info, then I am told the ARM is running at 1GHz. When I then run a test codec that I created in codec_engine, I get a measurement of 742570663 DSP cycles for a task. This is measured as:

unsigned long long start_tick, stop_tick;
TSCL = 0; start_ticks = TSCL;
  // .. Perform task ..
stop_tick = TSCL;
stop_tick -= start_tick;
GT_1trace(gtMask, GT_1CLASS, "Required %i DSP ticks\n", stop_tick);

The CE_DEBUG=2 output gives me a measurement that I assume is referenced to the ARM clock. I would expect a little overhead from the IPC and function startup, but:

[DSP] @0,125,888tk: ... Enter

[DSP] @19,803,855tk: [+1 T:0x8782a97c] blah.codecs.test_copy - Required 742569591 DSP ticks

And I monitored the delay as being 19.82s with a stopwatch. These numbers give about 37MHz for the DSP.

I am running on a gumstix overo, DM3730 chip, yocto kernel (linux-omap-3.5) built (if I recall) using the TI toolchain by the following:

CSTOOL_DIR=/home/wiley/ti-dvsdk_dm3730-evm_04_03_00_06/linux-devkit/
CSTOOL_PREFIX=$CSTOOL_DIR/bin/arm-arago-linux-gnueabi-

Other symptoms include some messages at bootup:

[ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz

[ 0.065093] Reprogramming SDRC clock to 400000000 Hz

[ 0.065093] dpll3_m2_clk rate change failed: -22

[ 0.077850] Switched to new clocking rate (Crystal/Core/MPU): 26.0/400/500 MHz

I am using the userspace governor.

Q1. Am I correct in understanding that the DSP should be running at 800MHz since the ARM is at 1GHz?

Q2. Are there any flaws in my validation method?

Q3. How do I troubleshoot this further?

Thanks!

over 11 years ago

0 Cvetolin Shulev-XID over 11 years ago

TI__Guru 65405 points

Hi Wiley Black,

You are correctly understanding that the DSP should be running at 800 MHz since the ARM is at 1 GHz if you are using the default settings of the PRCM.CM_CLKSEL1_PLL_IVA2 and PRCM.CM_CLKSEL2_PLL_IVA2 registers which provide control over the IVA2 DPLL but I suggest you to check their values.

Your validation method about DSP ticks counting seems correct.

Tsvetolin Shulev

0 Wiley Black1 over 11 years ago in reply to Cvetolin Shulev-XID

Prodigy 80 points

Hi Cvetolin,

If I am reading them correctly, then the registers when the ARM is running at 1GHz are:

CM_CLKSEL1_PLL_IVA2 = 0x00081400

CM_CLKSEL2_PLL_IVA2 = 0x00000001

There's a lot going on in understanding what these values should be (for the uninitiated like me), but I do notice that the DPLL2 clock is mentioned as being derived from the DPLL3 clock in some cases, so could that error message regarding DPLL3 be a factor? Or are these values otherwise correct?

Thanks!

0 Cvetolin Shulev-XID over 11 years ago in reply to Wiley Black1

TI__Guru 65405 points

Hi Wiley,

Could you try to change the CM_CLKSEL1_PLL_IVA2 register value to 0x0009900c and check whether the value is accepted. Then start the test again and measure the time for execution to compare it with previous execution time.

Tsvetolin Shulev

0 Wiley Black1 over 11 years ago in reply to Cvetolin Shulev-XID

Prodigy 80 points

Hi Tsvetolin,

It appeared to accept the register value, and definitely had an effect. I verified that the register value stuck even after my profiling program ran.

The "[DSP] @19,840,726tk: [+1 T:0x8782a99c]" in the program trace didn't really change, still a 19s delta, but the ARM side of the trace surrounding the task did:

@0,893,286us: [+0 T:0xb6f34000] CV - VISA_call(visa=0xcbe900, msg=0xb5990880): messageId=0x00021051, command=0x0

[... Task executes DSP side, reports 739492439 cycles elapsed ...]

@13,491,298us: [+0 T:0xb6f34000] CV - VISA_call Completed: messageId=0x00021051, command=0x0, return(status=0)

On a stopwatch, 13.26s elapsed, so the ARM side appears to be realistic. The DSP cycles/second then is about 59MHz give-or-take on the VISA call overhead. That's better than the 37MHz I was measuring before, but something still looks wrong...what can I do next to troubleshoot further? I appreciate the assistance!

Thanks,

Wiley

0 Cvetolin Shulev-XID over 11 years ago in reply to Wiley Black1

TI__Guru 65405 points

Hi Wiley,

I suggest you a tool for detecting the frequency of the DSP that is based on the C64x+ core. This tool is suitable for the DM3730's DSP. There is a link to the tools sources and short description:

http://processors.wiki.ti.com/index.php/What_is_my_DSP_clock_speed

Tsvetolin Shulev

0 Wiley Black1 over 11 years ago in reply to Cvetolin Shulev-XID

Prodigy 80 points

Hi Tsvetolin,

I don't have CCS or an emulator at the moment. We might be able to get our hands on one but I'd like to exhaust other methods first. I'm not clear whether the gumstix overo (IronStorm) even has the JTAG pins exposed. Does the DSP have access to any GPIO lines that I might be able to toggle and check with an oscilloscope?

Thanks,

Wiley

0 Wiley Black1 over 11 years ago in reply to Cvetolin Shulev-XID

Prodigy 80 points

Hi Tsvetolin,

My colleague made an observation that for a 13-second+ experiment we need to be reading the full 64-bit time stamp register prevent rollovers. I also found that GT_1trace() doesn't seem to like %lld or %llu outputs, so I had to resort to sprintf() and refer here for proper TSCL+TSCH reading technique:

http://e2e.ti.com/support/development_tools/compiler/f/343/p/111938/411954.aspx#411954

I verified that a rollover was handled properly by doubling the length of the test until a rollover would be expected and witnessing it showing up correctly. This is a big improvement, with your suggestion we see the DSP at 400MHz, but would still expect 800MHz. The new results are:

With the ARM set at 1GHz via echo:

With CM_CLKSEL1_PLL_IVA2 = 0x00081400 (Kernel Value): 20,150,699,407 ticks over 78 seconds -> 258MHz.
With CM_CLKSEL1_PLL_IVA2 = 0x0009900C (Suggested): 20,138,058,128 ticks over 50 seconds -> 400MHz.

Performed a hard reset, ARM at 500MHz and CM_CLKSEL1_PLL_IVA2 reads 0x00081400:

20,150,703,324 ticks over 78 seconds -> 258MHz.

Tried rebooting and changing mpurate=1000 and get the following dmesg listings:

[ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz

[ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz

[ 0.065063] Reprogramming SDRC clock to 400000000 Hz

[ 0.065093] dpll3_m2_clk rate change failed: -22

[ 0.077575] ------------[ cut here ]------------

[ 0.077606] WARNING: at arch/arm/mach-omap2/clock.c:476 omap2_clk_switch_mpur

ate_at_boot+0x80/0xbc()

[ 0.077606] clock: dpll1_ck: unable to set MPU rate to 1000: -22

[ 0.077606] Modules linked in:

[ 0.077667] [<c00139a0>] (unwind_backtrace+0x0/0x128) from [<c0031b10>] (warn

_slowpath_common+0x4c/0x64)

[ 0.077697] [<c0031b10>] (warn_slowpath_common+0x4c/0x64) from [<c0031bbc>] (

warn_slowpath_fmt+0x30/0x40)

[ 0.077728] [<c0031bbc>] (warn_slowpath_fmt+0x30/0x40) from [<c068f498>] (oma

p2_clk_switch_mpurate_at_boot+0x80/0xbc)

[ 0.077758] [<c068f498>] (omap2_clk_switch_mpurate_at_boot+0x80/0xbc) from [<

c068f4e0>] (omap3xxx_clk_arch_init+0xc/0x3c)

[ 0.077758] [<c068f4e0>] (omap3xxx_clk_arch_init+0xc/0x3c) from [<c0008690>]

(do_one_initcall+0x94/0x15c)

[ 0.077789] [<c0008690>] (do_one_initcall+0x94/0x15c) from [<c0682364>] (kern

el_init+0x13c/0x21c)

[ 0.077819] [<c0682364>] (kernel_init+0x13c/0x21c) from [<c000f154>] (kernel_

thread_exit+0x0/0x8)

[ 0.077880] ---[ end trace 1b75b31a2719ed1c ]---

Cpufreq-info reports 600MHz.

All times were verified with a stopwatch.

Wiley

0 Cvetolin Shulev-XID over 11 years ago in reply to Wiley Black1

TI__Guru 65405 points

Hi Wiley,

I'm little bit surprised because I have a dm3730evm board and when the ARM is clocked at 1 GHz and CM_CLKSEL1_PLL_IVA2 is 0x0009900C the DSP operates at 800 MHz.

I would like to verify the value of the following registers whether are as at my board:

CM_FCLKEN_IVA2 = 0x0000 - When the IVA2.2 subsystem does not require an internal clock, the internal clocks can be disabled at the PRCM level.

CM_CLKEN_PLL_IVA2 = 0x0017

I'm checking the DSP frequency by the following code:

    if (omap3_has_iva()) {
       pr_info("IVA2 clocking rate: %ld MHz\n",
               (clk_get_rate(iva2_ck) / 1000000)) ;
   }

which presents in the end of omap2_clk_set_freq function of clock34xx.c file in the DVSDK 4.02 but it's missed in the next version DVSDK 4.03.

If the DSP frequency is still 400 MHz I suggest you to try with two other values of the CM_CLKSEL1_PLL_IVA2 register:

0x0009FF0C or

0x00099006

Could you share your results?

Tsvetolin Shulev

0 Wiley Black1 over 11 years ago in reply to Cvetolin Shulev-XID

Prodigy 80 points

Hi Tsvetolin,

My colleague investigated this further and found that setting registers

PRM_CLKSEL_CTRL -> 0x48 and CM_CLKSEL1_PLL_IVA2-> 0x9900c

as well as the ARM to 1GHz results in an 800MHz DSP. Sounds like a bug in my linux kernel perhaps (?) but the problem is solved for my purposes.

Thanks for your help!

Wiley

Processors

Processors forum

Apparent DSP Clock Rate configuration issue