Yes, it's better to list new API exposed to the userspace and finalize API set after discussion. Then we discuss how to expose them to userspace: 1.driver 2.procfs 3.boardctl 4.sysctl
On Fri, Mar 19, 2021 at 9:31 PM Matias N. <mat...@imap.cc> wrote: > 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 > > >
