[riot-devel] Discussion of Power Management

Robert Hartung hartung at ibr.cs.tu-bs.de
Thu Aug 31 16:37:42 CEST 2017

Hi Kaspar,

thanks for the reply. See answers inline

On 31.08.2017 16:15, Kaspar Schleiser wrote:

> All of them who define pm_set() support pm_layered.

Makes sense. **CPUs should always define what they are going to use!**

> cortexm_common just provides a fallback for pm_set_lowest() which at
> least sets the ARM CPU into idle.

Oh, damn! It's not defining a pm_set. You are completely right, this is
how it should be! Got a little confused here.

I wonder why the kinetis_common cpu defines a pm_set, but cortexm_common
does not? Because the function is cortexm_sleep(0), which should be
available to all cortexm_common-based boards/cpus? So why not merge
these two?

> This is how I envision it:
> - if a CPU has a proper pm_set(), it depends on pm_layered

ACK. pm_layered does everything, except for pm_set. pm_layered will then
do all other stuff.

> - if not, possibly e.g., kinetis_common has pm_set(), then that should
> depend on pm_layered

This means that kinetis_common should provide a module
**kinetis_common_pm** that provides pm_set. The CPU should then depend
on this module. Additionally, it should select pm_layered.

> - if not, the cpu (or e.g., kinetis_common) might depend on
> cortexm_periph_pm_fallback (where the current cortexm weak defines
> should go)

Also sounds good.

> - if the cpu (or any common ancestor) has it's own way of power
> management, it implements pm_set_lowest()

Absolutely. Then we just don't use any of the existing pm_* modules.
This is the case that can always be done.

> - if not, it depends on periph_pm_fallback (which should wrap current
> drivers/periph_common/pm.c)

In this case we use the existing pm_* functions from
drivers/periph_common/pm.c, but I would move them to the module I
created (pm_fallback?).

I am working on a pm_fallback module (moved it from drivers/periph/pm.c
to sys/pm_fallback/pm.c) - is that the right location? Or where should
it be located?

> That should cover all cases, right?

I think so. Let's discuss the naming and location of the fallback
modules across CPUs and RIOT in general and I will take care of this.

- Robert

Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hartung at ibr.cs.tu-bs.de

More information about the devel mailing list