Hi Matias, Because we have an application that manages the power state machine by itself, therefore we don't need a governor and would like to view and change the power state. For testing we've been calling the OS interface directly from the user space application. This is indeed not ideal, therefore we want to create an API to do this nicely from user space.
Currently we are considering the following two options: 1. Create a driver in nuttx/drivers/power/pm_driver.c that exposes the blockdriver /dev/pm, the user could use this to invoke sys calls that nicely comply with the OS. 2. Add a procfs option to the PM driver that exposes /procfs/power/state which can be modified from the user space as well. Which option would you prefer or do you have other suggestions? Kind regards, Cis van Mierlo Embedded Software Engineer NXP Semiconductors, CTO Systems Innovations High Tech Campus 46, room 0.64, 5656 AE Eindhoven, The Netherlands E-mail: cis.van.mie...@nxp.com Internet: http://www.nxp.com -----Original Message----- From: Matias N. <mat...@imap.cc> Sent: Thursday, March 11, 2021 4:55 PM To: dev@nuttx.apache.org Subject: RE: [EXT] Re: Project specific power management configuration Caution: EXT Email 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
