Re: [riot-devel] pm_reboot

2017-09-13 Thread Robert Hartung
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 only for some CPUs, but always
uses cortexm_sleep from cortexm_common - However I don't see a
dependency of stm32_common to periph_common? Does this mean, all boards
currenctly always use cortexm_common anyway, if they use stm32_common?

This made me create *pm_stm32_common_layered* [3], as this only provides
pm_set, so others can use pm_layered with this one.

Another cool thing is that cpu/saml21 / cpu/samd21 are just able to use
pm_layered and provide their own pm_set().

Q: Why is the pm_set guarded with ifdefs? Shouldn't all CPUs that use
stm32_common be able to use pm_layered with pm_set? The same applies for
all CPUs that are based on cortexm_common IMO.

I've finished my WIP branch and it can be viewed at [0]

[0] https://github.com/roberthartung/RIOT/tree/hartung/power-management
[1]
https://github.com/roberthartung/RIOT/blob/hartung/power-management/drivers/pm_fallback/pm_fallback.c
[2]
https://github.com/roberthartung/RIOT/blob/hartung/power-management/cpu/cortexm_common/pm/pm.c
[3]
https://github.com/roberthartung/RIOT/blob/hartung/power-management/cpu/stm32_common/pm/pm.c

On 13.09.2017 15:09, Kaspar Schleiser wrote:
> 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
>
-- 
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


Re: [riot-devel] pm_reboot

2017-09-13 Thread Kaspar Schleiser
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-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] pm_reboot

2017-09-13 Thread Robert Hartung
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 get rid of all #ifdef stuff
which is really ugly!

Would that be fine? When do you plan to be finished with the submodules?
I would really like to finish the pm architecture and finally use it!

- Robert

On 11.09.2017 09:01, Kaspar Schleiser wrote:
> 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 applies for
>> pm_off (pm_off can be modeled as pm_set_lowest(); irq_disable();
>> while(1) in pm_layered I guess ?).
> 
> pm_layered does define pm_set_lowest() as weak exactly like that.
> 
>> Therefore I will work on removing pm_reboot() from pm_fallback
>> implementation and create additional modules if needed (at some points
>> pm_reboot is defined outside of pm anyway).
> 
> When designing periph/pm, we intentionally moved reboot from a core
> include into periph/pm, as it seemed to fit together with pm_off().
> 
> Do you have a WIP branch somewhere? While working on #7241, I had to
> implement a lot of what we've discussed, in order to make anything
> compile with sumbodulized periph. Maybe you can take a look? the
> requirements have changed a little.
> 
> Kaspar
> 

-- 
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