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 on the ARM side of the OMAP-L138

Other Parts Discussed in Thread: OMAP-L138, SYSBIOS

Hello,

I've some questions related to the cpuFreq on the ARM side of the OMAP-L138.
I'm the following versions on the ARM side of the OMAP-L138:
- CCS Version 4.2.1.00004
- SYS/BIOS 6.30.03.46 (eabi) ELF
- TMS470 Code Generation Tools 4.6.4
- XDCTOOLS 3.20.07.86

I've also my own platform package, where the Clock Speed (MHz) is set to 300.0
Within the ARM configuration I'm using the module ti.sysbios.BIOS, where the cpuFreq is set to 300MHz (hi = 0, lo = 300000000).

PLL settings for 300MHz are done via AISgen.

We are now planning to set the frequencies (for ARM and DSP to 456 MHz).

Q1: Are there any other settings beside the platform package (456.0), the ti.sysbios.BIOS (lo = 456000000) and PLL settings withn AISgen which need to be modified?

Q2: What is SYS/BIOS resp. the XDCTOOL exactly doing with these CPU frequency settings?

In SPRUEX3K (December 2011) I found an example how to lower the clock module frequency.
page 129/257
Runtime example: This C example uses some of the Clock APIs to lower the Clock module frequency

BIOS_getCpuFreq(&cpuFreq);
cpuFreq.lo = cpuFreq.lo / 2;
BIOS_setCpuFreq(&cpuFreq);

key = Hwi_disable();
Clock_tickStop();
Clock_tickReconfig();
Clock_tickStart();
Hwi_restore(key);

Q3: As my clock module is using a timer as tick source (and intFreq of the timer is set fixed to 24000000 in the configuration), for what do I need to change then the CPU frequency (what is the relationship between clock and CPU frequency)?

Thanks,
Frank

  • Frank,

    Q1 - Only other I can think of is Timer frequency...but as you stated that yours is fixed so then you should not need to change it.

    Q2 - SYSBIOS uses it to calculate CPUload.  Also some Timers run at a fraction of the CPU frequency, so in that case, it is used to determine the timer period.

    Q3 - Well, in your case looks like CPU and clock are independent of one another so there's no need to update the clock when you change CPU.  In some devices
             they are tied to one another so in that case, changing CPU requires an update to the Clock frequency also.

    Judah

  • Judah,

    thanks.

    More questions are popping up.

    Let's assume we have an OMAPL-138 with a DSP and an ARM both running already with 300MHz cpu frequency and we like to switch to 456MHz dynamically initiated by the DSP.
    In this case the DSP will need to change the PLLs according chapter "8.2.2.3 Changing PLL Multiplier" of SPRUH77A (December 2011, the OMAP-L138 DSP+ARM Processor Technical Reference Manual).

    Q4: Is my understanding of your previous answers correct, that on ARM side (if I'm not using CPU load calculations) the cpuFreq need not to be changed?

    Q5: When doing such a scenarion, need something else to be done by either the DSP or the ARM?
    I'm thinking about
    - hold the ARM in (local) reset during the PLL change
    - what about the clocks going to the ARM
    - what about the AINTC

    Q6: Is this a valid scenario?

    Q7: If answer to Q6 is yes, exists there any documentation (cook book) for such a scenario?

    Frank

  • Q4 - Yes, i think if you don't care about CPUload then there's not requirement to change cpu freq on the ARM.

    Q5 - Why would you need to hold the ARM in local reset?  I don't think that is needed.  The timing will change but the CPU will still continue to execute.  However, I recommend following the policy for changing PLL if there is one.

    Q6 - Typically the ARM is like the master and the DSP is the slave so the ARM usually does this type of thing as oppose to the DSP changing something like the PLL.  Other than that, I don't see why this would not be valid.

    Q7 - Sorry, I don't know of any documentation for doing something like this.

    Judah

  • Judah,

    thanks for your fast response.

    I'll close this ticket.

    Frank