[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <371503c267d9ded0195da126b58bc8339cb864e8.camel@baylibre.com>
Date: Thu, 08 Jan 2026 15:07:07 +0100
From: Francesco Lavra <flavra@...libre.com>
To: Nuno Sá <noname.nuno@...il.com>, Ramona Gradinariu
<ramona.gradinariu@...log.com>, Antoniu Miclaus
<antoniu.miclaus@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>, Jonathan Cameron
<jic23@...nel.org>, David Lechner <dlechner@...libre.com>, Nuno
Sá <nuno.sa@...log.com>, Andy Shevchenko
<andy@...nel.org>, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling
frequency
On Thu, 2026-01-08 at 13:45 +0000, Nuno Sá wrote:
> On Wed, 2026-01-07 at 16:39 +0100, Francesco Lavra wrote:
> > On Wed, 2026-01-07 at 13:56 +0000, Nuno Sá wrote:
> >
> > > 3. Other thing that comes to mind is if it makes sense to allow
> > > controlling odr if
> > > Activity/Inactivity detection is enabled?
> >
> > Disallowing odr control when activity detection is enabled could be an
> > option, but what error code should be returned if the user tries to set
> > the
> > sampling frequency value when not allowed? -EBUSY?
>
> I think it makes sense given the constrains on activity events. EBUSY
> would be my choice as well.
> Out of curiosity, do you know how the chip behaves if we change the odr
> with activity enabled? Is it
> just ignored?
The chip supports activity detection only when in low-power mode; changing
the odr to a value that requires exiting from low-power mode would mean
effectively disabling activity detection. The driver prevents this by
forcing low-power mode whenever detection is enabled, which means that any
odr changes by userspace do not take effect as long as detection is
enabled.
Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)
Powered by blists - more mailing lists