Implement power management `pm` for CPUs

[haukepetersen]

This issue is created for tracking the pm implementation status and synchronize efforts.

Steps needed for implementation:

• implement pm interface
• use pm_layered where applicable
• only allow appropriate power modes in peripheral drivers (e.g. use pm_block/pm_unblock)
• verification of power modes (e.g. using external measurement equipment)

Implementation status:

• atmega1281 (atmega_common?)
• atmega2560 (atmega_common?)
• atmega328p (atmega_common?)
• cc2538
• cc26x0
• cc430 (msp430_common?)
• ezr32wg
• kinetis_common (-> @gebart, kinetis: Implement low power modes #7897)
• lm4f120 (stellaris_common?)
• lpc11u34
• lpc1768
• lpc2387
• mips32r2_common
• msp430fxyz (msp430_common?)
• native (feasible?)
• nrf5x_common
• sam0_common
• sam3
• stm32_common
• x86

[jnohlgard]

The Kinetis CPUs are best implemented as a shared PM driver with possibly some small differences handled in preprocessor conditionals.

[haukepetersen]

jupp, agree. Updated the list

[vincent-d]

How the periph driver are supposed to implement this? I think this is straightforward for spi, block/unblock are called in acquire/release. But how do we proceed for uart for instance. Are the block/unblock supposed to be called from uart_poweron/uart_poweroff? If yes, then we need a timeout mechanism or something from the layer above to power off the uart when nothing is expected anymore. Then who is supposed to manage a wake up pin?

Same kind of questions apply to xtimer, because with the current design, once xtimer is launched most implementation would unlikely never go to any power saving mode.

[haukepetersen]

pratically, it is quite simple - as long as peripherals are active, they need to block any power state that prevents them from working:
UART: block low power when activated (init and poweron), and unblock when disabled (poweroff), no need for timeouts or anything. Effect: as long as e.g. the shell is used, low power modes are blocked. This is not a problem of the uart driver, but the using module (e.g. shell).
But it might be possible for some CPUs to go to sleep and be waken up by the UART, so these can handle the blocking differently...

timer: same thing: block lowpower modes when activated and unblock when powered off (stopped) on most platforms. This indeed blocks all low-power modes as long as the xtimer is used. This is a known issue or better known conceptual gap in our timer system design. @kaspar030 and me are working on a new proposal to solve this.

[vincent-d]

That's what I understood, then.

So in practical, as soon as shell or xtimer is used, we cannot reach any low power mode anymore with the current design.

For the UART, some platform will need to setup the rx pin as an external interrupt before sleeping to be able to wake up from the UART. Do you see this kind of features as part of the UART driver or as an extra layer above ?

I'm glad this topic is moving forward.

[haukepetersen]

For the UART, some platform will need to setup the rx pin as an external interrupt before sleeping to be able to wake up from the UART. Do you see this kind of features as part of the UART driver or as an extra layer above ?

I'd say this would be part of the uart driver, as it is up to the driver how it behaves in context with low power modes. But we need to be careful, as we don't want to run in situations, where we lose the first char send over the UART when we need to wakeup first...

[jnohlgard]

I prefer to see this not as a design flaw of xtimer, but rather a misconfiguration of the boards.
The whole purpose of #5608 was to allow low power modes while using xtimer. Many platforms have low power timers which operate at lower frequencies than 1 MHz. On Kinetis platforms, all we need to do is use the LPT instead of PIT and we get full xtimer functionality in all low power modes. I don't know the STM32 timer hardware, but I guess there must be some module or timer clocking mode which remains active in low power modes for this kind of applications.

UART:
For battery powered applications, you likely won't be using the shell anyway, so reconfigure the UART to TX only mode if you need some printfs for debugging. For low power RX, the UART drivers should probably be updated to configure the pins like @vincent-d and @haukepetersen wrote, or other platform specific wake method (RXEDGIF on Kinetis). Don't go to sleep if the UART module is in the process of receiving or transmitting a byte (handle this via interrupts or check status bits).

SPI/I2C:
Only needs to remain awake while a transmission is in progress.