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

OMAP Off Mode Using More Power than Retention

Chris Read
Genius 3345 points

Other Parts Discussed in Thread: TPS65950, OMAP3530

I am working on getting our system (OMAP3530 and TPS65950) to idle and sleep at its lowest power states possible.  I had assumed that enabling off mode (echo 1 > /debug/pm_debug/enable_off_mode) would lower the system power, but instead it goes up!  It is most obvious in suspend mode, where it uses 27mA more current from the TPS65950's 4.2V supply when enable_off_mode is 1 than when it is 0.

 

Any suggestions as to why?

  • 0
    TI__Genius 16690 points

    Can you tell the device successfully did suspend and resume with "enable_off_mode" ? Can you check if OFFENABLE bit in pad configuration register is enabled or not for the registers listed in "Table 7-4. Core Control Module Pad Configuration Register Fields" in the TRM ? When the device is transitioned to OFF state with OFFENABLE bit is enabled in the pad configuration registers, the pad configuration will be replaced with the settings set in off mode value in "Figure 7-7. Pad Configuration Register Functionality". If the pad configurations are not optimized for your hardware, they may cause higher current at pads and you may see the current increase at the 4.2 V supply. There is a wiki describes the guideline for the pad configuration optimization in off mode.

  • 0 in reply to kshin
    Genius 3345 points

    I have been working on this now for a while, and had been looking at the OFF mode bits, but now I'm quite concerned.  The OFFOUTENABLE bit is actually an OFFINENABLE bit, since OFFOUTENABLE is asserted low.  It might be OK if that was the only problem, but the arch/arm/mach-omap2/mux.h file seems to propagate the error, as it defines

    #define OMAP_OFFOUT_EN                  (1 << 10)

    and

    #define OMAP_PIN_OFF_OUTPUT_HIGH        (OMAP_OFF_EN | OMAP_OFFOUT_EN \
                                                    | OMAP_OFFOUT_VAL)
    #define OMAP_PIN_OFF_OUTPUT_LOW         (OMAP_OFF_EN | OMAP_OFFOUT_EN)
    #define OMAP_PIN_OFF_INPUT_PULLUP       (OMAP_OFF_EN | OMAP_OFF_PULL_EN \
                                                    | OMAP_OFF_PULL_UP)
    #define OMAP_PIN_OFF_INPUT_PULLDOWN     (OMAP_OFF_EN | OMAP_OFF_PULL_EN)

    this seems to say that the OFFOUTENABLE bit is asserted high.  I suppose that's why there's something so confusing as this:

    #ifdef CONFIG_KEYBOARD_TWL4030
            OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
                                    OMAP_PIN_OFF_INPUT_PULLUP | OMAP_PIN_OFF_OUTPUT_LOW |
                                    OMAP_PIN_OFF_WAKEUPENABLE),
    #endif

    in the board-omap3sg2.c file.  Here it looks like OFF mode is configured as both an input pullup and an output low.  That's totally confusing.