From: Jonathan Cameron <jic23@kernel.org>
To: cmo@melexis.com
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH v3 1/3] iio: temperature: mlx90632 Add runtime powermanagement modes
Date: Thu, 15 Sep 2022 15:07:52 +0100 [thread overview]
Message-ID: <20220915150752.643a3e7d@jic23-huawei> (raw)
In-Reply-To: <32c4b72624e4a3480b202f24f506ca91029e47f7.1662454215.git.cmo@melexis.com>
On Tue, 6 Sep 2022 11:04:30 +0200
cmo@melexis.com wrote:
> From: Crt Mori <cmo@melexis.com>
>
> The sensor can operate in lower power modes and even make measurements when
> in those lower powered modes. The decision was taken that if measurement
> is not requested within 2 seconds the sensor will remain in SLEEP_STEP
> power mode, where measurements are triggered on request with setting the
> start of measurement bit (SOB). In this mode the measurements are taking
> a bit longer because we need to start it and complete it. Currently, in
> continuous mode we read ready data and this mode is activated if sensor
> measurement is requested within 2 seconds. The suspend timeout is
> increased to 6 seconds (instead of 3 before), because that enables more
> measurements in lower power mode (SLEEP_STEP), with the lowest refresh
> rate (2 seconds).
>
> Signed-off-by: Crt Mori <cmo@melexis.com>
This is missing necessary disabling of autosuspend (see inline).
Also, I just realised you have the original pm disables in remove after
this patch - so effectively you disable runtime pm twice.
There is a sleep in that remove function which can also be done with
a devm_add_action_or_reset(). Do that as well and you can move
the device register to the devm form and drop the remove() function entirely.
> ---
> drivers/iio/temperature/mlx90632.c | 347 +++++++++++++++++++++++++----
> 1 file changed, 302 insertions(+), 45 deletions(-)
> + return 2;
> +}
> +
Nitpick, but single line is plenty.
> +
> +static int mlx90632_set_meas_type(struct mlx90632_data *data, u8 type)
> +{
>
> static int mlx90632_write_raw(struct iio_dev *indio_dev,
> @@ -875,6 +1096,15 @@ static int mlx90632_enable_regulator(struct mlx90632_data *data)
> return ret;
> }
>
> +static void mlx90632_pm_disable(void *data)
> +{
> + struct device *dev = data;
> +
> + pm_runtime_get_sync(dev);
So, this isn't quite enough.
Take a look at what devm_pm_runtime_enable()
does as the documentation for
pm_runtime_use_autosuspend()
I'd suggest using devm_pm_runtime_enable() and
an additional callback to turn the device on that
is registered after devm_pm_runtime_enable()
(so will maintain the ordering you have here).
> + pm_runtime_put_noidle(dev);
> + pm_runtime_disable(dev);
> +}
> +
> static int mlx90632_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -902,6 +1132,7 @@ static int mlx90632_probe(struct i2c_client *client,
> mlx90632->client = client;
> mlx90632->regmap = regmap;
> mlx90632->mtyp = MLX90632_MTYP_MEDICAL;
> + mlx90632->powerstatus = MLX90632_PWR_STATUS_HALT;
>
> mutex_init(&mlx90632->lock);
> indio_dev->name = id->name;
> @@ -961,16 +1192,25 @@ static int mlx90632_probe(struct i2c_client *client,
>
> mlx90632->emissivity = 1000;
> mlx90632->object_ambient_temperature = 25000; /* 25 degrees milliCelsius */
> + mlx90632->interaction_ts = jiffies; /* Set initial value */
>
> - pm_runtime_disable(&client->dev);
> + pm_runtime_get_noresume(&client->dev);
> ret = pm_runtime_set_active(&client->dev);
> if (ret < 0) {
> mlx90632_sleep(mlx90632);
> return ret;
> }
> +
> pm_runtime_enable(&client->dev);
> pm_runtime_set_autosuspend_delay(&client->dev, MLX90632_SLEEP_DELAY_MS);
> pm_runtime_use_autosuspend(&client->dev);
> + pm_runtime_put_autosuspend(&client->dev);
> +
> + ret = devm_add_action_or_reset(&client->dev, mlx90632_pm_disable, &client->dev);
Having moved those over to devm you need to also have dropped the calls in remove()
(I only noticed this whilst trying to fix the autosuspend issue above.)
> + if (ret) {
> + mlx90632_sleep(mlx90632);
> + return ret;
> + }
>
> return iio_device_register(indio_dev);
> }
next prev parent reply other threads:[~2022-09-15 14:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 9:06 [PATCH v3 0/3] iio: temperature: mlx90632: Add powermanagement cmo
2022-09-06 9:04 ` [PATCH v3 1/3] iio: temperature: mlx90632 Add runtime powermanagement modes cmo
2022-09-06 10:20 ` Andy Shevchenko
2022-09-06 10:51 ` Crt Mori
2022-09-06 12:36 ` Andy Shevchenko
2022-09-06 13:04 ` Crt Mori
2022-09-06 13:16 ` Andy Shevchenko
2022-09-08 12:43 ` Jonathan Cameron
2022-09-15 14:07 ` Jonathan Cameron [this message]
2022-09-15 14:35 ` Crt Mori
2022-09-16 15:22 ` Jonathan Cameron
2022-09-06 9:04 ` [PATCH v3 2/3] iio: temperature: mlx90632 Read sampling frequency cmo
2022-09-06 10:21 ` Andy Shevchenko
2022-09-15 14:09 ` Jonathan Cameron
2022-09-06 9:04 ` [PATCH v3 3/3] iio: temperature: mlx90632 Change return value of sensor measurement channel cmo
2022-09-06 10:23 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220915150752.643a3e7d@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy.shevchenko@gmail.com \
--cc=cmo@melexis.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox