NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.

Power Management in SA WINCE BSP

From Texas Instruments Wiki
Jump to: navigation, search

PM Status Summary[edit]

This wiki provides a quick summary of the current status of Power Management module in Sub-Arctic WinCE BSP (SA BSP). Most of the code and infrastructure are in place and many of the pieces have been unit tested. We believe that 80% of the code is present and 20% needs to be tweaked/added. In addition final integration and testing is left to be done. To rule out hardware/silicon/system issues, this should be undertaken after CM3 firmware is fully functional in Linux’s PM framework. Following sections in this note provide more details about different PM pieces and their respective states.

PRCM
[edit]

Most of the PRCM APIs are implemented in SA BSP and on par with OMAP3530 BSP. The main chunk of code is in prcm_device.c, prcm_clock.c, prcm_domain.c, prcm_reset.c (\COMMON\SRC\SOC\COMMON_TI_V1\AM33X\OAL\PRCM). The device table is defined in prcm_device.h. The clock and clock domain tables are defined in prcm_clock.c. OPP modes are implemented in \AM33X_BSP\SRC\OAL\OALLIB\opp_map.c and \AM33X_BSP\SRC\INC\bsp_opp_map.h - but it is not hooked up with DVFS. The only way to change OPP mode is through Eboot menu.


CPU Idle
[edit]

CPU Idle is implemented and working in SA BSP. The code is in \COMMON\SRC\SOC\COMMON_TI_V1\AM33X\OAL\CPUIDLE\cpu.s (OALCPUIdle) and \COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI_AMXX\OAL\TIMER\GPTIMER\timer.c (OEMIdle). CM3 is not involved during CPU idle.

One can use the shell command "cpuidle" or "do cpuidle" to get the CPU load.


CM3
[edit]

In the existing BSP, CM3 code is split into two parts - (1) PRCM related code in OAL PRCM module and (2) CM3 firmware loading driver. The PRCM code is the main code that takes care of communicating with the CM3, setting up mailboxes, configuring IPC regs, handling CM3 interrupt, etc. On init, the CM3 firmware driver just does the job of reading firmware.bin from windows folder and loading it in CM3 code space. It then calls a PRCM function to release CM3 from reset. Details about CM3 firmware and the communication between CM3 and ARM-A8 can be found here. The firmware.bin is the CM3 firmware downloaded from CM3 arago project and is placed at AM33X_BSP\Files folder. Platform.bib makes sure that this file is located in the windows folder on bootup.

The interaction between ARM and CM3 in the existing BSP is described below:

1. On device bootup, during OAL PostInit(), PrcmCM3Init() is called which sets up the CM3 interrupt handler and initializes the mailbox.

2. Then, when the CM3 firmware driver is loaded by device manager, it reads and loads the CM3 firmware (firmware.bin) into CM3 code space. It then calls PrcmCM3ResetAndHandshake() to release CM3 from reset.

3. CM3 starts executing and signals back to A8 if setup is successful. In the meantime, CM3 firmware driver busy waits for this signal from CM3.

4. After this CM3 executes WFI and is waiting for a mailbox interrupt from ARM.

5. When system goes into suspend, PRCM sets up the IPC regs as per desired suspend state (DSx) and then sends a mailbox interrupt to CM3.

6. CM3 checks the IPC regs and then waits for ARM to execute WFI.

7. After performing the required steps for suspend, ARM executes WFI.

8. CM3 now receives a PRCM interrupt and does the needful to put the system in desired DSx state.

9. On wakeup interrupt, CM3 wakes up the ARM and ARM continues to resume to functional state.


Suspend Resume
[edit]

Code
[edit]

The main crux of the suspend resume code is in following files:

1. \AM33X_BSP\SRC\OAL\OALLIB\oem_pm.c

2. \AM33X_BSP\SRC\OAL\OALLIB\power.c

3. \COMMON\SRC\SOC\COMMON_TI_V1\AM33X\OAL\PRCM\prcm.c

When the system goes to suspend, the WinCE PM driver puts all the drivers in D4 state. After that, it calls the OEMPowerOff function with global interrupts disabled (via CPSR bit). OEMPowerOff function is implemented in oem_pm.c.

This function disables Watchdog, KITL, High Performance Timer, Interrupts in INTC (except for CM3 interrupt).

It calls BSPPowerOff to do BSP/board specific stuff. Under ideal case, when suspend resume is working, BSPPowerOff() disables the Timer and debugUart. For debugging purposes, a function BSPDebugTurnOFFClocks() have been provided. This function checks which modules are still enabled and then turns them off. Ideally, one should not be needing this function if the drivers are doing their job of disabling modules and their clocks while going to D4. This function uses a list skipCheckDeviceList to skip WAkEUP domain devices, DEBUGSS (needed for CCS/JTAG debugging), EMIF, OCMC RAM, Interconnect modules. So use this function only when debugging suspend resume and not in production builds. Since debug UART (UART0) belongs to wakeup domain, you can keep this module enabled and use it for debugging suspend resume issues.

After disabling all necessary clocks, OEMPowerOff() reduces the MPU domain to OPP50 and CORE domain voltage to OPP50 (not the frequency).

It then calls PrcmSuspend() function implemented in prcm.c. This function clears any pending timer interrupt (so that ARM doesnt wakeup immediately after entering WFI). It then fills up the IPC registers with CM3 message for the desired Deepsleep mode. The desired deepsleep mode is set using the variable _suspendState in the same file. PrcmCM3ConfigDeepSleep() takes care of setting up the IPC regs, sending the message across to CM3 and doing the proper handshake. PrcmSuspend() then calls PrcmPreSuspendDisableClock() to disable any clocks for which there are no drivers in the SA BSP. There are bunch of wakeup sources available on SA - the current code uses DMTIMER1MS to test suspend resume. It then calls OALCPUIdle using function pointer - since we want the CPUIdle code to run from OCMC RAM (so that EMIF can be disabled). The OALSRAMFnInit() in prcm.c moves all the suspend resume related code (see cpu.s) to OCMC RAM on bootup. OALCPUIdle() checks the suspendState in CPU_INFO structure and decides if the system is going into deepsleep or not. Under normal running conditions, suspendState is set to PM_CMD_NO_PM (no suspend) and OALCPUIdle just executes WFI to enter idle state (this is how OEMIdle works). Under suspend scenario, suspendState is same as _suspendState and OALCPUIdle saves the ARM context and executes WFI. On executing WFI, CM3 takes over and does the needful to enter the desired Deepsleep mode.

On wakeup interrupt from one of the wakeup sources (DMTIMER1MS in this case), CM3 wakes up ARM. If the desired state was DS2, then ARM starts executing from the next line after WFI. For DS0 and DS1, Rom code executes first and jumps to OALCPURestoreContext (since this is the pointer set in IPC REGS 0). OALCPURestoreContext() restores the ARM context saved by OALCPUIdle and then jumps to next line in PrcmSuspend() after OALCPURestoreContext. PrcmSuspend and OEMPowerOff then do the reverse of what happened while going into suspend.


Current Status
[edit]

DS2
[edit]

There was a bug in CM3 firmware dated 11/02/2011. So this state was not fully tested.

DS1
[edit]

ARM could enter DS1 state. The Master OSC was also turned off. But it could never resume. The reason being that the wakeup sources (TSC, RTC, DMTIMER1MS) generated regular interrupts but not wakeup interrupts. CM3 wakes up ARM only when wakeup interrupts are received. Why wakeup sources do not generate wakeup interrupt needs to be debugged further.

DS0
[edit]

This cannot be tested until Peripheral Save/Restore Context is implemented.

RTC-only
[edit]

PG1.0 silicon has a bug for RTC only mode. So this mode can be tested only when new PG comes out.


Flags
[edit]

The suspend resume code (described above) is commented out in existing SA BSP and can be enabled by setting the flag TEST_SUSPEND_RESUME in oem_pm.c. To enable debug code for suspend resume, enable the flag DEBUG_PRCM_SUSPEND_RESUME in AM33X_BSP\sources.cmn.


Wake-Up Sources[edit]

In the existing code, DMTIMER1MS is used as the wakeup source. To disable this, disable the flag USE_TIMER1_AS_WAKEUP_SOURCE in prcm.c. To use RTC as wakeup source, USE_RTC_AS_WAKEUP_SOURCE flag should be enabled in prcm.c. For RTC, one will need to do some extra configuration which is not present in the existing BSP:

Changes needed are:
  1. Set SYSCONFIG register to Smart Idle w/ wakeup
  2. Use 32768 Crystal as the source and not the PER PLLL 32K output; set the OSC register accordingly
  3. Enable alarm wakeup interrupt.

Touchscreen can also be used as a wakeup source. You will have to modify the driver to flush all FIFOs and make sure the module gets disabled (including the functional clock) on entering D4.


Drivers - Known Issue[edit]

1. EDMA driver doesnt follow any power management. This needs to be implemented before testing DS0 state.

2. When DMA is enabled in display driver, the system gets stucks when going into suspend. OEMPowerOff() is not even called. This needs to be debugged. For the existing BSP, DMA was turned off in display driver registry when testing/debugging suspend resume.

3. For USB, the sysconfig register should be set to force idle on entering D4, otherwise the USBSS will not transition to disabled state.



Pending Work
[edit]

1. There are lot of APIs/IOCTLs defined in EVM_OMAP3530\SRC\OAL\OALLIB\oem_pm.c that are not implemented in SA BSP because:

       (a) They do not apply for SA chip OR

       (b) they are needed for PM policies management or advanced suspend resume functionality (like DS0) which is still not available in this BSP

2. SmartReflex is disabled in BSP since the h/w doesnt support it yet

3. None of the PM policies have been implemented (DVFS, CPU Load Policy, Interrupt Latency, DEVMON). From requirements perspective, it is not clear if any of these are even needed.

4. Drivers - All drivers need to be tested if they disable the clocks correctly when going to D4 and are able to recover to functional state on resume (D0)

5. Peripheral Context Save/restore - Logic needs to be added to do context save of peripheral domain registers when going into DS0 state on suspend. Similar logic needs to be added to restore their context on resume from DS0 state. If one wants to follow the OMAP way of doing this, then the OMAP Bus driver will have to be ported for SA BSP. Currently SA BSP doesnt use/include the OMAP Bus driver.

6. Testing/Debugging Suspend resume - all DSx and RTC-only states should be tested

7. Sometimes system gets stuck when entering suspend (this is with DMA disabled in display driver). OEMPowerOff() is not even called. So suspicion is that the system is stuck at some driver level trying to put a module in D4 state. This needs to be debugged. For now, the workaround is to reboot the board and try again.


LINKS
[edit]

1. http://processors.wiki.ti.com/index.php/AM335x_StarterWare_Power_management

2. http://processors.wiki.ti.com/index.php/StarterWare

3. http://ap-fpdsp-swapps.dal.design.ti.com/index.php/AM335x_Power_Consumption_Data



E2e.jpg {{
  1. switchcategory:MultiCore=
  • For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
  • For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article Power Management in SA WINCE BSP here.

Keystone=
  • For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
  • For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article Power Management in SA WINCE BSP here.

C2000=For technical support on the C2000 please post your questions on The C2000 Forum. Please post only comments about the article Power Management in SA WINCE BSP here. DaVinci=For technical support on DaVincoplease post your questions on The DaVinci Forum. Please post only comments about the article Power Management in SA WINCE BSP here. MSP430=For technical support on MSP430 please post your questions on The MSP430 Forum. Please post only comments about the article Power Management in SA WINCE BSP here. OMAP35x=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Power Management in SA WINCE BSP here. OMAPL1=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Power Management in SA WINCE BSP here. MAVRK=For technical support on MAVRK please post your questions on The MAVRK Toolbox Forum. Please post only comments about the article Power Management in SA WINCE BSP here. For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Power Management in SA WINCE BSP here.

}}

Hyperlink blue.png Links

Amplifiers & Linear
Audio
Broadband RF/IF & Digital Radio
Clocks & Timers
Data Converters

DLP & MEMS
High-Reliability
Interface
Logic
Power Management

Processors

Switches & Multiplexers
Temperature Sensors & Control ICs
Wireless Connectivity