You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Cis Van Mierlo <ci...@nxp.com> on 2021/03/10 14:39:45 UTC
RE: [EXT] Re: Project specific power management configuration
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.mierlo@nxp.com<ma...@nxp.com>
Internet: http://www.nxp.com<http://www.nxp.com/>
From: Matias N. <ma...@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.mierlo@nxp.com<ma...@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
Re: [EXT] Re: Project specific power management configuration
Posted by Xiang Xiao <xi...@gmail.com>.
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. <ma...@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.mierlo@nxp.com <mailto:cis.van.mierlo%40nxp.com>
> > Internet: http://www.nxp.com
> >
> > -----Original Message-----
> > From: Matias N. <matias@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
> >
>
Re: [EXT] Re: Project specific power management configuration
Posted by "Matias N." <ma...@imap.cc>.
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.mierlo@nxp.com <mailto:cis.van.mierlo%40nxp.com>
> Internet: http://www.nxp.com
>
> -----Original Message-----
> From: Matias N. <matias@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
>
Re: [EXT] Re: Project specific power management configuration
Posted by Gregory Nutt <sp...@gmail.com>.
> 2. Add a procfs option to the PM driver that exposes /procfs/power/state which can be modified from the user space as well.
Currently the procfs is read-only, but there is no reason that I can
think of that we could no extended to support writing.
RE: [EXT] Re: Project specific power management configuration
Posted by Cis Van Mierlo <ci...@nxp.com>.
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.mierlo@nxp.com
Internet: http://www.nxp.com
-----Original Message-----
From: Matias N. <ma...@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
RE: [EXT] Re: Project specific power management configuration
Posted by "Matias N." <ma...@imap.cc>.
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
RE: [EXT] Re: Project specific power management configuration
Posted by Cis Van Mierlo <ci...@nxp.com>.
Hi Matias,
So I didn't implement the activity triggers and reactions plus IDLE loop like on https://nuttx.apache.org/docs/latest/components/power.html.
We just call pm_changestate(MCU_POWER_DOMAIN, PM_SLEEP) from the application, because this application has a sleep state.
The pm_changestate() function will trigger the up_pm_prepare() and the up_pm_notify() callback functions in the peripherals, which will first set the UART1 to the new slow clock and then the MCU to the very low power run mode on this slow clock.
But this is then defined for the whole architecture, which we don't want.
We want do define this behavior like which clock frequencies and which peripherals to enable in the application or something.
Do you have an example of how you did this?
Where is your IDLE loop defined?
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.mierlo@nxp.com<ma...@nxp.com>
Internet: http://www.nxp.com<http://www.nxp.com/>
From: Matias N. <ma...@imap.cc>
Sent: Wednesday, March 10, 2021 3:44 PM
To: dev@nuttx.apache.org
Subject: Re: [EXT] Re: Project specific power management configuration
Caution: EXT Email
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.mierlo@nxp.com<ma...@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%7C0d027db521e64caf3cca08d8e3d31156%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637509842964783976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9TXZF2GAVXYOFdjcg2Eyk6vdRX4vIhA1IquP9w9Gn88%3D&reserved=0>
From: Matias N. <ma...@imap.cc>>
Sent: Friday, March 5, 2021 4:32 PM
To: dev@nuttx.apache.org<ma...@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.mierlo@nxp.com<ma...@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%7C0d027db521e64caf3cca08d8e3d31156%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637509842964783976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9TXZF2GAVXYOFdjcg2Eyk6vdRX4vIhA1IquP9w9Gn88%3D&reserved=0>
Attachments:
* image001.png
* image002.png
* PM_mode_configuration_option.png
* PM_mode_configuration_option2.png
Attachments:
* image001.png
* image002.png
Re: [EXT] Re: Project specific power management configuration
Posted by "Matias N." <ma...@imap.cc>.
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.mierlo@nxp.com
> Internet: http://www.nxp.com
>
> *From:* Matias N. <ma...@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.mierlo@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