Calling those functions from applications would be a violation of OS/application isolation, as these are OS level calls. The general idea is that a driver only knows what to do on each sleep level and the IDLE loop uses those functions to drive the change of states of PM system. >From application side you can forbid/allow the PM system go into each state >which let's you control how devices behave.
I think the typical approach for low-power applications is typically to have a very short active period and a long sleep period. So, the application logic can forbid entering sleep, interact with all required devices, allow sleep, and go to sleep itself (so the IDLE loop kicks in). This way there's no need to control device state directly. Note that you can still wakeup due to external events, which can be made to go back to normal state or not, which will turn on required devices until you service the request and go back to sleep. If for some reason your project requires a different architecture I would say that you need to have a custom board-level driver and offer some kind of interface the user to tune this. An easy path is to use boardctl for this interface. Best, Matias
