Re: [PATCH 0/4] Add WoM feature as an IIO event - Jean-Baptiste Maneyrol

From: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "lars@metafoo.de" <lars@metafoo.de>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 0/4] Add WoM feature as an IIO event
Date: Mon, 4 Mar 2024 10:50:25 +0000	[thread overview]
Message-ID: <FR3P281MB17579D0F295C8C99E7C7A5A0CE232@FR3P281MB1757.DEUP281.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20240303164410.6b7cb206@jic23-huawei>

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(-)
> 