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: hart...@ibr.cs.tu-bs.de _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
