On Wed, 22 May 2024 15:35:45 +0000 Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@xxxxxxx> 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@xxxxxxxxxx> > Sent: Sunday, May 19, 2024 13:52 > To: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@xxxxxxx> > Cc: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>; INV Git Commit > <INV.git-commit@xxxxxxx>; lars@xxxxxxxxxx <lars@xxxxxxxxxx>; > linux-iio@xxxxxxxxxxxxxxx <linux-iio@xxxxxxxxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxx> > > Sent: Thursday, May 9, 2024 15:13 > > To: INV Git Commit <INV.git-commit@xxxxxxx> > > Cc: jic23@xxxxxxxxxx <jic23@xxxxxxxxxx>; lars@xxxxxxxxxx > > <lars@xxxxxxxxxx>; linux-iio@xxxxxxxxxxxxxxx > > <linux-iio@xxxxxxxxxxxxxxx>; Jean-Baptiste Maneyrol > > <Jean-Baptiste.Maneyrol@xxxxxxx> 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@xxxxxxx wrote: > > > > > From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@xxxxxxx> > > > > > > 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 >
