• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 493 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.

OMAP3525 IVA C6x DSP Frequency Scaling - can it be decoupled from the OMAP frequency scaling?

Peter Thoeming
Intellectual 300 points

Our OS is based on the Linux2.6.32 kernel/drives distributed by TI in PSP3.0.1.6 release.

We are using the DVSDK code for testing and developing audio encoding capable for analog audio inputs.

We have enabled the ondemand governor.

At idle, we are at OPP1: ARM@125MHz; DSP@90MHz.

When we begin encoding an analog stream, the ondemand governor throttles the system to OPP2: ARM@250MHz; DSP@180MHz

The problem is that the ARM CPU load does not correlate to enough processing power in the DSP to perform REALTIME encode of the incoming audio stream.

Furthermore, if multiple encodes are enabled in parallel, the problem gets even worse as the ARM does not require a higher OPP, but the DSP does.

 

Is it possible for the DSP to monitor its own load and scale its own frequency independantly of the ARM CPU that is governed by the ondemand governor?

If yes, what documentation or kernel source code should I reference to enable this?

 

Can the DSP PWRM do this on its own?

 

Best regards,

Peter Thoeming

 

 

  • 0
    TI__Expert 4590 points

    Yes, you are right that ondemand governor doesn't take into account the loading on DSP.
    Also, i would recommend you to keep the ARM and DSP in one of the pre-defined OPPs - not scale them individually.
    I couldn't understand the full system context - but i feel you need DSP at higher performance only during the encode operation - single/multiple streams.
    You can try the following scheme:

    • Include both ondemand and userspace governors in your kernel.
    • Let ondemand governot be default - to maximize power savings.
    • When the application starts, switch to userspace governor.
    • Set the OPP where you expect DSP algorithm to work as expected.
    • Once application completes, switch back to ondemand governor.
  • 0 in reply to Sanjeev Premi
    Intellectual 300 points

    Mr. Premi,

    That seems to be a rather simple solution that should be easy for us to use, so for now, we will plan on that.

    I think you have given us an answer we can use, but I'd also like to understand all other potential options, if they already exist in the DVSDK and 3.0.1.6 provided by TI...

    For example, is there no option in the kernel settings for other options?

    what about in the DSP code provided with the DVSDK - can the DSP PWRM be adjusted to do this?

     

    Thanks again,

    Peter

  • 0 in reply to Peter Thoeming
    TI__Expert 4590 points

    Peter Thoeming said:

    That seems to be a rather simple solution that should be easy for us to use, so for now, we will plan on that.


    Do share your experience once you have it implemented.

    Peter Thoeming said:

    For example, is there no option in the kernel settings for other options?
    what about in the DSP code provided with the DVSDK - can the DSP PWRM be adjusted to do this?

    I am afraid, there is no kernel setting today that lets Linux (running on ARM) understand the loading on DSP; unless the feature has been deveoped as part of DVSDK. I will let someone with better understanding of the DVSDK and DSP PWRM respond to these queries.

  • 0 in reply to Sanjeev Premi
    Intellectual 300 points

    After testing our design, we found that the best solution was to empirically determine the minimum DSP operating frequency necessary for the performance required for our product, then use SW running on the ARM to adjust the minimum frequency allowed for use by the ondemand governor.

     

    For example, if we know that we are about to turn-on AAC encode and sample rate conversion, we know that we require that the DSP run at 180MHz, at a minimum.

     

    this corresponds to an ARM clock of 250Mhz, therefore our ARM userspace app would issue this command:

     

    echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

     

    when the need to run the DSP at higher or lower performance changes, our SW simply changes the scaling_min_freq value as well.

     

    It works fine for our application.