1 2 Previous Next 27 Replies Latest reply on Oct 9, 2016 4:36 PM by rpress

    Putting the Edison into and taking it out of Standby?

    inteluser888

      The Edison boasts amazingly low power consumption (13mW!) in standby, but I haven't been able to find any details on standby. I have a battery-powered project that would need processing very sparingly so I would want to have it in standby as much as possible to save battery. I assume standby is more than just idling, correct?

       

      Major questions:

      1. How do you bring it in and out of standby? What wake-up capabilities are available - pin level change, timer, bluetooth connection/message, etc?
      2. What are it's capabilities in and out of standby?
      3. How long does does it take to come out of standby?
      4. Is there a power spike bringing it out of standby?

       

      I saw the CPU Power management on Yocto (edison-image) C-states thread where they discuss C-states and P-states, but am unsure - are these the same things as the referenced "standby"?

        • 1. Re: Putting the Edison into and taking it out of Standby?
          CMata_Intel

          Hi inteluser888 ;

           

          I'm not sure of what you mean with standby function. What exactly do you want to put on standby? (Memory, disk, a script...)

          Do you mean "the low power sleep mode" with SW1UI2 or do you want to go into a sleep mode using commands in Linux(sleep)?

           

          For timers this is an interesting thread that you could check Timer Interrupts in Intel Edison

          For Power Management in WiFi WiFi User Guide

          For functionality of SW1UI2 for IO configurations: Buttons and Switch

          For Bluetooth you can rfkill block Bluetooth.

           

          Please let me know what you want to accomplish with the "standby" mode in order to give you a more accurate help.

           

          Regards;

          CMata

          • 2. Re: Putting the Edison into and taking it out of Standby?
            zJack

            Ideally the system/SOC can be put in S3. And wake up when there's an interrupt, like from GPIO or something like that.

            Is this doable?

             


            • 3. Re: Putting the Edison into and taking it out of Standby?
              CMata_Intel

              Hi zJack

               

              If you are using the Release 2 in the Edison you can use:

              echo -n "mem" > /sys/power/state
              

              or

              echo -n "freeze" > /sys/power/state
              

               

              Regards;

              CMata

              • 4. Re: Putting the Edison into and taking it out of Standby?
                zJack

                Interesting... after rfkill block all, V_SYS was at about 50mA.

                After echo -n "mem" > /sys/power/state, it went down to about 2~3mA.. for several seconds (until something, maybe timer wakes the soc up).

                But I couldn't get this to work again by repeating the same command...until a reboot. Not sure why...

                 

                echo -n "freeze" > /sys/power/state does not seem to help. It went up to 70mA from 50mA and stayed there.

                 

                can you explain what the 2 commands do?

                • 5. Re: Putting the Edison into and taking it out of Standby?
                  CMata_Intel

                  Hi zJack

                   

                  Do you still having issues with "mem"? Is working just once? Are you using the latest image?

                  Take a look in here: https://www.kernel.org/doc/Documentation/power/states.txt

                  As you may know we are working on more documentation about Power Management and it will be released as soon as the editing and reviewing processes finishes

                   

                  Regards;

                  CMata

                  • 6. Re: Putting the Edison into and taking it out of Standby?
                    rpress

                    zJack wrote:

                     

                    Interesting... after rfkill block all, V_SYS was at about 50mA.

                    After echo -n "mem" > /sys/power/state, it went down to about 2~3mA.. for several seconds (until something, maybe timer wakes the soc up).

                    But I couldn't get this to work again by repeating the same command...until a reboot. Not sure why...

                     

                    echo -n "freeze" > /sys/power/state does not seem to help. It went up to 70mA from 50mA and stayed there.

                     

                    can you explain what the 2 commands do?

                     

                    I am seeing the same problem trying to use "mem" for S3 standby, where it only works the first time.  I am using the latest Yocto image ww18-15.  The kernel log below hints at the problem.

                     

                    [26926.886949] smpboot: CPU 1 is now offline

                    [26926.888350] SC device/devices not in d0i3!!

                    [26926.888360] pmu2_states[0] = FFCFC3FC

                    [26926.888367] pmu2_states[1] = FFFFFFFF

                    [26926.888372] pmu2_states[2] = FFFFFF3F

                    [26926.888377] pmu2_states[3] = FFFFFFFF

                    [26926.888390] ------------[ cut here ]------------

                    [26926.888415] WARNING: at /home/rpress/edison-src/build/tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux/arch/x86/platform/intel-mid/intel_soc_pmu.c:2039 mid_suspend_enter+0xb7/0x1a0()

                    [26926.888449] Modules linked in: usb_f_acm u_serial g_multi libcomposite bcm_bt_lpm bcm4334x(O)

                    [26926.888464] CPU: 0 PID: 1077 Comm: sh Tainted: G           O 3.10.17-yocto-standard #14

                    [26926.888470] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48

                    [26926.888508]  00000000 00000000 f5d83e6c c18a0071 f5d83e94 c123e92e c1a9f780 c1a940dc

                    [26926.888541]  000007f7 c1234f87 c1234f87 00000000 00000003 00000000 f5d83ea4 c123e9f2

                    [26926.888572]  00000009 00000000 f5d83ec4 c1234f87 c1576d04 00000003 00000003 00000000

                    [26926.888577] Call Trace:

                    [26926.888603]  [<c18a0071>] dump_stack+0x16/0x18

                    [26926.888622]  [<c123e92e>] warn_slowpath_common+0x5e/0x80

                    [26926.888638]  [<c1234f87>] ? mid_suspend_enter+0xb7/0x1a0

                    [26926.888652]  [<c1234f87>] ? mid_suspend_enter+0xb7/0x1a0

                    [26926.888670]  [<c123e9f2>] warn_slowpath_null+0x22/0x30

                    [26926.888685]  [<c1234f87>] mid_suspend_enter+0xb7/0x1a0

                    [26926.888700]  [<c1576d04>] ? pm_wakeup_pending+0xd4/0x150

                    [26926.888718]  [<c1283bf5>] suspend_devices_and_enter+0x3a5/0x450

                    [26926.888736]  [<c1283e06>] pm_suspend+0x166/0x240

                    [26926.888752]  [<c1282e7b>] state_store+0x5b/0xb0

                    [26926.888766]  [<c1282e20>] ? wakeup_count_show+0x50/0x50

                    [26926.888785]  [<c14bab27>] kobj_attr_store+0x17/0x30

                    [26926.888801]  [<c137242e>] sysfs_write_file+0x9e/0x110

                    [26926.888817]  [<c1372390>] ? sysfs_remove_files+0x30/0x30

                    [26926.888834]  [<c131affd>] vfs_write+0x9d/0x1b0

                    [26926.888853]  [<c131b649>] SyS_write+0x49/0x90

                    [26926.888870]  [<c18a5a48>] syscall_call+0x7/0xb

                    [26926.888884] ---[ end trace 7054a423e83344ef ]---

                     

                     

                    Also the sdhci-pci driver (for the SDIO interface to the WiFi chipset) also blocks sleep if the WiFi connection is still up.  Although I can work around this by stopping wpa_supplicant and restarting after awakening this seems like it shouldn't be needed.

                     

                    [27035.195041] pci_pm_suspend(): sdhci_pci_suspend+0x0/0xc0 returns -16

                    [27035.195060] dpm_run_callback(): pci_pm_suspend+0x0/0x1b0 returns -16

                    [27035.195076] PM: Device 0000:00:01.3 failed to suspend async: error -16

                    [27035.216326] PM: Some devices failed to suspend

                    • 7. Re: Putting the Edison into and taking it out of Standby?
                      robert_armstrong

                      I have a similiar problem w/ the latest image. Sleeping works once but is woken up and then cannot be repeated.

                      • 8. Re: Putting the Edison into and taking it out of Standby?
                        Azoth

                        Just confirming the issue here as well - latest image as of 6/7/15.

                        • 9. Re: Putting the Edison into and taking it out of Standby?
                          JOSE GARZA ROSADO

                          Anyone could work this around? I can only execute the "mem" > /sys/power/state once, the next times it just goes out of it like 1 second after that.

                          • 10. Re: Putting the Edison into and taking it out of Standby?
                            dave_gallatin

                            I am having the same issue - echo "mem" > /sys/power/state works once after a fresh boot, then fails to sleep subsequent times.  I'm also running the latest image  - ww18-15.


                            We are developing a product that embeds an Edison module and require that Sleep mode be functional in order for the product to be viable.

                             

                            I took a look at the kernel log as rpress mentioned and agree that the key messages are (I added printing the mask/target for states[0-3]):

                             

                            [  293.025444] SC device/devices not in d0i3!!

                            [  293.025455] 0 - mask FFF3FFFF target FFF3FFFF

                            [  293.025461] 1 - mask FFFFFFFF target FFFFFFFF

                            [  293.025467] 2 - mask FFFFFFFF target FFFFFF3F

                            [  293.025473] 3 - mask FFFFFFFF target FFFFFFFF

                            [  293.025479] pmu2_states[0] = FFCFC3FC

                            [  293.025485] pmu2_states[1] = FFFFFFFF

                            [  293.025490] pmu2_states[2] = FFFFFF3F

                            [  293.025496] pmu2_states[3] = FFFFFFFF

                            [  293.025506] ------------[ cut here ]------------

                            [  293.025533] WARNING: at /home/daveg/edison-src/build/tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux/arch/x86/platform/intel-mid/intel_soc_pmu.c:2039 mid_suspend_enter+0xb7/0x1a0()

                            The code that does this check is at kernel/arch/x86/platform/intel-mid/intel_soc_mrfld.c/mrfld_nc_sc_status_check(). This code verifies that the various pieces of the north and south bridges have entered the sleep state – presumably because their drivers have run during the suspend sequence and placed the hardware into the correct state (which happens the first time after boot).  Specifically the south bridge check fails – the code is as follows:

                             

                            static bool mrfld_nc_sc_status_check(void)

                            {

                                        int i;

                                        u32 val, nc_pwr_sts;

                                        struct pmu_ss_states cur_pmsss;

                                        bool nc_status, sc_status;

                             

                             

                                        /* assuming nc and sc are good */

                                        nc_status = true;

                                        sc_status = true;

                             

                             

                                        /* Check south complex device status */

                                        pmu_read_sss(&cur_pmsss);

                             

                             

                                        if (!(((cur_pmsss.pmu2_states[0] & S0IX_TARGET_SSS0_MASK) ==

                                                                                        S0IX_TARGET_SSS0) &&

                                                    ((cur_pmsss.pmu2_states[1] & S0IX_TARGET_SSS1_MASK) ==

                                                                                        S0IX_TARGET_SSS1) &&

                                                    ((cur_pmsss.pmu2_states[2] & S0IX_TARGET_SSS2_MASK) ==

                                                                                        S0IX_TARGET_SSS2) &&

                                                    ((cur_pmsss.pmu2_states[3] & S0IX_TARGET_SSS3_MASK) ==

                                                                                        (S0IX_TARGET_SSS3)))) {

                                                    sc_status = false;

                                                    pr_warn("SC device/devices not in d0i3!!\n");

                                                    pr_warn("0 - mask %08lX target %08lX\n", S0IX_TARGET_SSS0_MASK, S0IX_TARGET_SSS0);

                                                    pr_warn("1 - mask %08lX target %08lX\n", S0IX_TARGET_SSS1_MASK, S0IX_TARGET_SSS1);

                                                    pr_warn("2 - mask %08lX target %08lX\n", S0IX_TARGET_SSS2_MASK, S0IX_TARGET_SSS2);

                                                    pr_warn("3 - mask %08lX target %08lX\n", S0IX_TARGET_SSS3_MASK, S0IX_TARGET_SSS3);

                                                    for (i = 0; i < 4; i++)

                                                                pr_warn("pmu2_states[%d] = %08lX\n", i,

                                                                                        cur_pmsss.pmu2_states[i]);

                            }


                            The mask and targets are defined as hex values in kernel/arch/x86/platform/intel-mid/intel_soc_mrfld.h:

                             

                            #define S0IX_TARGET_SSS0_MASK (0xFFF3FFFF)

                            #define S0IX_TARGET_SSS1_MASK (0xFFFFFFFF)

                            #define S0IX_TARGET_SSS2_MASK (0xFFFFFFFF)

                            #define S0IX_TARGET_SSS3_MASK (0xFFFFFFFF)

                             

                            #define S0IX_TARGET_SSS0 (0xFFF3FFFF)

                            #define S0IX_TARGET_SSS1 (0xFFFFFFFF)

                            #define S0IX_TARGET_SSS2 (0xFFFFFF3F)

                            #define S0IX_TARGET_SSS3 (0xFFFFFFFF)

                            For the other Intel SoC targets (Medfield and Clovertrail) the specific bit fields are defined for these registers in their respective header files and would indicate which subsystems are not sleeping.  But for Merrifield (Edison) these are just hex values so I don't see conclusive way of determining which subsystem is not achieving the sleep sleep. 

                             

                            If these registers for Merrifield are similar to Medfield/Clovertrail then it would seem that pmu2_states[0] = FFCFC3FC would indicate that 3 or 4 subsystems are not achieving the proper state for sleep.

                             

                            Can Intel or someone with access to the Merrifield specifications shed some light on what is happening here?

                            • 11. Re: Putting the Edison into and taking it out of Standby?
                              CMata_Intel

                              Hi guys;

                               

                              We are working on sharing information on this in the future. Please be patient.

                              • 12. Re: Putting the Edison into and taking it out of Standby?
                                Mattrich

                                Hi,

                                 

                                I'm working on a project which will use many Edison devices but it relies on being able to periodically enter a low power state and resume a time after. I've got to the same position as dave_gallatin and now stuck on this project. Has anybody got any news that they can share on this issue? I suppose I would like to know if it is a hardware limitation or a software issue that can be resolved?

                                • 13. Re: Putting the Edison into and taking it out of Standby?
                                  Cedric.P

                                  Here are some observations:

                                   

                                  1. before entering the `mem` sleep, my idle consumption is 46mA (ok)

                                  2. during the first `mem` sleep, the consumption drops to 4mA (ok)

                                  3. I wake-up with the power button, and my idle consumption is now 55mA (9mA more than it should be) => apparently the resume procedure is putting some device in a different mode, maybe this is why the second sleep does not work.

                                   

                                  Secondly, I made some tests with /sys/power/pm_test, as recommended on https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

                                  A:

                                  1. echo devices > /sys/power/pm_test

                                  2. echo mem > /sys/power/state (devices are put into sleep for 5s, and resumed)

                                  (the idle power consumption comes back to 46mA, as expected)

                                  3. echo none > /sys/power/pm_test

                                  4. echo mem > /sys/power/state

                                  the consumption drops to 4mA as expected => the sleep issue most likely does not come from a device driver

                                   

                                  B:

                                  Same steps with 'platform' instead of 'devices':

                                  1. echo platform > /sys/power/pm_test

                                  2. echo mem > /sys/power/state (devices are put into sleep for 5s, and resumed)

                                  (the idle power consumption comes back to 55mA => 9mA more than expected)

                                  3. echo none > /sys/power/pm_test

                                  4. echo mem > /sys/power/state

                                  The sleep fails with the classical "SC device/devices not in d0i3!!" message

                                   

                                  I compared `dmesg` between A and B, and the only notifiable difference is:

                                  HSU serial 0000:00:04.0: Refused to change power state, currently in D0

                                   

                                  I wonder if the sleep issue comes from the HSU (High Speed UART).

                                  I will try to deactivate the HSU in the kernel and try again, although debugging with the UART will be tricky.

                                  • 14. Re: Putting the Edison into and taking it out of Standby?
                                    TylerK

                                    Thanks for your work on this, @CMata_Intel.  Do you have any updates for us?  I'm still experiencing the issue.  Thanks for your help!

                                    1 2 Previous Next