The interaction between hardware on/off and sleep states usually occurs on IDLE loop. I'm not sure if you are aware of this option but you can have a board specific idle loop implementation. This is what I usually do to implement project specific handling of sleep states.
Best, Matias On Wed, Mar 10, 2021, at 11:39, Cis Van Mierlo wrote: > Hi Matias, > > I indeed saw that there are several governors. > > I implemented PM switches in the application code (you could see this as a > governor), there is for example a sleep state of the application, there the > PM_SLEEP state is used to set the MCU in a very low power state. > Another one is the PM_STANDBY, where the MCU will be put in very low power > run mode, with only one SPI bus and the console UART enabled. All on a slower > clock source. To reduce as much power as possible. > > But the problem that I have is that these peripherals and MCU modes are chip > specific and you want to do the configuration of which MCU mode, which > peripherals, etc. to enable in a power mode per board/project. Because then > you know which peripherals you can turn off in a certain mode to reduce as > much power, but still have the application states functional. > > This is what I wanted to bring to a discussion on how to solve this. > > 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 > > *From:* Matias N. <mat...@imap.cc> > *Sent:* Friday, March 5, 2021 4:32 PM > *To:* dev@nuttx.apache.org > *Subject:* [EXT] Re: Project specific power management configuration > > *Caution: *EXT Email > Hi, > > I'm not entirely sure what is the specific control over PM you need but some > time ago I introduced the notion of "governor" which lets you select either > the activity based one (which uses a specific algorithm to control states), a > greedy governor (which lets an application directly control states via > relax/stay calls). This can easily be extended to have another governor or > even an application defined one (in that case, there need to be some extra > logic to receive the lower-half of the governor from board logic). > > Best, > Matias > > On Fri, Mar 5, 2021, at 07:15, Cis Van Mierlo wrote: >> Hi all, >> >> Me and my colleagues (NXP mobile robotics) encountered a problem and we >> would like to start a discussion on how to solve that. We're making a >> development board using NuttX and we would like to add the power mode >> configuration to it. But this needs to be specific for this "project". >> >> The problem: >> The pm.h specific logic is in the chip dependent code (for example the >> up_pm_prepare() and up_pm_notify() callback functions are located in >> nuttx/arch/arm/src/s32k1xx/s32k1xx_clockconfig.c for the power mode switch >> of the MCU). And for peripherals in the chip specific files as well, for >> example to enable/disable peripherals, like in >> nuttx/arch/arm/src/s32k1xx/s32k1xx_serial.c to enable the serial on the >> other clock which is active in the MCU low power run mode. >> >> But you should not decide on chip level what your current board is doing, >> each board/project would want to have its own power optimizations and >> ability to enable/disable peripherals depending on the use case. >> >> So in that case you would want to give the user/developer the option to >> refine which power reductions he will use for his product/project. >> >> We have several ideas which we would like to use to start a discussion on >> this. >> >> Idea 1: >> Add the configuration with the kconfig files to for example "System Type" in >> menuconfig. Make a PM configure part in which you can enable/disable the >> various PM states (PM_IDLE, PM_STANDBY, PM_SLEEP) and going in this PM state >> will allow you to configure in what state the MCU should be and which >> peripherals should be enabled. >> >> Machine generated alternative text: menuconfig Build Setup System Type >> Allows user to specify which peripherals are enabled In e specflc power mode >> and in which mode the MCI-I Is PM configuration IDLE SLEEP Copy >> configuratjon from menuconfig (pherjpherals)? chip specific MCIJ mode RUN >> chip specific MCIJ mode UART CARTO LIARTI only show PM suppoäed peripherals >> HSRUN RUN VLPR STOP >> Idea 2: >> Another idea is that you add the PM configuration of the peripherals, to the >> peripheral configuration. >> >> Machine generated alternative text: menuconfig Build Setup System Type >> Peripheral Selection UART CARTO LIARTI BAUD rate OMA support Power >> Management NORMAL PM IDLE PM STANDBY PM SLEEP >> Of course we are open to other ideas. We just wanted to get a discussion >> started on how to do this the best way. >> >> 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 >> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nxp.com%2F&data=04%7C01%7Ccis.van.mierlo%40nxp.com%7Cffe5a6177a3c45a66afd08d8dfebe00b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637505551459130586%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CCwUYCNICORguVhH3hbnbbzI2rpWyUxTZUvSBVi5%2Fu8%3D&reserved=0> >> >> >> *Attachments:* >> * image001.png >> * image002.png >> * PM_mode_configuration_option.png >> * PM_mode_configuration_option2.png > > > *Attachments:* > * image001.png > * image002.png
