mbox series

[0/4] Add WoM feature as an IIO event

Message ID 20240225160027.200092-1-inv.git-commit@tdk.com (mailing list archive)
Headers show
Series Add WoM feature as an IIO event | expand

Message

inv.git-commit@tdk.com Feb. 25, 2024, 4 p.m. UTC
From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>

Add WoM (Wake-on-Motion) feature for all chips supporting it
(all except MPU-6000/6050/9150). WoM compares the magnitude of
the current accel sample with the previous one against a threshold
and returns an interrupt event if the value is higher.

Report WoM as an accel mag_adaptive_rising IIO event, add system
wakeup functionality if WoM is on and put the chip in low-power
mode when the system is suspended. WoM threshold value is in SI
units since the chip is using an absolute value in mg.


Jean-Baptiste Maneyrol (4):
  iio: imu: inv_mpu6050: add WoM (Wake-on-Motion) sensor
  iio: imu: inv_mpu6050: add WoM event inside accel channels
  iio: imu: inv_mpu6050: add new interrupt handler for WoM events
  iio: imu: inv_mpu6050: add WoM suspend wakeup with low-power mode

 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c    | 523 +++++++++++++++---
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h     |  33 +-
 drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c    |  17 +-
 drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c |  70 ++-
 4 files changed, 541 insertions(+), 102 deletions(-)

Comments

Jonathan Cameron March 3, 2024, 4:44 p.m. UTC | #1
On Sun, 25 Feb 2024 16:00:23 +0000
inv.git-commit@tdk.com wrote:

> From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> 
> Add WoM (Wake-on-Motion) feature for all chips supporting it
> (all except MPU-6000/6050/9150). WoM compares the magnitude of
> the current accel sample with the previous one against a threshold
> and returns an interrupt event if the value is higher.
> 
> Report WoM as an accel mag_adaptive_rising IIO event, add system
> wakeup functionality if WoM is on and put the chip in low-power
> mode when the system is suspended. WoM threshold value is in SI
> units since the chip is using an absolute value in mg.


Adaptive thresholds are normally used when a threshold is based on
some offset form a heavily filtered version of the same channel (often
with filter resets and other nastiness)  It's an obscure hack we added
because we couldn't really get these to fit with another scheme.
This seems simpler than that from your description.

As it's just against the previous reading and I assume the chip
is in a self clocking mode during this, it might be more appropriate
to use a Rate of Change Event (ROC).  There are references to
this being a threshold on highpassed sample, so I guess there might
be some filtering to make this messier? 

The control of a roc threshold will be a little more complex as
you'll need to take into account the sampling frequency.
Advantage is you end up with something easily human understandable.

A human doesn't want to have to figure out what the right value
is for the particular frequency they are sampling at.

Jonathan

> 
> 
> Jean-Baptiste Maneyrol (4):
>   iio: imu: inv_mpu6050: add WoM (Wake-on-Motion) sensor
>   iio: imu: inv_mpu6050: add WoM event inside accel channels
>   iio: imu: inv_mpu6050: add new interrupt handler for WoM events
>   iio: imu: inv_mpu6050: add WoM suspend wakeup with low-power mode
> 
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c    | 523 +++++++++++++++---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h     |  33 +-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c    |  17 +-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c |  70 ++-
>  4 files changed, 541 insertions(+), 102 deletions(-)
>
Jean-Baptiste Maneyrol March 4, 2024, 10:50 a.m. UTC | #2
Hi Jonathan,

it makes sense indeed, using a value in m/s2 per second and computing the corresponding threshold based on the sampling frequency. Just that this will be a check against the absolute value of accel, no sign supported. That's why I was thinking about magnitude more than threshold.

It will effectively be more complex to handle because it will depend on the sampling frequency and will require to adapt the threshold value when changing sampling frequency.

I will rework this series to switch to ROC instead.

Thanks,
JB


From: Jonathan Cameron <jic23@kernel.org>
Sent: Sunday, March 3, 2024 17:44
To: INV Git Commit <INV.git-commit@tdk.com>
Cc: lars@metafoo.de <lars@metafoo.de>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>; Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com>
Subject: Re: [PATCH 0/4] Add WoM feature as an IIO event 
 
On Sun, 25 Feb 2024 16: 00: 23 +0000 inv. git-commit@ tdk. com wrote: > From: Jean-Baptiste Maneyrol <jean-baptiste. maneyrol@ tdk. com> > > Add WoM (Wake-on-Motion) feature for all chips supporting it > (all except MPU-6000/6050/9150).  
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender 
This message came from outside your organization. 
 
ZjQcmQRYFpfptBannerEnd
On Sun, 25 Feb 2024 16:00:23 +0000
inv.git-commit@tdk.com wrote:

> From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> 
> Add WoM (Wake-on-Motion) feature for all chips supporting it
> (all except MPU-6000/6050/9150). WoM compares the magnitude of
> the current accel sample with the previous one against a threshold
> and returns an interrupt event if the value is higher.
> 
> Report WoM as an accel mag_adaptive_rising IIO event, add system
> wakeup functionality if WoM is on and put the chip in low-power
> mode when the system is suspended. WoM threshold value is in SI
> units since the chip is using an absolute value in mg.


Adaptive thresholds are normally used when a threshold is based on
some offset form a heavily filtered version of the same channel (often
with filter resets and other nastiness)  It's an obscure hack we added
because we couldn't really get these to fit with another scheme.
This seems simpler than that from your description.

As it's just against the previous reading and I assume the chip
is in a self clocking mode during this, it might be more appropriate
to use a Rate of Change Event (ROC).  There are references to
this being a threshold on highpassed sample, so I guess there might
be some filtering to make this messier? 

The control of a roc threshold will be a little more complex as
you'll need to take into account the sampling frequency.
Advantage is you end up with something easily human understandable.

A human doesn't want to have to figure out what the right value
is for the particular frequency they are sampling at.

Jonathan

> 
> 
> Jean-Baptiste Maneyrol (4):
>   iio: imu: inv_mpu6050: add WoM (Wake-on-Motion) sensor
>   iio: imu: inv_mpu6050: add WoM event inside accel channels
>   iio: imu: inv_mpu6050: add new interrupt handler for WoM events
>   iio: imu: inv_mpu6050: add WoM suspend wakeup with low-power mode
> 
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c    | 523 +++++++++++++++---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h     |  33 +-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c    |  17 +-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c |  70 ++-
>  4 files changed, 541 insertions(+), 102 deletions(-)
>