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

[Jonathan Cameron <jic23@kernel.org>]

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