• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 102 subscribers
  • Views 967 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CPUFreq issue on OMAP3EVM

WRiba
Prodigy 120 points
Other Parts Discussed in Thread: OMAP3525

Hi,

I've been looking into several OMAP PM features and am unable to get CPUFreq to properly indicate / regulate CPU frequency. All frequency queries indicate that the CPU frequency is always set to the boot up value (mpurate=500).

I've configure the latest TI PSP kernel (2.6.32) with SmartReflex, CPUFreq (userspace, ondemand support) and CPUIdle. CPUIdle tests seem to work fine. Dynamic CPU frequency control however is not. When set to the ondemand governor at boot, cpufreq-info yields the following after some system up and run time::

root@omap3evm:~# cpufreq-info
cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: omap
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 300 us.
  hardware limits: 125 MHz - 720 MHz
  available frequency steps: 720 MHz, 600 MHz, 550 MHz, 500 MHz, 250 MHz, 125 MHz
  available cpufreq governors: ondemand, userspace
  current policy: frequency should be within 125 MHz and 720 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 500 MHz (asserted by call to hardware).
  cpufreq stats: 720 MHz:0.00%, 600 MHz:0.00%, 550 MHz:0.00%, 500 MHz:100.00%, 250 MHz:0.00%, 125 MHz:0.00% 

Indicating the the 100% of the time, the CPU has been at the bootarg specified frequency.

With the userspace governer, I find the following:

root@omap3evm:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_governors
ondemand userspace
root@omap3evm:/sys/devices/system/cpu/cpu0/cpufreq# cpufreq-set -g userspace
root@omap3evm:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq
500000
root@omap3evm:/sys/devices/system/cpu/cpu0/cpufreq# echo 550000 > scaling_setspeed
root@omap3evm:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_setspeed
500000 <=== WRONG VALUE
root@omap3evm:/sys/devices/system/cpu/cpu0/cpufreq# cpufreq-set -f 550000
root@omap3evm:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_setspeed
500000 <=== WRONG VALUE
root@omap3evm:/sys/devices/system/cpu/cpu0/cpufreq# cpufreq-info
cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: omap
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 300 us.
  hardware limits: 125 MHz - 720 MHz
  available frequency steps: 720 MHz, 600 MHz, 550 MHz, 500 MHz, 250 MHz, 125 MHz
  available cpufreq governors: ondemand, userspace
  current policy: frequency should be within 125 MHz and 720 MHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 500 MHz (asserted by call to hardware).
  cpufreq stats: 720 MHz:0.00%, 600 MHz:0.00%, 550 MHz:0.00%, 500 MHz:100.00%, 250 MHz:0.00%, 125 MHz:0.00%

So again with userspace control, I am still unable to set the CPU frequency.

Any ideas on what is wrong here would be greatly apreciated.

Thanks

Bill R

  • 0
    Prodigy 120 points

    I resolved the above non-working cpufreq issue by unselecting CPU Power Management->Enable CPUfreq debugging in the kernel config. With that cpufreq became functional.

    Using cpufreq in userspace works well. The CPU frequency changes as specifed.. Attempting ondemand mode however yields the following:

     

    root@omap3evm:~# cpufreq-set -g ondemand
    root@omap3evm:~#     omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX

     

    The display subsystem fails. Are any modes other than userspace control known to work on the OMAP3 EVM?

    Thanks,

    Bill Riba

     

  • 0 in reply to WRiba
    Intellectual 300 points

    Mr. Riba,

     

    Did you ever get a response to this?

     

    I see the exact same response when using "ondemand" + this one from dpll.c line 439:

    WARNING: at arch/arm/mach-omap2/dpll.c:439 omap3_noncore_dpll_set_rate+0x220/0x264()
    Modules linked in:
    [<c003d464>] (unwind_backtrace+0x0/0xd0) from [<c005e940>] (warn_slowpath_common+0x48/0x60)
    [<c005e940>] (warn_slowpath_common+0x48/0x60) from [<c0047440>] (omap3_noncore_dpll_set_rate+0x220/0x264)
    [<c0047440>] (omap3_noncore_dpll_set_rate+0x220/0x264) from [<c0045ac0>] (omap2_clk_set_rate+0x20/0x2c)
    [<c0045ac0>] (omap2_clk_set_rate+0x20/0x2c) from [<c004aa18>] (clk_set_rate+0x38/0x78)
    [<c004aa18>] (clk_set_rate+0x38/0x78) from [<c00494c8>] (program_opp+0x88/0x104)
    [<c00494c8>] (program_opp+0x88/0x104) from [<c0049634>] (resource_set_opp_level+0xf0/0x160)
    [<c0049634>] (resource_set_opp_level+0xf0/0x160) from [<c00496e0>] (set_opp+0x3c/0xf8)
    [<c00496e0>] (set_opp+0x3c/0xf8) from [<c005042c>] (update_resource_level+0xa8/0xcc)
    [<c005042c>] (update_resource_level+0xa8/0xcc) from [<c0049418>] (set_freq+0xb8/0xe0)
    [<c0049418>] (set_freq+0xb8/0xe0) from [<c005042c>] (update_resource_level+0xa8/0xcc)
    [<c005042c>] (update_resource_level+0xa8/0xcc) from [<c004f7b0>] (omap_target+0x50/0x6c)
    [<c004f7b0>] (omap_target+0x50/0x6c) from [<c0262c78>] (__cpufreq_driver_target+0x28/0x38)
    [<c0262c78>] (__cpufreq_driver_target+0x28/0x38) from [<c02656d0>] (do_dbs_timer+0x264/0x2cc)
    [<c02656d0>] (do_dbs_timer+0x264/0x2cc) from [<c0072634>] (worker_thread+0x18c/0x204)
    [<c0072634>] (worker_thread+0x18c/0x204) from [<c00757c4>] (kthread+0x7c/0x84)
    [<c00757c4>] (kthread+0x7c/0x84) from [<c0039854>] (kernel_thread_exit+0x0/0x8)
    ---[ end trace b06d984c9d800ffc ]---

    are they completely inane warnings (no reason for concern)?

     

    Thanks,

    Peter Thoeming

  • 0 in reply to Peter Thoeming
    Prodigy 120 points

    No response to the on demand mode question yet.

    I also get many trace backs when power management features are active. I haven't had time to go back and investigate their causes just yet.

    W Riba

  • 0 in reply to WRiba
    Intellectual 300 points

    I've confirmed on both our product and the Mistral EVM that enabling ONDEMAND on kernel 2.6.32 (PSP 3.0.1.6) definately randomly kills the display controllers GFX and that affects the frame-buffer/display controller out through the analog video encoder (tv_out1).

    The image randomly goes blank. re-using something such as "fbv" to re-display the image restores the image, but occasionally, any frequency adjustment while using ondemand governor will crash the display controller.

  • 0 in reply to Peter Thoeming
    TI__Expert 8180 points

    Hi,

    Can you please try the patch attached here and let me know the outcome of this

    NOTE: Please rename the file from *.txt to *.patch.

     

    7220.0001-OMAP3EVM-Set-minimum-throughput-requirement-for-DSS.txt.

    Thanks,

    Vaibhav

  • 0 in reply to Vaibhav Hiremath
    Intellectual 300 points

    Valibhav,

    Thanks.

    That appears to have eliminated the DISPC error.

    2 questions:

    1. what is the best/fastest way for me to be aware of such patches in the future? is there an email list/notification method I should sign-up for to see such patches?

    2. This warning is causing a huge back-trace error (see below this line) - is it OK to suppress it? Our customer might become quite distressed if they see this backtrace message every time the CPU PLL shifts frequency when using the ondemand governor:

    ------------[ cut here ]------------
    WARNING: at arch/arm/mach-omap2/dpll.c:439 omap3_noncore_dpll_set_rate+0x220/0x2                   64()
    Modules linked in:
    [<c003c464>] (unwind_backtrace+0x0/0xd0) from [<c005da6c>] (warn_slowpath_common                   +0x48/0x60)
    [<c005da6c>] (warn_slowpath_common+0x48/0x60) from [<c0046440>] (omap3_noncore_d                   pll_set_rate+0x220/0x264)
    [<c0046440>] (omap3_noncore_dpll_set_rate+0x220/0x264) from [<c0044ac0>] (omap2_                   clk_set_rate+0x20/0x2c)
    [<c0044ac0>] (omap2_clk_set_rate+0x20/0x2c) from [<c0049aa4>] (clk_set_rate+0x38                   /0x78)
    [<c0049aa4>] (clk_set_rate+0x38/0x78) from [<c00484c8>] (program_opp+0x88/0x104)
    [<c00484c8>] (program_opp+0x88/0x104) from [<c0048634>] (resource_set_opp_level+                   0xf0/0x160)
    [<c0048634>] (resource_set_opp_level+0xf0/0x160) from [<c00486e0>] (set_opp+0x3c                   /0xf8)
    [<c00486e0>] (set_opp+0x3c/0xf8) from [<c004f558>] (update_resource_level+0xa8/0                   xcc)
    [<c004f558>] (update_resource_level+0xa8/0xcc) from [<c0048418>] (set_freq+0xb8/                   0xe0)
    [<c0048418>] (set_freq+0xb8/0xe0) from [<c004f558>] (update_resource_level+0xa8/                   0xcc)
    [<c004f558>] (update_resource_level+0xa8/0xcc) from [<c004e83c>] (omap_target+0x                   50/0x6c)
    [<c004e83c>] (omap_target+0x50/0x6c) from [<c0261950>] (__cpufreq_driver_target+                   0x28/0x38)
    [<c0261950>] (__cpufreq_driver_target+0x28/0x38) from [<c02643a8>] (do_dbs_timer                   +0x264/0x2cc)
    [<c02643a8>] (do_dbs_timer+0x264/0x2cc) from [<c0071760>] (worker_thread+0x18c/0                   x204)
    [<c0071760>] (worker_thread+0x18c/0x204) from [<c00748f0>] (kthread+0x7c/0x84)
    [<c00748f0>] (kthread+0x7c/0x84) from [<c0038854>] (kernel_thread_exit+0x0/0x8)
    ---[ end trace b519163b88b60dbb ]---

    it seems benign. I'm tempted to comment out the warning.

    thanks and best regards,

    Peter Thoeming

  • 0 in reply to Peter Thoeming
    Intellectual 300 points

    New problem.

     

    ondemand also kills audio streaming through MCBSP to ALSA.

    If ondemand is turned off, then the MCBSP buffer error does not occur.

    Error log output is:

     

    Normal 0 false false false EN-US X-NONE X-NONE

    + arecord -f cd -D hw:1,0

    + aplay -f cd -D plughw:0,0

    Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

    11:1:1: cannot get freq at ep 0x81

    Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

    underrun!!! (at least 81.476 ms long)

    underrun!!! (at least 72.641 ms long)

    underrun!!! (at least 22.452 ms long)

    underrun!!! (at least 1023.859 ms long)

    underrun!!! (at least 22.369 ms long)

    underrun!!! (at least 68.985 ms long)

     

    Has ondemand been tested for use on the OMAP?

    First the DISPC must be tweaked by adjusting some OCP setting and now the MCBSP buffers to ALSA underrun.

     

    The implication is that  every I/O path is going to fail while the CPU is allowed to have a dynamic clock and it appears that somehow the entire switching fabric must be "tuned" for any given application that intends to use a frequency-throttled CPU.

    This is non-obvious.

    Is there a document describing every subsystem that must be re-configured in order for use of the ondemand governor to work without killing peripheral functionality?

     

  • 0 in reply to Peter Thoeming
    Intellectual 270 points

    Hi Peter,

    Did you get any fix for the kernel back-trace error? If yes, can you share with us? Thanks. 

     

    Kalai

  • 0 in reply to Kalaiselvan Rajagopal
    Intellectual 300 points

    I'm sorry, but that was too long ago.

    I do not remember the solution except that we no longer have any issues like that above.

    we do use ondemand on the OMAP3525 without any issues.

    However, we turned off the entire video path because we decided not to do video rendering in our product.

    That may be why we no longer see an issue.

    sorry...

  • 0 in reply to Peter Thoeming
    Intellectual 270 points

    Thanks for your quick reply.  

  • 0 in reply to Kalaiselvan Rajagopal
    Prodigy 40 points

    I am having the same problem. I'm also looking for any other OMAP3EVM patches needed to get cpufreq working reliabliy.

     

  • 0 in reply to Steve McClellan
    Intellectual 300 points

    I'm assuming you're having the same problem with getting the display to work consistently and not some other problem with cpufreq scaling using the ondemand governor.

    There is an OCP INITIATOR value that can be set in the kernel to make sure that an absolute minimum BW is maintained for specific sub-systems that are DMA capable. That way, even when the CPU clock frequency falls,

    I don't remember how the display sub-system gets its data from across the Sonics backplane (switching fabric), but the TRM probably defines if it has it's own DMA initiator and if it does, then the kernel should have a data structure whose member value for minimum BW can be adjusted.

    for example for the DSS:

            omap_pm_set_min_bus_tput(&dssdev->dev, OCP_INITIATOR_AGENT, 400000);

    To look for patches that might include such a "tweak" that are maintained, you can check the mainline Linux kernel git.

    Or also the Arago git that holds TI OMAP3xxx patches:

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary

     

    regards,

    Pete

     

     

     

  • 0 in reply to Peter Thoeming
    Intellectual 270 points

    I tweaked the ti's patch that they provided in this thread in a way that it doesn't set the OCP INITIATOR value to zero when DSS set to sleep. Without that tweak, the same error (omap dss:dispc error underrun error) had happened when the cpufreq scaling_setspeed was changed when LCD in sleep (auto shutoff after set time). I don't know whether you have LCD autoshutoff option enabled in your case. Just thought of sharing my suggestion.    

  • 0 in reply to Kalaiselvan Rajagopal
    Prodigy 40 points

    Thanks for your reply. I see this as well.

    Is your "tweak" setting OCP INITIATOR to 400000 in omap3_evm_disable_lcd() or some other value?

    Thanks

    --stevem