• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 97 subscribers
  • Views 2153 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.

AM3351 : Power management standby/wake up issue

Manoj Kumar
Intellectual 900 points

Other Parts Discussed in Thread: AM3351

In our AM3351 based custom board,  we are working on power management . Here we are facing two issue.

1) The resume is not properly happening after entering standby mode. Console is getting hang after wakeup and I'm using GPIO0 as wakeup source. Below is the log

[ 447.038156] PM: Syncing filesystems ... done.
[ 447.068369] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 447.080560] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 448.324334] PM: suspend of devices complete after 1233.793 msecs
[ 448.331614] PM: late suspend of devices complete after 1.201 msecs
[ 448.339551] PM: noirq suspend of devices complete after 1.585 msecs
[ 448.345969] PM: Successfully put all powerdomains to target state
[ 448.345969] PM: Wakeup source GPIO0
[ 448.347510] PM: noirq resume of devices complete after 1.382 msecs
[ 448.355143] PM: early resume of devices complete after 0.832 msecs
[ 450.313815] brcmf_sdio_bus_rxctl: resumed on timeout

(hangs)

2) We connected the leds in common anode mode to the processor as shown below

So when the processor enters into standby mode, led gpios are configured to pulldown, which makes the LED to glow at standby mode. To override this, I have added pinmux control for sleep in device tree as follow,

led_gpio_default: pinmux_led_gpio_default {
pinctrl-single,pins = <
0x20 ( PIN_INPUT | MUX_MODE7 ) /* gpmc_ad8.gpio0[22] */
0x24 ( PIN_INPUT | MUX_MODE7 ) /* gpmc_ad9.gpio0[23] */
0x28 ( PIN_INPUT | MUX_MODE7 ) /* gpmc_ad10.gpio0[26] */
>;
};

led_gpio_sleep: pinmux_led_gpio_sleep {
pinctrl-single,pins = <
0x20 ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* gpmc_ad8.gpio0[22] */
0x24 ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* gpmc_ad9.gpio0[23] */
0x28 ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* gpmc_ad10.gpio0[26] */
>;
};

leds {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&led_gpio_default>;
pinctrl-1 = <&led_gpio_sleep>;
compatible = "gpio-leds";

led@1 {
label = "red";
gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
default-state = "on";
};

led@2 {
label = "blue";
gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;
default-state = "on";
};

led@3 {
label = "green";
gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
default-state = "on";
};

};

But still the leds are on, when the processor enters into standby mode. Whether by default it will only configure the gpio as pulldown...?

How to solve the above issues..

  • 0
    TI__Guru**** 161600 points
    Hi Manoj,

    Can you try with the noconsole suspend option, to see if you'll get anything more (debug log) out of the terminal & share the results?
    Also which SDK is this? Are you working on a TI Reference board or a Custom board?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 900 points
    Hi Yordan,

    It is our own custom board and we are using processor-sdk-02.00.02.11. I have tried with and without console suspend and below are the logs

    root@am335x:/# echo 0 > /sys/module/printk/parameters/console_suspend
    root@am335x:/# echo standby > /sys/power/state
    [ 409.451714] PM: Syncing filesystems ... done.
    [ 409.484723] Freezing user space processes ... (elapsed 0.002 seconds) done.
    [ 409.494725] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
    [ 411.023969] PM: suspend of devices complete after 1519.286 msecs
    [ 411.031256] PM: late suspend of devices complete after 1.217 msecs
    [ 411.039204] PM: noirq suspend of devices complete after 1.594 msecs
    [ 411.045621] PM: Successfully put all powerdomains to target state
    [ 411.045621] PM: Wakeup source GPIO0
    [ 411.047168] PM: noirq resume of devices complete after 1.390 msecs
    [ 411.054801] PM: early resume of devices complete after 0.826 msecs
    [ 413.013714] brcmf_sdio_bus_rxctl: resumed on timeout

    root@am335x:/# echo 1 > /sys/module/printk/parameters/console_suspend
    root@am335x:/# echo standby > /sys/power/state
    [ 165.501263] PM: Syncing filesystems ... done.
    [ 165.536400] Freezing user space processes ... (elapsed 0.002 seconds) done.
    [ 165.548236] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
    [ 165.556896] Suspending console(s) (use no_console_suspend to debug)


    When console suspend = 1, I'm not seeing any wakeup log in the console.


    Regards,
    Manoj
  • 0
    TI__Guru**** 161600 points

    Hi, 

    Manoj Kumar said:
    But still the leds are on, when the processor enters into standby mode. Whether by default it will only configure the gpio as pulldown...?

     

    Can you try configuring the led_gpio_sleep as ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) & led_gpio_default as ( PIN_INPUT_PULLUP | MUX_MODE7 )? Do you get the leds to stop glowing when device is in standby? 

    As for the console hanging after wake up, this is strange.. Can you add some debug prints in omap8250_suspend() & omap8250_resume() functions, to try and track if the kernel invokes them correctly. 

    Best Regards, 
    Yordan

  • 0 in reply to Yordan Kovachev
    Intellectual 900 points

    Hi Yordan,

    The problem is on the broadcom wifi driver

    "brcmf_sdio_bus_rxctl: resumed on timeout"

    Before going into standby mode, I removed broadcom wifi driver, then suspend/wakeup works perfectly. Broadcom wifi driver is expecting SDIO interrupt from broadcom wifi chipset, for some reason it is not getting the interrupt.  

    For leds, I tried the configuration you mentioned, but still LED is glowing when I enter into standby mode. I tried with led_gpio_sleep as ( PIN_OUTPUT_PULLUP | MUX_MODE7 ), but led gpio pins are always low, during standby mode which makes led to glow.

    Since Led pins by default goes to pulldown on standby, I'm having doubt on SDIO pins sleep mode configuration( but I didnt configure sleep pin configuration for Wifi SDIO pins), which may prevent SDIO interrupt. 

    So how to override this standby mode pin configuration..?

    Regards,

    Manoj

  • 0 in reply to Manoj Kumar
    TI__Guru**** 161600 points

    Hi Manoj,

    What is the voltage level you get out of the gpio pins, when you set them high? Is it equal to the 3V3, which you use to power the leds? 

    I've made a mistake, you need to drive the pins high in sleep state, if you want to get the diodes to stop golwing.. so on sleep you should try with PIN_INPUT_PULLUP or just PIN_INPUT  (without any pulls)... sorry for the confusion.

    Can you double check if gpio pins are NOT used by any other dts node. If they are used by other dts node, this may overwrite the user_led_sleep settings.

    Just for the test, can you try toggling the gpio through sysfs (/sys/class/gpio): 

       echo <gpio_pin> > export

       echo 1 > <gpio_pin>

     Do you get the diodes to blink? 

    Best Regards,

    Yordan

  • 0 in reply to Yordan Kovachev
    TI__Guru**** 161600 points
    Can you share your dts?

    Also, when testing with sysfs entries, verify that you're using the correct gpio numbers.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 900 points
    Hi Yordan
    When the processor goes suspend mode, the led class driver (drivers/leds/led-class.c) always make the particular gpio to low logic. Below is the code which cause suspend in led driver.
    void led_classdev_suspend(struct led_classdev *led_cdev)
    {
    led_cdev->flags |= LED_SUSPENDED;
    led_cdev->brightness_set(led_cdev, 0);
    }
    EXPORT_SYMBOL_GPL(led_classdev_suspend);


    I changed the code into led_cdev->brightness_set(led_cdev, 1), then my problem got solved. Is it correct the way..?

    Regards,
    Manoj
  • 0 in reply to Manoj Kumar
    TI__Guru**** 161600 points

    Hi Manoj,

    Yes, I missed that part of the needed kernel modifications... Yes, by inverting the logic, you will have the leds turned off, every time the device goes to suspend.

    Best Regards,
    Yordan