Description

I'm the initial author of ztimer's interaction with pm_layered (#13722). Basically, it works like this: For each ztimer_clock_t, a minimum required PM mode can be defined. If so, that PM mode is blocked, once a ztimer_t is added to the ztimer_clock_t and unblocked, once all ztimer_t have expired. This works in my applications for more than a year, but I came to the conclusion that this approach isn't a clean solution.

Long story short: ztimer interacts with pm_layered to ensure that the underlying ztimer_periph_[timer|rtt|rtc|ptp] doesn't stall. In my opinion, this should be done by the timer/rtt/rtc/ptp driver. Instead of blocking and unblocking certain PM modes, ztimer should call timer_start()/timer_stop(), rtt_poweron()/rtt_poweroff(), ... The respective driver should be in charge of blocking and unblocking PM modes.

Would you agree, that this is at least a cleaner solution?

Before any change can happen, we have some homework left to do:

• I looked into some periph_timer implementation. Some already interact with pm_layered (ESP32), some don't (STM32, SAM0). We need to make sure that every periph_timer blocks the right PM mode. The same goes with periph_rtt, periph_rtc and periph_ptp.
• Turing off the underlying peripheral will stall the respective ztimer_clock_t. This means a simple ztimer_now() can't be used for time measurement anymore. For that, we must tell ztimer that the clock must not be turned off. Maybe we'll introduce a ztimer_stopwatch_...? That could be used to measuring time distances or as a wall clock? Dunno ... TBD ;-)
• More implications I don't see, yet ...

I'd love to hear your opinion on this!

Useful links

Original PR: #13722