From: Jonathan Cameron <jic23@kernel.org>
To: Chris Morgan <macroalpha82@gmail.com>
Cc: linux-iio@vger.kernel.org, andy@kernel.org, nuno.sa@analog.com,
dlechner@baylibre.com, jean-baptiste.maneyrol@tdk.com,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
heiko@sntech.de, conor+dt@kernel.org, krzk+dt@kernel.org,
robh@kernel.org, andriy.shevchenko@intel.com,
Chris Morgan <macromorgan@hotmail.com>
Subject: Re: [PATCH V4 08/10] iio: imu: inv_icm42607: Add Wake on Movement for icm42607
Date: Tue, 5 May 2026 11:45:18 +0100 [thread overview]
Message-ID: <20260505114518.4af3c3ac@jic23-huawei> (raw)
In-Reply-To: <20260501221152.194251-9-macroalpha82@gmail.com>
On Fri, 1 May 2026 17:11:47 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for wake on movement for the icm42607 driver.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
One general thing as a result of change in how runtime pm
calls the stuff to track when it was last busy that I probably
missed in earlier patches.
Otherwise minor stuff inline.
Jonathan
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> index d998d8c94eb9..d056c74dcbfe 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> +static int inv_icm42607_accel_disable_wom(struct iio_dev *indio_dev)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct device *pdev = regmap_get_device(st->map);
> + int ret;
> +
> + ret = _inv_icm42607_accel_disable_wom(indio_dev);
> +
> + pm_runtime_mark_last_busy(pdev);
> + pm_runtime_put_autosuspend(pdev);
Check for this throughout. The definition of pm_runtime_put_autosuspend() is
now:
static inline int pm_runtime_put_autosuspend(struct device *dev)
{
pm_runtime_mark_last_busy(dev);
return __pm_runtime_put_autosuspend(dev);
}
So drop all separate calls to mark_last_busy()
> +
> + return ret;
> +}
> static const int inv_icm42607_accel_scale_nano[][2] = {
> [INV_ICM42607_ACCEL_FS_16G] = { 0, 4788403 },
> [INV_ICM42607_ACCEL_FS_8G] = { 0, 2394202 },
> @@ -464,6 +650,9 @@ static int inv_icm42607_accel_write_odr(struct iio_dev *indio_dev,
> return ret;
>
> ret = inv_icm42607_set_accel_conf(st, &conf, NULL);
> + if (ret)
> + return ret;
Blank line here as the two blocks aren't that closely related.
Helps readability (a tiny bit!)
> + ret = inv_icm42607_accel_set_wom_threshold(st, st->apex.wom.value, val, val2);
> if (ret)
> return ret;
>
> +
> static const struct iio_info inv_icm42607_accel_info = {
> .read_raw = inv_icm42607_accel_read_raw,
> .write_raw = inv_icm42607_accel_write_raw,
> @@ -586,6 +885,10 @@ static const struct iio_info inv_icm42607_accel_info = {
> .update_scan_mode = inv_icm42607_accel_update_scan_mode,
> .hwfifo_set_watermark = inv_icm42607_accel_hwfifo_set_watermark,
> .hwfifo_flush_to_buffer = inv_icm42607_accel_hwfifo_flush,
> + .read_event_config = inv_icm42607_accel_read_event_config,
> + .write_event_config = inv_icm42607_accel_write_event_config,
> + .read_event_value = inv_icm42607_accel_read_event_value,
> + .write_event_value = inv_icm42607_accel_write_event_value,
> };
>
> struct iio_dev *inv_icm42607_accel_init(struct inv_icm42607_state *st)
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 5c2010d8256f..480fe1741a04 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +int inv_icm42607_disable_wom(struct inv_icm42607_state *st)
> +{
> + int ret;
> +
> + /* disable WoM interrupt */
> + ret = regmap_clear_bits(st->map, INV_ICM42607_REG_INT_SOURCE1,
> + INV_ICM42607_INT_SOURCE1_WOM_INT1_EN);
> + if (ret)
> + return ret;
> +
> + /* disable WoM hardware */
> + return regmap_clear_bits(st->map, INV_ICM42607_REG_WOM_CONFIG,
> + INV_ICM42607_WOM_CONFIG_EN);
> +}
> +
> +
Single line only between functions.
> int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> +
> +static irqreturn_t inv_icm42607_irq_handler(int irq, void *_data)
> +{
> + struct inv_icm42607_state *st = _data;
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int status;
> + int ret;
> +
> + mutex_lock(&st->lock);
> +
> + if (st->apex.on) {
> + unsigned int status2, status3;
> +
> + /* read INT_STATUS2 and INT_STATUS3 in 1 operation */
> + ret = regmap_bulk_read(st->map, INV_ICM42607_REG_INT_STATUS2, st->buffer, 2);
> + if (ret)
> + goto out_unlock;
> + status2 = st->buffer[0];
> + status3 = st->buffer[1];
> + inv_icm42607_accel_handle_events(st->indio_accel, status2, status3,
> + st->timestamp.accel);
> + }
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_INT_STATUS, &status);
> + if (ret)
> + goto out_unlock;
> +
> + if (status & INV_ICM42607_INT_STATUS_FIFO_FULL)
> + dev_warn(dev, "FIFO full data lost!\n");
> +
> + if (status & INV_ICM42607_INT_STATUS_FIFO_THS) {
> + ret = inv_icm42607_buffer_fifo_read(st, 0);
> + if (ret) {
> + dev_err(dev, "FIFO read error %d\n", ret);
> + goto out_unlock;
> + }
> + ret = inv_icm42607_buffer_fifo_parse(st);
> + if (ret)
> + dev_err(dev, "FIFO parsing error %d\n", ret);
> + }
> +
> +out_unlock:
> + mutex_unlock(&st->lock);
Looks like suitable place for guard() and early returns.
> + return IRQ_HANDLED;
> +}
> +
> +/**
> + * inv_icm42607_irq_init() - initialize int pin and interrupt handler
> + * @st: driver internal state
> + * @irq: irq number
> + * @irq_type: irq trigger type
> + * @open_drain: true if irq is open drain, false for push-pull
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + */
> +static int inv_icm42607_irq_init(struct inv_icm42607_state *st, int irq,
> + int irq_type, bool open_drain)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int val = 0;
> + int ret;
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_RISING:
> + case IRQF_TRIGGER_HIGH:
> + val = INV_ICM42607_INT_CONFIG_INT1_ACTIVE_HIGH;
> + break;
> + default:
> + val = INV_ICM42607_INT_CONFIG_INT1_ACTIVE_LOW;
> + break;
> + }
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_LOW:
> + case IRQF_TRIGGER_HIGH:
> + val |= INV_ICM42607_INT_CONFIG_INT1_LATCHED;
> + break;
> + default:
> + break;
> + }
> +
> + if (!open_drain)
> + val |= INV_ICM42607_INT_CONFIG_INT1_PUSH_PULL;
> +
> + ret = regmap_write(st->map, INV_ICM42607_REG_INT_CONFIG, val);
> + if (ret)
> + return ret;
> +
> + irq_type |= IRQF_ONESHOT;
> + return devm_request_threaded_irq(dev, irq, inv_icm42607_irq_timestamp,
> + inv_icm42607_irq_handler, irq_type,
> + st->name, st);
> +}
> +
> static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
> {
> int ret;
> @@ -387,7 +523,7 @@ int inv_icm42607_core_probe(struct regmap *regmap, int chip,
> struct device *dev = regmap_get_device(regmap);
> struct fwnode_handle *fwnode = dev_fwnode(dev);
> struct inv_icm42607_state *st;
> - int irq;
> + int irq, irq_type;
> bool open_drain;
> int ret;
>
> @@ -402,6 +538,9 @@ int inv_icm42607_core_probe(struct regmap *regmap, int chip,
> if (irq < 0)
> return dev_err_probe(dev, irq, "error missing INT1 interrupt\n");
>
> + irq_type = irq_get_trigger_type(irq);
> + if (!irq_type)
> + irq_type = IRQF_TRIGGER_FALLING;
This is cut and pasted from elsewhere. The only reason we ever do this
is to paper over a driver that set the irq type unconditionally and we should
never have done that. The problem in those historical cases is we don't know
if boards are relying on that behaviour. Hence this hack.
For new code just let the firmware set it up without the driver doing
anything to modify it. Fine to read it here and fail to use the interrupt
if nothing is set.
> open_drain = device_property_read_bool(dev, "drive-open-drain");
next prev parent reply other threads:[~2026-05-05 10:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 22:11 [PATCH V4 00/10] Add Invensense ICM42607 Chris Morgan
2026-05-01 22:11 ` [PATCH V4 01/10] dt-bindings: iio: imu: icm42600: Add icm42607 binding Chris Morgan
2026-05-03 12:18 ` Krzysztof Kozlowski
2026-05-03 20:51 ` Chris Morgan
2026-05-04 16:51 ` Jonathan Cameron
2026-05-04 17:17 ` Chris Morgan
2026-05-01 22:11 ` [PATCH V4 02/10] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver Chris Morgan
2026-05-04 18:10 ` Jonathan Cameron
2026-05-01 22:11 ` [PATCH V4 03/10] iio: imu: inv_icm42607: Add I2C and SPI For icm42607 Chris Morgan
2026-05-04 18:15 ` Jonathan Cameron
2026-05-01 22:11 ` [PATCH V4 04/10] iio: imu: inv_icm42607: Add PM support for icm42607 Chris Morgan
2026-05-04 18:26 ` Jonathan Cameron
2026-05-01 22:11 ` [PATCH V4 05/10] iio: imu: inv_icm42607: Add Buffer " Chris Morgan
2026-05-05 10:14 ` Jonathan Cameron
2026-05-01 22:11 ` [PATCH V4 06/10] iio: imu: inv_icm42607: Add Temp Support in icm42607 Chris Morgan
2026-05-05 10:17 ` Jonathan Cameron
2026-05-01 22:11 ` [PATCH V4 07/10] iio: imu: inv_icm42607: Add Accelerometer for icm42607 Chris Morgan
2026-05-05 10:36 ` Jonathan Cameron
2026-05-01 22:11 ` [PATCH V4 08/10] iio: imu: inv_icm42607: Add Wake on Movement " Chris Morgan
2026-05-05 10:45 ` Jonathan Cameron [this message]
2026-05-01 22:11 ` [PATCH V4 09/10] iio: imu: inv_icm42607: Add Gyroscope to icm42607 Chris Morgan
2026-05-05 10:46 ` Jonathan Cameron
2026-05-01 22:11 ` [PATCH V4 10/10] arm64: dts: rockchip: Add icm42607p IMU for RG-DS Chris Morgan
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=20260505114518.4af3c3ac@jic23-huawei \
--to=jic23@kernel.org \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=heiko@sntech.de \
--cc=jean-baptiste.maneyrol@tdk.com \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=macroalpha82@gmail.com \
--cc=macromorgan@hotmail.com \
--cc=nuno.sa@analog.com \
--cc=robh@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