03-02-2016, 02:48 PM
Just to clear things up for others, there's a big difference between idle and deep sleep mode.
Idle is the state the kernel goes into when there's nothing else to do (all tasks are waiting for something like I/O or sleeping). The kernel executes a "wait for interrupt" instruction on each core, which allows the ARM cores to go into the lowest possible power mode while still running the clock. At this point, or shortly afterwards if the CPU governor allows, the CPU clock speed drops to its minimum, 480MHz on the Pine64. Even though the clock is still running, the CPU cores consume less power than they would if they were executing NOPs in a loop. The Pine64 sitting on my desk here is currently consuming 90mA (.45W) at 480MHz idle, ethernet powered down, HDMI disconnected (but not necessarily powered down). Increasing the CPU clock to 1.152 GHz causes the current consumption at idle to rise to 110Ma. Depending on the kernel and SoC, other parts of the chip may switch into lower power modes when in the idle state, e.g., the DRAM bus and GPU clock speed will typically be reduced as well.
Deep sleep mode is an entirely different state. The clocks to most of the SoC are disabled (in Arm parlance, they are "gated"), DRAM is put into self-refresh mode, and the only things left running are a low speed timer (for timer wakeup events), the interrupt controller (although most of its inputs may also be gated), and the interrupt lines for things that are allowed to wake up the SoC, e.g., network devices, touch controllers, the power button gpio, and the low speed timer. The kernel only enters deep sleep mode on demand, when something makes the request_suspend_state call (at least this is how it's done in android kernels -- not sure if this is also in mainline). I don't have the android distro on a card ATM, so I can't measure the Pine64's current draw in deep sleep mode, but on the Freescale iMX6 DualLite, the current draw in DSM for a 1GB board is around 15mA.
Just for fun, I ran a single instance of nbench, which runs the CPU up close to 100%. Consumption wend up to 180mA. Of course, this probably doesn't fully load the CPU core, as the Cortex-A53 can issue multiple integer and floating point instructions in a single cycle, so you'd need an artificial test that interleaved integer and floating point operations just right to max out a core. But assuming you wouldn't normally max out a single core, you should be fine on a budget of less than 1 watt for busy periods and less than .5 watt for idle.
Running a second nbench pushed the current draw to between 250 and 280mA, but also caused thermal throttling to kick in and reduce the clock speed to 1.1GHz (it did cycle up and down between 1.152 and 1.1GHz during this test, which may also explain why the current usage fluctuated much more than in the case of a single nbench instance).
Idle is the state the kernel goes into when there's nothing else to do (all tasks are waiting for something like I/O or sleeping). The kernel executes a "wait for interrupt" instruction on each core, which allows the ARM cores to go into the lowest possible power mode while still running the clock. At this point, or shortly afterwards if the CPU governor allows, the CPU clock speed drops to its minimum, 480MHz on the Pine64. Even though the clock is still running, the CPU cores consume less power than they would if they were executing NOPs in a loop. The Pine64 sitting on my desk here is currently consuming 90mA (.45W) at 480MHz idle, ethernet powered down, HDMI disconnected (but not necessarily powered down). Increasing the CPU clock to 1.152 GHz causes the current consumption at idle to rise to 110Ma. Depending on the kernel and SoC, other parts of the chip may switch into lower power modes when in the idle state, e.g., the DRAM bus and GPU clock speed will typically be reduced as well.
Deep sleep mode is an entirely different state. The clocks to most of the SoC are disabled (in Arm parlance, they are "gated"), DRAM is put into self-refresh mode, and the only things left running are a low speed timer (for timer wakeup events), the interrupt controller (although most of its inputs may also be gated), and the interrupt lines for things that are allowed to wake up the SoC, e.g., network devices, touch controllers, the power button gpio, and the low speed timer. The kernel only enters deep sleep mode on demand, when something makes the request_suspend_state call (at least this is how it's done in android kernels -- not sure if this is also in mainline). I don't have the android distro on a card ATM, so I can't measure the Pine64's current draw in deep sleep mode, but on the Freescale iMX6 DualLite, the current draw in DSM for a 1GB board is around 15mA.
Just for fun, I ran a single instance of nbench, which runs the CPU up close to 100%. Consumption wend up to 180mA. Of course, this probably doesn't fully load the CPU core, as the Cortex-A53 can issue multiple integer and floating point instructions in a single cycle, so you'd need an artificial test that interleaved integer and floating point operations just right to max out a core. But assuming you wouldn't normally max out a single core, you should be fine on a budget of less than 1 watt for busy periods and less than .5 watt for idle.
Running a second nbench pushed the current draw to between 250 and 280mA, but also caused thermal throttling to kick in and reduce the clock speed to 1.1GHz (it did cycle up and down between 1.152 and 1.1GHz during this test, which may also explain why the current usage fluctuated much more than in the case of a single nbench instance).