There's somewhat of a (reduced) PM interface to userspace, via boardctl(), which passes on the PM_STAY, PM_RELAX and others to PM subsystem. This could be extended or indeed you could create a specific driver. The downside of this is that it requires runtime registration on board initialization for all boards. procfs interface could be useful but I think it becomes awkward to be handled from code (it is most useful from CLI by using echo and cat).
Anyway, I think the main point is to really think what is the expected interface to offer to userspace so it is really useful for the general case and not tied to a particular scenario. Maybe we need to think this through carefully and maybe even look at the Linux PM subsystem for some inspiration for a relatively standard interface. Anyway, as I mentioned before, the IDLE loop is usually a good place to interact with hardware. When I need to interact with board code from userspace, I simply extend boardctl to provide any required functionality. Have you looked into this options before moving onto introducing a common driver? Best, Matias On Fri, Mar 19, 2021, at 07:08, Cis Van Mierlo wrote: > 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 <mailto:cis.van.mierlo%40nxp.com> > Internet: http://www.nxp.com > > -----Original Message----- > From: Matias N. <mat...@imap.cc <mailto:matias%40imap.cc>> > Sent: Thursday, March 11, 2021 4:55 PM > To: dev@nuttx.apache.org <mailto:dev%40nuttx.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 >
