| Message ID | cover.1663834141.git.cmo@melexis.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iio: temperature: mlx90632: Add powermanagement | expand |
On Thu, 22 Sep 2022 10:13:21 +0200 cmo@melexis.com wrote: > From: Crt Mori <cmo@melexis.com> > > As discussed previously on the group under the > "Controlling device power management from terminal" thread the mlx90632 > sensor provides measurement capabilities under sleep_step mode. This > series runtime suspends the unused chip to sleep step mode to save power > but in case of continuous sequential reading it switches to continuous > mode for faster readouts. This value is hardcoded to > MLX90632_MEAS_MAX_TIME (with some buffer) and not user configurable. > > The sensor runtime suspension is set to MLX90632_SLEEP_DELAY_MS which is > hardcoded to 3 times as much as MEAS_MAX_TIME. > Hi Crt, Applied. However, we are cutting it very tight for the coming merge window so I'm not sure I'll get a 3rd pull request out (this just missed the 2nd one as I only queued up material that was in a final state last weekend) So for now pushed out as testing and we'll see if Linus hints at an rc8 when he releases rc7 tomorrow. If not this will be 6.2 material now. Thanks, Jonathan > Changes in v6: > > - Revert changes to the suspend to prevent power mode regression > > Changes in v5 (per review comments from Jonathan Cameron): > > - Migrate to devm also for driver removal, along with putting it to low > power mode > > Changes in v4 (per review comments from Jonathan Cameron): > > - Migrate back to devm_pm_runtime_enable and remove the pm_disable function > - Remove pm stuff from remove and also sleep, since when iio device is > not registered also sleep makes no sense. > - Replace use EOPNOTSUPP as per checkpatch suggestion although some drivers > still use ENOTSUPP. > - Change the style of read frequency > > Changes in v3 (per review comments from Jonathan Cameron): > > - Change the "available" attribute presentation to more recent way > suggested > - Replace devm_pm_runtime_enable with enable and devm_add_action_or_reset > - When suspending device also put it to lower power mode in case there is > dummy regulator > - Use more switch cases instead of if/else > > Changes in v2: > > - apply review comments from Andy Shevchenko > > Crt Mori (3): > iio: temperature: mlx90632 Add runtime powermanagement modes > iio: temperature: mlx90632 Read sampling frequency > iio: temperature: mlx90632 Change return value of sensor measurement > channel > > drivers/iio/temperature/mlx90632.c | 440 ++++++++++++++++++++++++----- > 1 file changed, 369 insertions(+), 71 deletions(-) >
On Sat, 24 Sept 2022 at 18:32, Jonathan Cameron <jic23@kernel.org> wrote: > > > The sensor runtime suspension is set to MLX90632_SLEEP_DELAY_MS which is > > hardcoded to 3 times as much as MEAS_MAX_TIME. > > > Hi Crt, > > Applied. However, we are cutting it very tight for the coming merge window > so I'm not sure I'll get a 3rd pull request out (this just missed the 2nd > one as I only queued up material that was in a final state last weekend) > So for now pushed out as testing and we'll see if Linus hints at an rc8 > when he releases rc7 tomorrow. If not this will be 6.2 material now. > I sure hope you mean 6.1 material... It would be great to get into 6.0 as i think that is a most likely candidate also for Android kernel baseline (which is what I am also targeting). > Thanks, > > Jonathan > >
On Mon, 26 Sep 2022 15:20:16 +0200 Crt Mori <cmo@melexis.com> wrote: > On Sat, 24 Sept 2022 at 18:32, Jonathan Cameron <jic23@kernel.org> wrote: > > > > > The sensor runtime suspension is set to MLX90632_SLEEP_DELAY_MS which is > > > hardcoded to 3 times as much as MEAS_MAX_TIME. > > > > > Hi Crt, > > > > Applied. However, we are cutting it very tight for the coming merge window > > so I'm not sure I'll get a 3rd pull request out (this just missed the 2nd > > one as I only queued up material that was in a final state last weekend) > > So for now pushed out as testing and we'll see if Linus hints at an rc8 > > when he releases rc7 tomorrow. If not this will be 6.2 material now. > > > I sure hope you mean 6.1 material... It would be great to get into 6.0 > as i think that is a most likely candidate also for Android kernel > baseline (which is what I am also targeting). Sorry, I do mean 6.2. The merge window for 6.0 was months ago and we have to line 6.1 material up a week or so before the 6.1 merge window (which probably starts today). That allows us to get build bots and similar results before the merge window and with time to fix any issues. So unfortunately this will only be in a released kernel in about 6 months time: 3 months for the 6.1 cycle that this just missed and then it'll go into Linus' mainline tree, but the release will still be 3 months after that. In the meantime it'll be in linux-next from just after 6.1-rc1, and in Linus' tree for 6.2-rc1. Kernel cycles are short for a bit project, but they still have about 3 to 6 month delay for new code reaching a release. This just happened to hit the maximum. Jonathan > > > Thanks, > > > > Jonathan > > > >
>> I sure hope you mean 6.1 material... It would be great to get into 6.0 >> as i think that is a most likely candidate also for Android kernel >> baseline (which is what I am also targeting). > > Sorry, I do mean 6.2. > > The merge window for 6.0 was months ago and we have to line 6.1 material > up a week or so before the 6.1 merge window (which probably starts today). > That allows us to get build bots and similar results before the merge window > and with time to fix any issues. > > So unfortunately this will only be in a released kernel in about 6 months time: > 3 months for the 6.1 cycle that this just missed and then it'll go into Linus' > mainline tree, but the release will still be 3 months after that. > > In the meantime it'll be in linux-next from just after 6.1-rc1, and in > Linus' tree for 6.2-rc1. > > Kernel cycles are short for a bit project, but they still have about > 3 to 6 month delay for new code reaching a release. This just happened > to hit the maximum. > > Jonathan OK, then fingers crossed we get rc8, as then I imagine you could put this series into the 6.1 right? Would be really grateful if it would not take 6 months to get this into mainline. Crt On Sun, 2 Oct 2022 at 13:25, Jonathan Cameron <jic23@kernel.org> wrote: > > On Mon, 26 Sep 2022 15:20:16 +0200 > Crt Mori <cmo@melexis.com> wrote: > > > On Sat, 24 Sept 2022 at 18:32, Jonathan Cameron <jic23@kernel.org> wrote: > > > > > > > The sensor runtime suspension is set to MLX90632_SLEEP_DELAY_MS which is > > > > hardcoded to 3 times as much as MEAS_MAX_TIME. > > > > > > > Hi Crt, > > > > > > Applied. However, we are cutting it very tight for the coming merge window > > > so I'm not sure I'll get a 3rd pull request out (this just missed the 2nd > > > one as I only queued up material that was in a final state last weekend) > > > So for now pushed out as testing and we'll see if Linus hints at an rc8 > > > when he releases rc7 tomorrow. If not this will be 6.2 material now. > > > > > I sure hope you mean 6.1 material... It would be great to get into 6.0 > > as i think that is a most likely candidate also for Android kernel > > baseline (which is what I am also targeting). > > Sorry, I do mean 6.2. > > The merge window for 6.0 was months ago and we have to line 6.1 material > up a week or so before the 6.1 merge window (which probably starts today). > That allows us to get build bots and similar results before the merge window > and with time to fix any issues. > > So unfortunately this will only be in a released kernel in about 6 months time: > 3 months for the 6.1 cycle that this just missed and then it'll go into Linus' > mainline tree, but the release will still be 3 months after that. > > In the meantime it'll be in linux-next from just after 6.1-rc1, and in > Linus' tree for 6.2-rc1. > > Kernel cycles are short for a bit project, but they still have about > 3 to 6 month delay for new code reaching a release. This just happened > to hit the maximum. > > Jonathan > > > > > > > Thanks, > > > > > > Jonathan > > > > > > >
On Sun, 2 Oct 2022 16:36:39 +0200 Crt Mori <cmo@melexis.com> wrote: > >> I sure hope you mean 6.1 material... It would be great to get into 6.0 > >> as i think that is a most likely candidate also for Android kernel > >> baseline (which is what I am also targeting). > > > > Sorry, I do mean 6.2. > > > > The merge window for 6.0 was months ago and we have to line 6.1 material > > up a week or so before the 6.1 merge window (which probably starts today). > > That allows us to get build bots and similar results before the merge window > > and with time to fix any issues. > > > > So unfortunately this will only be in a released kernel in about 6 months time: > > 3 months for the 6.1 cycle that this just missed and then it'll go into Linus' > > mainline tree, but the release will still be 3 months after that. > > > > In the meantime it'll be in linux-next from just after 6.1-rc1, and in > > Linus' tree for 6.2-rc1. > > > > Kernel cycles are short for a bit project, but they still have about > > 3 to 6 month delay for new code reaching a release. This just happened > > to hit the maximum. > > > > Jonathan > > OK, then fingers crossed we get rc8, as then I imagine you could put > this series into the 6.1 right? Would be really grateful if it would > not take 6 months to get this into mainline. Pretty unlikely as last Sunday Linus indicated that he was expecting to release new kernel today :( Note it'll be in mainline in 3 months, just not in a release because those take just under 3 months. Jonathan > > Crt > > On Sun, 2 Oct 2022 at 13:25, Jonathan Cameron <jic23@kernel.org> wrote: > > > > On Mon, 26 Sep 2022 15:20:16 +0200 > > Crt Mori <cmo@melexis.com> wrote: > > > > > On Sat, 24 Sept 2022 at 18:32, Jonathan Cameron <jic23@kernel.org> wrote: > > > > > > > > > The sensor runtime suspension is set to MLX90632_SLEEP_DELAY_MS which is > > > > > hardcoded to 3 times as much as MEAS_MAX_TIME. > > > > > > > > > Hi Crt, > > > > > > > > Applied. However, we are cutting it very tight for the coming merge window > > > > so I'm not sure I'll get a 3rd pull request out (this just missed the 2nd > > > > one as I only queued up material that was in a final state last weekend) > > > > So for now pushed out as testing and we'll see if Linus hints at an rc8 > > > > when he releases rc7 tomorrow. If not this will be 6.2 material now. > > > > > > > I sure hope you mean 6.1 material... It would be great to get into 6.0 > > > as i think that is a most likely candidate also for Android kernel > > > baseline (which is what I am also targeting). > > > > Sorry, I do mean 6.2. > > > > The merge window for 6.0 was months ago and we have to line 6.1 material > > up a week or so before the 6.1 merge window (which probably starts today). > > That allows us to get build bots and similar results before the merge window > > and with time to fix any issues. > > > > So unfortunately this will only be in a released kernel in about 6 months time: > > 3 months for the 6.1 cycle that this just missed and then it'll go into Linus' > > mainline tree, but the release will still be 3 months after that. > > > > In the meantime it'll be in linux-next from just after 6.1-rc1, and in > > Linus' tree for 6.2-rc1. > > > > Kernel cycles are short for a bit project, but they still have about > > 3 to 6 month delay for new code reaching a release. This just happened > > to hit the maximum. > > > > Jonathan > > > > > > > > > > > Thanks, > > > > > > > > Jonathan > > > > > > > > > >
From: Crt Mori <cmo@melexis.com> As discussed previously on the group under the "Controlling device power management from terminal" thread the mlx90632 sensor provides measurement capabilities under sleep_step mode. This series runtime suspends the unused chip to sleep step mode to save power but in case of continuous sequential reading it switches to continuous mode for faster readouts. This value is hardcoded to MLX90632_MEAS_MAX_TIME (with some buffer) and not user configurable. The sensor runtime suspension is set to MLX90632_SLEEP_DELAY_MS which is hardcoded to 3 times as much as MEAS_MAX_TIME. Changes in v6: - Revert changes to the suspend to prevent power mode regression Changes in v5 (per review comments from Jonathan Cameron): - Migrate to devm also for driver removal, along with putting it to low power mode Changes in v4 (per review comments from Jonathan Cameron): - Migrate back to devm_pm_runtime_enable and remove the pm_disable function - Remove pm stuff from remove and also sleep, since when iio device is not registered also sleep makes no sense. - Replace use EOPNOTSUPP as per checkpatch suggestion although some drivers still use ENOTSUPP. - Change the style of read frequency Changes in v3 (per review comments from Jonathan Cameron): - Change the "available" attribute presentation to more recent way suggested - Replace devm_pm_runtime_enable with enable and devm_add_action_or_reset - When suspending device also put it to lower power mode in case there is dummy regulator - Use more switch cases instead of if/else Changes in v2: - apply review comments from Andy Shevchenko Crt Mori (3): iio: temperature: mlx90632 Add runtime powermanagement modes iio: temperature: mlx90632 Read sampling frequency iio: temperature: mlx90632 Change return value of sensor measurement channel drivers/iio/temperature/mlx90632.c | 440 ++++++++++++++++++++++++----- 1 file changed, 369 insertions(+), 71 deletions(-)