Re: [PATCH] iio: imu: inv_icm42600: add support of accel low-power mode

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 22 May 2024 15:35:45 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com> wrote:

> Hello Jonathan,
> 
> the hardware bias changes (inside calibbias exactly) is due to the
> noise differences of the 2 modes, introducing a little change in
> offset (these comes from the MEMS mechanical parts). This change
> cannot be anticipated sadly.
> 
> Most of the time, the low power mode is used for accelerometer, since
> most used accelerometer features are motion monitoring in the
> background (pedometer, activity, ...). But high frequencies can be
> needed for very fast event like tap our double taps on the device.
> 
> We could default to low-power mode and switch to low-noise mode
> automatically only for the high frequencies where it is mandatory.
> And we could add a sysfs entry like low_noise_mode to enforce
> low-noise mode for lower frequencies supporting it.
> 
> This way traditional userspace can ignore the power_mode setup and
> use all frequencies. And only specialized userpsace components can
> set this low_noise_mode to have better noise values for specific use
> cases. For the hardware bias issue, the high frequency use cases are
> usually not impacted by the absolute offset, so it should not be a
> big issue.
> 
> Is that OK for you?

The part about defaulting to low power mode where possible on basis
that's what is normally wanted makes sense.

A low_noise_mode switch for special users is a reasonable compromise
I think, but let's see if we get other replies on this or on a patch
implementing the above.

Jonathan

> 
> Thanks,
> JB
> 
> ________________________________________
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Sunday, May 19, 2024 13:52
> To: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com>
> Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>; INV Git Commit
> <INV.git-commit@tdk.com>; lars@metafoo.de <lars@metafoo.de>;
> linux-iio@vger.kernel.org <linux-iio@vger.kernel.org> Subject: Re:
> [PATCH] iio: imu: inv_icm42600: add support of accel low-power mode
> This Message Is From an External Sender This message came from
> outside your organization. 
> On Mon, 13 May 2024 09:18:34 +0000
> Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com> wrote:
> 
> > Hello Jonathan,
> > 
> > sorry for the patch malformation, I will send a V2 fixed.
> > 
> > Our chips have usually 2 working modes called "low-noise" and
> > "low-power".
> > 
> > "Low-noise" is the standard mode where the chip (ADC/MEMS) runs
> > continuously with high precision oscillator. Measures are the best
> > with the less jitter (low noise), you can use the highest possible
> > frequencies (> 500Hz), but power consumption is high, and you
> > cannot use the lowest frequencies (< 12.5Hz).
> > 
> > "Low-power" is duty cycling the chip, turning ADC and MEMS on only
> > when measuring and then turns it off. Power consumption is then
> > much lower (low power), you can use the lowest frequencies (<
> > 12.5Hz), but measures have more jitter, and you cannot use the
> > highest frequencies.
> > 
> > Depending on the use case, you may prefer to have the "low-noise"
> > mode with better measures and high frequencies, or the "low-power"
> > mode with less power consumption and low frequencies. The main
> > point is the frequencies availability depending on the power mode.
> > 
> > We could have the driver switching automatically from low-noise to
> > low-power to support all possible frequencies, but we need to
> > arbitrary choose the mode for the common frequencies, and the
> > configured hardware bias in bias registers are not the same
> > depending on the power mode. We prefer handling all this from
> > userspace, switching the mode when needed depending on the use case
> > and dealing with the 2 sets of hardware bias depending on the modes.
> > 
> > I hope I am clear enough with my description.
> >   
> 
> Whilst I understand the motivation, the problem with this is that
> most userspace software will have no idea what these controls do. It
> is very challenging to provide enough discoverability to userspace
> because these modes tend to have weird and wonderful side effects
> (e.g. the hardware bias here).
> 
> So I'd very strongly suggest at least a 'default' option to figure it
> out from the requested frequencies probably defaulting to low noise
> on the common frequencies
> - "when in doubt give the best possible data". 
> 
> With that in place, I'd be more likely to be persuaded of the need
> for a 'tweak' bit of custom ABI that overrides this automatic
> parameter setting. Thus things would work as well as possible for
> normal software, and advanced software, by which I mean your
> userspace stack, would have access to a way to bias the low power /
> low noise decision in the common frequencies.
> 
> The sticky bit here is that hardware bias. I'm assuming that is what
> we are controlling via calibbias?  If so is there any sane way to
> relate the two sets of bias values?
> Normally (I think) that stuff is about fixing variability in the
> analog signal part of the device, so I'd expect any change in value
> to be predictable unless there is something odd going on with digital
> filtering perhaps?
> 
> Finally I do wonder how often people use those mid frequencies where
> there is a direct choice.  In broad terms the reason for low power is
> to do detection of background stuff - screen rotation etc in which
> case they'd also pick low frequency to save even more power. The low
> noise modes are for when the precise data matters a lot more and
> those tend to also need at least moderately high sampling rates
> because people are typically running some sensor fusion on top and
> accurate data but at low frequency is usually no good for that unless
> you know something is mechanically filtering the motion (i.e it's
> fine on measuring shaft rotation on something with lots of inertial,
> not so much human motion).
> 
> Jonathan
> 
> > Thanks,
> > JB
> > 
> > 
> > 
> > ________________________________________
> > From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> > Sent: Thursday, May 9, 2024 15:13
> > To: INV Git Commit <INV.git-commit@tdk.com>
> > Cc: jic23@kernel.org <jic23@kernel.org>; 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] iio: imu:
> > inv_icm42600: add support of accel low-power mode This Message Is
> > From an External Sender This message came from outside your
> > organization. On Tue,  7 May 2024 10:30:56 +0000
> > inv.git-commit@tdk.com wrote:
> >   
> > > From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> > > 
> > > Add channel attributes "power_mode" and "power_mode_available" for
> > > setting accel power mode (low-noise or low-power).
> > > 
> > > Differents ODRs and filter are possible depending on the power
> > > mode. Thus make ODRs and filter dynamic and check values when
> > > applying.    
> > Hi Jean-Baptiste
> > 
> > No Sign-off?
> > 
> > We have never provided this sort of control because it's near
> > impossible for user space to know what to do with it.
> > 
> > Various attempts happened in the past to provide enough info
> > to userspace, but didn't succeed because what low power means
> > is incredibly chip dependent.  As a general rule everyone wants
> > low power, but at 0 perf cost :)
> > 
> > What are the results of low power mode? Normally it maps as
> > something we can enable when some other set of states is set or
> > automatically control based on how often the device is being
> > accessed etc.
> > 
> > For example, what do we loose by choosing this mode for everything
> > below 200Hz?
> > 
> > I see there is some reference to 'low noise' - what does that
> > actually mean for this device? Is it oversampling or running lower
> > resolution on the ADCs?  If so those are the things to look at as
> > ways to control this.  Choose lowest power to meet a given set of
> > requirements.
> > 
> > Jonathan  
>