• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 548 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.

Sitara AM3359 FW Low Power States

Jared Becker
Genius 11845 points
Other Parts Discussed in Thread: AM3359

Hi team,

I have some questions regarding the Sitara AM3359 FM support below.

Idle Power Management

I am trying to reduce power using the IDLE power management feature.

I realize there are deeper sleep states that save more power but we can not use them because the system must be up collecting data all the time. In case it is relevant my am335x-pm-firmware.bin reports CM3 Firmware Version 0x190.

First of all I notice only a very small difference with IDLE power management enabled in the kernel, roughly only 3-4% when sitting at a bash prompt with the MPU at 99% idle.

The idle power management relies on the processor WFI instruction which according to this article changed in armv7.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/CJAHGJEF.html

This states: "WFI existed as a CP15 operation in many earlier processors. ARMv7 redefines the CP15 operation as a NOP."

The Sitara is cortex-a8 armv7-a, so maybe the WFI is moved to a new instruction?

It looks to me like the idle power management uses WFI and also memory autorefresh.

Is it possible that the WFI portion is acting as NO-OP?

I am using arm gcc version 4.7.3 with mtune=cortex-a8  

Is it possible that I need a newer compiler to emit a newer WFI instruction code?

Also, we will be using the PRUs. Can the MPU enter the WFI state with the PRUs runing?

Thanks in advance.

Jared

  • 0
    TI__Guru*** 125430 points

    Jared Becker said:

    This states: "WFI existed as a CP15 operation in many earlier processors. ARMv7 redefines the CP15 operation as a NOP."

    The Sitara is cortex-a8 armv7-a, so maybe the WFI is moved to a new instruction?

    I think you misunderstood that sentence.  It is saying:

    • Prior to ARMv6K low power modes were implemented with a CP15 register.
    • In ARMv6K low power modes were implemented with a new WFI instruction as well as the older CP15 register access.
    • In ARMv7 they got rid of the old CP15 method and use only WFI for this purpose.

    Jared Becker said:
    Is it possible that I need a newer compiler to emit a newer WFI instruction code?

    That shouldn't be an issue.

    Have you read some of the documentation here:

    http://processors.wiki.ti.com/index.php/Linux_Core_Power_Management_User's_Guide_%28v3.14%29#CPUIdle

    In particular, I think you need to do some profiling to understand how much time you're spending in the C-states.  You need to be in the C2 state in order to have clock gating.  Are you sure you're getting to C2?

    Jared Becker said:
    Also, we will be using the PRUs. Can the MPU enter the WFI state with the PRUs runing?

    Yes.

    Jared Becker said:

    ITEM #2 - Timer Capture Mode.

    I will be looking at getting Timer5&6 to operate in capture mode. I see some evidence of a timer driver in the kernel. It looks like many people use them to generate PWM signals - not what we need. We need to use the capture mode to grab a time-stamp on a signal edge.

    Does the kernel have a working driver for this and if so can you supply any info on how to make use of it?

    I recommend renaming this thread to focus on low power states and start a new thread for this question.

  • 0
    TI__Mastermind 25966 points
    Though the screenshots on the below post are old, I've repeated on ProcessoerSDK1.03 with CCSv6.1. You can clearly see a WFI in the disassembly: e2e.ti.com/.../737657

    >>Also, we will be using the PRUs. Can the MPU enter the WFI state with the PRUs runing?
    Deepsleep1 which is "echo standby > /sys/power/state" as documented here: processors.wiki.ti.com/.../AM335x_Power_Management_Standby_User's_Guide
    and not the Deepsleep0 which is seen in the above post (and documented here).

    The difference from a HW standpoint can be see on pp. 1122-1123 of the TRM (www.ti.com/.../spruh73l.pdf).
    In DS0, PD_PER = OFF. And since PRU is on the PER domain, you have to use DS1.