Hi Kaspar,
pm.h consists of pm_set_lowest, pm_off and pm_reboot.
pm_fallback therefore should define stubs for all of these [1]
cpu/cortexm_common defines some better implementation and also provides
cortexm_sleep, that's why I created pm_cortexm_common [2].
cpu/stm32_common provides pm_set, but
Hi,
On 09/13/2017 03:06 PM, Robert Hartung wrote:
> Make all pm_* implementations submodules, so the final CPU *always* has
> to select the according pm implementation.
You mean all functions, like pm_reboot()?
Kaspar
___
devel mailing list
devel@riot-
Hi Kaspar,
I just looked in more detail on what you've done.
Using submodules is fine for me, but I would like to change a key aspect
here:
Make all pm_* implementations submodules, so the final CPU *always* has
to select the according pm implementation.
For cortexm_common this would allow us to
Hi,
examples/default was the only one really using pm_* functions,
hello-world almost always compiled for me. That's why I always use
different examples.
The top most cpu should simply choose the pm_* module it is willing to
use (being it pm_layered, pm_fallback, pm_stm32_common_fallback or other
Hi,
On 09/12/2017 02:50 PM, Robert Hartung wrote:
> Your PR does not compile for me, almost 50% of the boards in
> examples/default/ are not compiling anymore.
> At least the first few I checked are missing pm_reboot (undefined
> reference).
examples/default mostly doesn't compile because of miss
Hi Kaspar,
On 11.09.2017 09:01, Kaspar Schleiser wrote:
> Only mips-malta has it's own "pm_reboot()" implementation. The other two
> define stubs.
Might be, still, it has to be considered where to place it and how we
define fallbacks cleanly!
>> Additionally pm_layered does not define pm_reboot
Hi,
On 09/08/2017 11:28 AM, Robert Hartung wrote:
> Looks like it's not that easy. Many platforms define pm_reboot in the
> board's file(s).
Only mips-malta has it's own "pm_reboot()" implementation. The other two
define stubs.
> Additionally pm_layered does not define pm_reboot, the same applie
Looks like it's not that easy. Many platforms define pm_reboot in the
board's file(s).
Additionally pm_layered does not define pm_reboot, the same applies for
pm_off (pm_off can be modeled as pm_set_lowest(); irq_disable();
while(1) in pm_layered I guess ?).
Therefore I will work on removing pm_re
After a short discussion offline we decided to keep it as it is. As the
nucleo board for example, supports saving reigsters across the reset.
Therefor when entering low power modes or making a reboot, it might be
required to perform some more stuff.
The pm_* functions will now all be combined in a
Hi *,
I am working on the pm (power management) module of RIOT. Can anyone
tell me why pm_reboot is (often) part of this module?
If no one votes against it, I woud like to move *pm_reboot()* to a
dedicated module, in order to have a reboot_fallback module as we have
planned for pm_fallback and ad
10 matches
Mail list logo
