[PATCH 0/2] iio: imu: inv-mpu9150: fix interrupts for MPU9150

[PATCH 0/2] iio: imu: inv-mpu9150: fix interrupts for MPU9150

[akemnade]

The Epson Moverio BT200 has MPU9150 chips. The devicetree has a simple
typo regarding the interrupt of that chip. Simply fixing it unweils
problems in the driver causing IRQ storms by calling
iio_readdev -T 0 iio:deviceX 

With the fix applied one IRQ comes per sampling when calling
iio_readdev -T 0 iio:deviceX which looks like sane behaviour.
Probably applying this series has to be split between different kernel
releases to avoid having fixed devicetree with broken driver.

Signed-off-by: Andreas Kemnade <akemnade@kernel.org>
---
Andreas Kemnade (2):
      iio: imu: inv-mpu9150: fix irq ack preventing irq storms
      ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property

 arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts | 4 ++--
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c        | 8 ++++++++
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h         | 2 ++
 drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c     | 5 ++++-
 4 files changed, 16 insertions(+), 3 deletions(-)
---
base-commit: f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da
change-id: 20251231-mpu9150-0f261490d17e

Best regards,
--  
Andreas Kemnade <akemnade@kernel.org>

[PATCH 1/2] iio: imu: inv-mpu9150: fix irq ack preventing irq storms

[akemnade]

From: Andreas Kemnade <andreas@kemnade.info>

IRQ needs to be acked. for some odd reasons, reading from irq status does
not reliable help, enable acking from any register to be on the safe side
and read the irq status register. Comments in the code indicate a known
unreliability with that register.
The blamed commit was tested with mpu6050 in lg,p895 and lg,p880 according
to Tested-bys. But with the MPU9150 in the Epson Moverio BT-200 this leads
to irq storms without properly acking the irq.

Fixes: 0a3b517c8089 ("iio: imu: inv_mpu6050: fix interrupt status read for old buggy chips")
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c    | 8 ++++++++
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h     | 2 ++
 drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 5 ++++-
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index b2fa1f4957a5b..5796896d54cd8 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -1943,6 +1943,14 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, const char *name,
 			irq_type);
 		return -EINVAL;
 	}
+
+	/*
+	 * Acking interrupts by status register does not work reliably
+	 * but seem to work when this bit is set.
+	 */
+	if (st->chip_type == INV_MPU9150)
+		st->irq_mask |= INV_MPU6050_INT_RD_CLEAR;
+
 	device_set_wakeup_capable(dev, true);
 
 	st->vdd_supply = devm_regulator_get(dev, "vdd");
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
index 211901f8b8eb6..6239b1a803f77 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
@@ -390,6 +390,8 @@ struct inv_mpu6050_state {
 /* enable level triggering */
 #define INV_MPU6050_LATCH_INT_EN	0x20
 #define INV_MPU6050_BIT_BYPASS_EN	0x2
+/* allow acking interrupts by any register read */
+#define INV_MPU6050_INT_RD_CLEAR	0x10
 
 /* Allowed timestamp period jitter in percent */
 #define INV_MPU6050_TS_PERIOD_JITTER	4
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
index 10a4733420759..22c1ce66f99ee 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
@@ -248,7 +248,6 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
 	switch (st->chip_type) {
 	case INV_MPU6000:
 	case INV_MPU6050:
-	case INV_MPU9150:
 		/*
 		 * WoM is not supported and interrupt status read seems to be broken for
 		 * some chips. Since data ready is the only interrupt, bypass interrupt
@@ -257,6 +256,10 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
 		wom_bits = 0;
 		int_status = INV_MPU6050_BIT_RAW_DATA_RDY_INT;
 		goto data_ready_interrupt;
+	case INV_MPU9150:
+		/* IRQ needs to be acked */
+		wom_bits = 0;
+		break;
 	case INV_MPU6500:
 	case INV_MPU6515:
 	case INV_MPU6880:

-- 
2.47.3

Re: [PATCH 1/2] iio: imu: inv-mpu9150: fix irq ack preventing irq storms

[Jonathan Cameron]

On Wed, 31 Dec 2025 22:14:16 +0100
akemnade@kernel.org wrote:

> From: Andreas Kemnade <andreas@kemnade.info>
> 
> IRQ needs to be acked. for some odd reasons, reading from irq status does
> not reliable help, enable acking from any register to be on the safe side
> and read the irq status register. Comments in the code indicate a known
> unreliability with that register.
> The blamed commit was tested with mpu6050 in lg,p895 and lg,p880 according
> to Tested-bys. But with the MPU9150 in the Epson Moverio BT-200 this leads
> to irq storms without properly acking the irq.
> 
> Fixes: 0a3b517c8089 ("iio: imu: inv_mpu6050: fix interrupt status read for old buggy chips")
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Jean-Baptiste,

If you have time to look at this that would be great.

Whilst here I'll note the defines in this driver could really do with consistency
improvements.  I'd like to see GENMASK() and BIT() used everywhere.
Currently it's mostly the style used in this patch with a few fields in
the newer style.  

Thanks

Jonathan

> ---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c    | 8 ++++++++
>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h     | 2 ++
>  drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 5 ++++-
>  3 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> index b2fa1f4957a5b..5796896d54cd8 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> @@ -1943,6 +1943,14 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, const char *name,
>  			irq_type);
>  		return -EINVAL;
>  	}
> +
> +	/*
> +	 * Acking interrupts by status register does not work reliably
> +	 * but seem to work when this bit is set.
> +	 */
> +	if (st->chip_type == INV_MPU9150)
> +		st->irq_mask |= INV_MPU6050_INT_RD_CLEAR;
> +
>  	device_set_wakeup_capable(dev, true);
>  
>  	st->vdd_supply = devm_regulator_get(dev, "vdd");
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> index 211901f8b8eb6..6239b1a803f77 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> @@ -390,6 +390,8 @@ struct inv_mpu6050_state {
>  /* enable level triggering */
>  #define INV_MPU6050_LATCH_INT_EN	0x20
>  #define INV_MPU6050_BIT_BYPASS_EN	0x2
> +/* allow acking interrupts by any register read */
> +#define INV_MPU6050_INT_RD_CLEAR	0x10
>  
>  /* Allowed timestamp period jitter in percent */
>  #define INV_MPU6050_TS_PERIOD_JITTER	4
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> index 10a4733420759..22c1ce66f99ee 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> @@ -248,7 +248,6 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
>  	switch (st->chip_type) {
>  	case INV_MPU6000:
>  	case INV_MPU6050:
> -	case INV_MPU9150:
>  		/*
>  		 * WoM is not supported and interrupt status read seems to be broken for
>  		 * some chips. Since data ready is the only interrupt, bypass interrupt
> @@ -257,6 +256,10 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
>  		wom_bits = 0;
>  		int_status = INV_MPU6050_BIT_RAW_DATA_RDY_INT;
>  		goto data_ready_interrupt;
> +	case INV_MPU9150:
> +		/* IRQ needs to be acked */
> +		wom_bits = 0;
> +		break;
>  	case INV_MPU6500:
>  	case INV_MPU6515:
>  	case INV_MPU6880:
> 

Re: [PATCH 1/2] iio: imu: inv-mpu9150: fix irq ack preventing irq storms

[Jean-Baptiste Maneyrol]

>
>________________________________________
>From: Jonathan Cameron <jic23@kernel.org>
>Sent: Sunday, January 11, 2026 13:30
>To: akemnade@kernel.org <akemnade@kernel.org>
>Cc: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com>; David Lechner <dlechner@baylibre.com>; Nuno Sá <nuno.sa@analog.com>; Andy Shevchenko <andy@kernel.org>; Aaro Koskinen <aaro.koskinen@iki.fi>; Andreas Kemnade <andreas@kemnade.info>; Kevin Hilman <khilman@baylibre.com>; Roger Quadros <rogerq@kernel.org>; Tony Lindgren <tony@atomide.com>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Jonathan Cameron <Jonathan.Cameron@huawei.com>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-omap@vger.kernel.org <linux-omap@vger.kernel.org>; devicetree@vger.kernel.org <devicetree@vger.kernel.org>
>Subject: Re: [PATCH 1/2] iio: imu: inv-mpu9150: fix irq ack preventing irq storms
> 
>On Wed, 31 Dec 2025 22: 14: 16 +0100 akemnade@ kernel. org wrote: > From: Andreas Kemnade <andreas@ kemnade. info> > > IRQ needs to be acked. for some odd reasons, reading from irq status does > not reliable help, enable acking from
>ZjQcmQRYFpfptBannerStart
>This Message Is From an External Sender
>This message came from outside your organization.
> 
>ZjQcmQRYFpfptBannerEnd
>On Wed, 31 Dec 2025 22:14:16 +0100
>akemnade@kernel.org wrote:
>
>> From: Andreas Kemnade <andreas@kemnade.info>
>> 
>> IRQ needs to be acked. for some odd reasons, reading from irq status does
>> not reliable help, enable acking from any register to be on the safe side
>> and read the irq status register. Comments in the code indicate a known
>> unreliability with that register.
>> The blamed commit was tested with mpu6050 in lg,p895 and lg,p880 according
>> to Tested-bys. But with the MPU9150 in the Epson Moverio BT-200 this leads
>> to irq storms without properly acking the irq.
>> 
>> Fixes: 0a3b517c8089 ("iio: imu: inv_mpu6050: fix interrupt status read for old buggy chips")
>> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
>Jean-Baptiste,
>
>If you have time to look at this that would be great.
>
>Whilst here I'll note the defines in this driver could really do with consistency
>improvements.  I'd like to see GENMASK() and BIT() used everywhere.
>Currently it's mostly the style used in this patch with a few fields in
>the newer style.  
>
>Thanks
>
>Jonathan

Hello Jonathan,

sorry for the late response. This is a very old chip, I'm sorry I won't be
able to check the modification on my side.

By looking at it, it seems correct if it is indeed fixing the issue. I'm
giving my acknowledgement to the patch.

Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>

Thanks,
JB

>
>> ---
>>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c    | 8 ++++++++
>>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h     | 2 ++
>>  drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 5 ++++-
>>  3 files changed, 14 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>> index b2fa1f4957a5b..5796896d54cd8 100644
>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>> @@ -1943,6 +1943,14 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, const char *name,
>>  			irq_type);
>>  		return -EINVAL;
>>  	}
>> +
>> +	/*
>> +	 * Acking interrupts by status register does not work reliably
>> +	 * but seem to work when this bit is set.
>> +	 */
>> +	if (st->chip_type == INV_MPU9150)
>> +		st->irq_mask |= INV_MPU6050_INT_RD_CLEAR;
>> +
>>  	device_set_wakeup_capable(dev, true);
>>  
>>  	st->vdd_supply = devm_regulator_get(dev, "vdd");
>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
>> index 211901f8b8eb6..6239b1a803f77 100644
>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
>> @@ -390,6 +390,8 @@ struct inv_mpu6050_state {
>>  /* enable level triggering */
>>  #define INV_MPU6050_LATCH_INT_EN	0x20
>>  #define INV_MPU6050_BIT_BYPASS_EN	0x2
>> +/* allow acking interrupts by any register read */
>> +#define INV_MPU6050_INT_RD_CLEAR	0x10
>>  
>>  /* Allowed timestamp period jitter in percent */
>>  #define INV_MPU6050_TS_PERIOD_JITTER	4
>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
>> index 10a4733420759..22c1ce66f99ee 100644
>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
>> @@ -248,7 +248,6 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
>>  	switch (st->chip_type) {
>>  	case INV_MPU6000:
>>  	case INV_MPU6050:
>> -	case INV_MPU9150:
>>  		/*
>>  		 * WoM is not supported and interrupt status read seems to be broken for
>>  		 * some chips. Since data ready is the only interrupt, bypass interrupt
>> @@ -257,6 +256,10 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
>>  		wom_bits = 0;
>>  		int_status = INV_MPU6050_BIT_RAW_DATA_RDY_INT;
>>  		goto data_ready_interrupt;
>> +	case INV_MPU9150:
>> +		/* IRQ needs to be acked */
>> +		wom_bits = 0;
>> +		break;
>>  	case INV_MPU6500:
>>  	case INV_MPU6515:
>>  	case INV_MPU6880:
>> 
>
>

Re: [PATCH 1/2] iio: imu: inv-mpu9150: fix irq ack preventing irq storms

[Jonathan Cameron]

On Fri, 30 Jan 2026 16:17:58 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com> wrote:

> >
> >________________________________________
> >From: Jonathan Cameron <jic23@kernel.org>
> >Sent: Sunday, January 11, 2026 13:30
> >To: akemnade@kernel.org <akemnade@kernel.org>
> >Cc: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com>; David Lechner <dlechner@baylibre.com>; Nuno Sá <nuno.sa@analog.com>; Andy Shevchenko <andy@kernel.org>; Aaro Koskinen <aaro.koskinen@iki.fi>; Andreas Kemnade <andreas@kemnade.info>; Kevin Hilman <khilman@baylibre.com>; Roger Quadros <rogerq@kernel.org>; Tony Lindgren <tony@atomide.com>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Jonathan Cameron <Jonathan.Cameron@huawei.com>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-omap@vger.kernel.org <linux-omap@vger.kernel.org>; devicetree@vger.kernel.org <devicetree@vger.kernel.org>
> >Subject: Re: [PATCH 1/2] iio: imu: inv-mpu9150: fix irq ack preventing irq storms
> > 
> >On Wed, 31 Dec 2025 22: 14: 16 +0100 akemnade@ kernel. org wrote: > From: Andreas Kemnade <andreas@ kemnade. info> > > IRQ needs to be acked. for some odd reasons, reading from irq status does > not reliable help, enable acking from
> >ZjQcmQRYFpfptBannerStart
> >This Message Is From an External Sender
> >This message came from outside your organization.
> > 
> >ZjQcmQRYFpfptBannerEnd
> >On Wed, 31 Dec 2025 22:14:16 +0100
> >akemnade@kernel.org wrote:
> >  
> >> From: Andreas Kemnade <andreas@kemnade.info>
> >> 
> >> IRQ needs to be acked. for some odd reasons, reading from irq status does
> >> not reliable help, enable acking from any register to be on the safe side
> >> and read the irq status register. Comments in the code indicate a known
> >> unreliability with that register.
> >> The blamed commit was tested with mpu6050 in lg,p895 and lg,p880 according
> >> to Tested-bys. But with the MPU9150 in the Epson Moverio BT-200 this leads
> >> to irq storms without properly acking the irq.
> >> 
> >> Fixes: 0a3b517c8089 ("iio: imu: inv_mpu6050: fix interrupt status read for old buggy chips")
> >> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>  
> >Jean-Baptiste,
> >
> >If you have time to look at this that would be great.
> >
> >Whilst here I'll note the defines in this driver could really do with consistency
> >improvements.  I'd like to see GENMASK() and BIT() used everywhere.
> >Currently it's mostly the style used in this patch with a few fields in
> >the newer style.  
> >
> >Thanks
> >
> >Jonathan  
> 
> Hello Jonathan,
> 
> sorry for the late response. This is a very old chip, I'm sorry I won't be
> able to check the modification on my side.
> 
> By looking at it, it seems correct if it is indeed fixing the issue. I'm
> giving my acknowledgement to the patch.
> 
> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Good enough for me.
Applied to my local tree for now as we are close to the merge window
and I'll probably rebase before pushing these out.

Thanks,

Jonathan

> 
> Thanks,
> JB
> 
> >  
> >> ---
> >>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c    | 8 ++++++++
> >>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h     | 2 ++
> >>  drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 5 ++++-
> >>  3 files changed, 14 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> >> index b2fa1f4957a5b..5796896d54cd8 100644
> >> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> >> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> >> @@ -1943,6 +1943,14 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, const char *name,
> >>  			irq_type);
> >>  		return -EINVAL;
> >>  	}
> >> +
> >> +	/*
> >> +	 * Acking interrupts by status register does not work reliably
> >> +	 * but seem to work when this bit is set.
> >> +	 */
> >> +	if (st->chip_type == INV_MPU9150)
> >> +		st->irq_mask |= INV_MPU6050_INT_RD_CLEAR;
> >> +
> >>  	device_set_wakeup_capable(dev, true);
> >>  
> >>  	st->vdd_supply = devm_regulator_get(dev, "vdd");
> >> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> >> index 211901f8b8eb6..6239b1a803f77 100644
> >> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> >> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> >> @@ -390,6 +390,8 @@ struct inv_mpu6050_state {
> >>  /* enable level triggering */
> >>  #define INV_MPU6050_LATCH_INT_EN	0x20
> >>  #define INV_MPU6050_BIT_BYPASS_EN	0x2
> >> +/* allow acking interrupts by any register read */
> >> +#define INV_MPU6050_INT_RD_CLEAR	0x10
> >>  
> >>  /* Allowed timestamp period jitter in percent */
> >>  #define INV_MPU6050_TS_PERIOD_JITTER	4
> >> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> >> index 10a4733420759..22c1ce66f99ee 100644
> >> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> >> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> >> @@ -248,7 +248,6 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
> >>  	switch (st->chip_type) {
> >>  	case INV_MPU6000:
> >>  	case INV_MPU6050:
> >> -	case INV_MPU9150:
> >>  		/*
> >>  		 * WoM is not supported and interrupt status read seems to be broken for
> >>  		 * some chips. Since data ready is the only interrupt, bypass interrupt
> >> @@ -257,6 +256,10 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
> >>  		wom_bits = 0;
> >>  		int_status = INV_MPU6050_BIT_RAW_DATA_RDY_INT;
> >>  		goto data_ready_interrupt;
> >> +	case INV_MPU9150:
> >> +		/* IRQ needs to be acked */
> >> +		wom_bits = 0;
> >> +		break;
> >>  	case INV_MPU6500:
> >>  	case INV_MPU6515:
> >>  	case INV_MPU6880:
> >>   
> >
>   

[PATCH 2/2] ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property

[akemnade]

From: Andreas Kemnade <andreas@kemnade.info>

Define interrupts properly. Unfortunately, this hides a bug in the linux
driver, so it needs to be used with the driver fixed only.

Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
 arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
index c90f43cc2fae9..a9f0cfd7c999d 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
+++ b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
@@ -346,7 +346,7 @@ mpu9150h: imu@68 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&mpu9150h_pins>;
 		interrupt-parent = <&gpio2>;
-		interrupt = <19 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
 	};
 };
 
@@ -408,7 +408,7 @@ mpu9150: imu@68 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&mpu9150_pins>;
 		interrupt-parent = <&gpio2>;
-		interrupt = <7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
 		vddio-supply = <&cb_v18>;
 		vdd-supply = <&cb_v33>;
 		invensense,level-shifter;

-- 
2.47.3

Re: [PATCH 2/2] ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property

[Jonathan Cameron]

On Wed, 31 Dec 2025 22:14:17 +0100
akemnade@kernel.org wrote:

> From: Andreas Kemnade <andreas@kemnade.info>
> 
> Define interrupts properly. Unfortunately, this hides a bug in the linux
> driver, so it needs to be used with the driver fixed only.
> 
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Not related to patch 1 so if TI soc folk can pick this up that would be
great.

> ---
>  arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
> index c90f43cc2fae9..a9f0cfd7c999d 100644
> --- a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
> +++ b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
> @@ -346,7 +346,7 @@ mpu9150h: imu@68 {
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&mpu9150h_pins>;
>  		interrupt-parent = <&gpio2>;
> -		interrupt = <19 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
>  	};
>  };
>  
> @@ -408,7 +408,7 @@ mpu9150: imu@68 {
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&mpu9150_pins>;
>  		interrupt-parent = <&gpio2>;
> -		interrupt = <7 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
>  		vddio-supply = <&cb_v18>;
>  		vdd-supply = <&cb_v33>;
>  		invensense,level-shifter;
> 

Re: [PATCH 2/2] ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property

[Andreas Kemnade]

On Sun, 11 Jan 2026 12:32:00 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Wed, 31 Dec 2025 22:14:17 +0100
> akemnade@kernel.org wrote:
> 
> > From: Andreas Kemnade <andreas@kemnade.info>
> > 
> > Define interrupts properly. Unfortunately, this hides a bug in the linux
> > driver, so it needs to be used with the driver fixed only.
> > 
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>  
> 
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Not related to patch 1 so if TI soc folk can pick this up that would be
> great.
> 
well, it needs things fixed via patch 1 to avoid creating havoc...
But from a strictly dogmatic point of view the devicetree describes the
hardware, so it is unrelated.
... but from a more pragmatic point of view, I do not want to have interrupts
enabled for drivers which do not handle them correctly.

Of course this should be picked up by omap folks.

Regards,
Andreas

Re: [PATCH 2/2] ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property

[Kevin Hilman]

Andreas Kemnade <andreas@kemnade.info> writes:

> On Sun, 11 Jan 2026 12:32:00 +0000
> Jonathan Cameron <jic23@kernel.org> wrote:
>
>> On Wed, 31 Dec 2025 22:14:17 +0100
>> akemnade@kernel.org wrote:
>> 
>> > From: Andreas Kemnade <andreas@kemnade.info>
>> > 
>> > Define interrupts properly. Unfortunately, this hides a bug in the linux
>> > driver, so it needs to be used with the driver fixed only.
>> > 
>> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>  
>> 
>> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>> Not related to patch 1 so if TI soc folk can pick this up that would be
>> great.
>> 
> well, it needs things fixed via patch 1 to avoid creating havoc...
> But from a strictly dogmatic point of view the devicetree describes the
> hardware, so it is unrelated.
> ... but from a more pragmatic point of view, I do not want to have interrupts
> enabled for drivers which do not handle them correctly.
>
> Of course this should be picked up by omap folks.

Based on the changelog comments, I will pick up the DT patch when the
driver fix gets applied.

Kevin

Re: [PATCH 2/2] ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property

[Andreas Kemnade]

On Wed, 14 Jan 2026 14:30:02 -0800
Kevin Hilman <khilman@baylibre.com> wrote:

> Andreas Kemnade <andreas@kemnade.info> writes:
> 
> > On Sun, 11 Jan 2026 12:32:00 +0000
> > Jonathan Cameron <jic23@kernel.org> wrote:
> >  
> >> On Wed, 31 Dec 2025 22:14:17 +0100
> >> akemnade@kernel.org wrote:
> >>   
> >> > From: Andreas Kemnade <andreas@kemnade.info>
> >> > 
> >> > Define interrupts properly. Unfortunately, this hides a bug in the linux
> >> > driver, so it needs to be used with the driver fixed only.
> >> > 
> >> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>    
> >> 
> >> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> >> Not related to patch 1 so if TI soc folk can pick this up that would be
> >> great.
> >>   
> > well, it needs things fixed via patch 1 to avoid creating havoc...
> > But from a strictly dogmatic point of view the devicetree describes the
> > hardware, so it is unrelated.
> > ... but from a more pragmatic point of view, I do not want to have interrupts
> > enabled for drivers which do not handle them correctly.
> >
> > Of course this should be picked up by omap folks.  
> 
> Based on the changelog comments, I will pick up the DT patch when the
> driver fix gets applied.
> 
the needed patch is in. So it can be applied.

Regards,
Andreas

Re: [PATCH 2/2] ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property

[Kevin Hilman]

Andreas Kemnade <andreas@kemnade.info> writes:

> On Wed, 14 Jan 2026 14:30:02 -0800
> Kevin Hilman <khilman@baylibre.com> wrote:
>
>> Andreas Kemnade <andreas@kemnade.info> writes:
>> 
>> > On Sun, 11 Jan 2026 12:32:00 +0000
>> > Jonathan Cameron <jic23@kernel.org> wrote:
>> >  
>> >> On Wed, 31 Dec 2025 22:14:17 +0100
>> >> akemnade@kernel.org wrote:
>> >>   
>> >> > From: Andreas Kemnade <andreas@kemnade.info>
>> >> > 
>> >> > Define interrupts properly. Unfortunately, this hides a bug in the linux
>> >> > driver, so it needs to be used with the driver fixed only.
>> >> > 
>> >> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>    
>> >> 
>> >> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>> >> Not related to patch 1 so if TI soc folk can pick this up that would be
>> >> great.
>> >>   
>> > well, it needs things fixed via patch 1 to avoid creating havoc...
>> > But from a strictly dogmatic point of view the devicetree describes the
>> > hardware, so it is unrelated.
>> > ... but from a more pragmatic point of view, I do not want to have interrupts
>> > enabled for drivers which do not handle them correctly.
>> >
>> > Of course this should be picked up by omap folks.  
>> 
>> Based on the changelog comments, I will pick up the DT patch when the
>> driver fix gets applied.
>> 
> the needed patch is in. So it can be applied.

Thanks for the reminder.  Applying.

Kevin

Re: (subset) [PATCH 0/2] iio: imu: inv-mpu9150: fix interrupts for MPU9150

[Kevin Hilman]

On Wed, 31 Dec 2025 22:14:15 +0100, akemnade@kernel.org wrote:
> The Epson Moverio BT200 has MPU9150 chips. The devicetree has a simple
> typo regarding the interrupt of that chip. Simply fixing it unweils
> problems in the driver causing IRQ storms by calling
> iio_readdev -T 0 iio:deviceX
> 
> With the fix applied one IRQ comes per sampling when calling
> iio_readdev -T 0 iio:deviceX which looks like sane behaviour.
> Probably applying this series has to be split between different kernel
> releases to avoid having fixed devicetree with broken driver.
> 
> [...]

Applied, thanks!

[2/2] ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property
      commit: e0abb8a515cdb7613a15ce54910405ce8110e4f5

Best regards,
-- 
Kevin Hilman (TI) <khilman@baylibre.com>