Message-ID: <20250614143335.2049da6e@jic23-huawei>
Date: Sat, 14 Jun 2025 14:33:35 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Lothar Rubusch <l.rubusch@...il.com>
Cc: dlechner@...libre.com, nuno.sa@...log.com, andy@...nel.org,
 corbet@....net, lucas.p.stankus@...il.com, lars@...afoo.de,
 Michael.Hennerich@...log.com, bagasdotme@...il.com,
 linux-iio@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 10/11] iio: accel: adxl313: add AC coupled
 activity/inactivity events

On Wed, 11 Jun 2025 21:58:36 +0200
Lothar Rubusch <l.rubusch@...il.com> wrote:

> Hi Jonathan,
> 
> On Sun, Jun 8, 2025 at 6:23 PM Jonathan Cameron <jic23@...nel.org> wrote:
> >
> > On Sun,  1 Jun 2025 17:21:38 +0000
> > Lothar Rubusch <l.rubusch@...il.com> wrote:
> >  
> > > Add AC coupling activity and inactivity as MAG_ADAPTIVE events. This adds
> > > up an additional set of threshold and period handles, verifies matching
> > > disabling functionality and extends setting the link bit to complementary
> > > event configurations.
> > >
> > > This means, e.g. either ACTIVITY or ACTIVITY_AC can be enabled. The most
> > > recent set will remain configured. Disabling ACTIVITY where ACTIVITY_AC was
> > > enabled is ignored, since it does not match (should be disabling
> > > ACTIVITY_AC). When INACTIVITY or INACTIVITY_AC is also enabled, the link
> > > bit will be set. Note, having the link bit and auto-sleep in place activity
> > > and inactivity indicate the power save state change and thus will only be
> > > triggered once a state transition occurs. Since there is a separate AC bit
> > > for ACTIVITY and for INACTIVITY, events can be linked independently from
> > > each other i.e. ACTIVITY can be linked to INACTIVITY_AC for instance.
> > >
> > > When one of both is disabled, the link bit will be removed. Hence, the
> > > remaining event will not indicate a plain state change anymore, but occur
> > > as a periodically triggered inactivity event or for each activity event
> > > above the threshold.
> > >
> > > Signed-off-by: Lothar Rubusch <l.rubusch@...il.com>  
> >
> > Minor thought on rereading this.  If we don't have the link bit set
> > (and the paired event) the AC events are more accurately described as
> > MAG_REFERENCED as they are referenced simply to whatever acceleration
> > was going on when they were first enabled.   Only with the link bit
> > set (and the other event type enabled) are they actually adapting
> > (so MAG_ADAPTIVE).
> >  
> 
> Going by examples, I can follow you as practically I'm aware of the
> difference between a plain inactivity setup and a link-bit enabled
> inactivity(and activity) setup. Initially I thought of MAG and the
> AC-coupled equivalent being MAG_REFERENCED. By your explanation I
> understand why you preferred MAG_ADAPTIVE rather. But still all three
> configurations are possible.
> 
> My idea is, the driver implementation supports all cases in parallel,
> at least to a certain extent. I mean, at the current implementation
> someone can configure plain activity, or AC-coupled activity, or
> respectively, their inactivity equivalents - when both, an activity
> type together with an inactivity type are enabled, they will be linked
> counter events. I.e. "adaptive" - and auto-sleep will be turned on for
> the inactivity periods. Built on using just plain IIO API w/o custom
> API calls.
> 
> Due to all the possible combinations, this comes at a certain
> complexity. In terms of configuration and for instance mapping to MAG,
> MAG_REFERNCED or MAG_ADAPTIVE. Here I rely on your feedback. On my
> side, I'll try to recycle the automation setup to verify registers are
> configured as I like them to be using the sysfs handles (that's btw
> the reason why I'm glad to have debugfs on board). So, if you tell me,
> to change it rather to MAG_REFERENCED, I'll do it, but then AC-coupled
> events will be all MAG_REFRENCED w/ or w/o link bit. Or we come up
> with a total different approach, like putting link-bit AC on
> MAG_ADAPTIVE and plain AC-coupled on MAG_REFERENCED, but then what
> about MAG events w/ or w/o link-bit? hmm, I think current approach
> seems to be a good compromise. Let me know what you think.

I don't have a good answer for how to handle this complexity :(
This was more about an earlier question I think you asked about whether
there was a way to have the user opt in to the link bit or not.

I'm fine with treating them all as adaptive and glossing over exactly
how it is adapting but that doesn't get us to link bit control if
we decide that wants to be explicitly exposed at all.

J
> 
> Best,
> L
> 
> >
> > Maybe there is room to use that to ultimately control whether the
> > link bit is set or not (putting aside the power aspect of that).
> >  

Powered by blists - more mailing lists