From: Cosmin Tanislav <demonsingur@gmail.com>
To: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>,
"Tanislav, Cosmin" <Cosmin.Tanislav@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
Rob Herring <robh+dt@kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] iio: accel: add ADXL367 driver
Date: Tue, 11 Jan 2022 00:43:25 +0200 [thread overview]
Message-ID: <ab212905-2377-040b-ce8a-2cef3ae13002@gmail.com> (raw)
In-Reply-To: <20211228205757.7654cb66@jic23-huawei>
On 12/28/21 22:58, Jonathan Cameron wrote:
> Hi Cosmin,
>
> Happy New year for a few day's time.
>
>>> ...
>>>
>>>> +
>>>> +static bool adxl367_push_event(struct iio_dev *indio_dev, u8 status)
>>>> +{
>>>> + unsigned int ev_dir;
>>>> +
>>>> + if (FIELD_GET(ADXL367_STATUS_ACT_MASK, status))
>>>> + ev_dir = IIO_EV_DIR_RISING;
>>>> + else if (FIELD_GET(ADXL367_STATUS_INACT_MASK, status))
>>>> + ev_dir = IIO_EV_DIR_FALLING;
>>>> + else
>>>> + return false;
>>>> +
>>>> + iio_push_event(indio_dev,
>>>> + IIO_MOD_EVENT_CODE(IIO_ACCEL, 0,
>>> IIO_MOD_X_OR_Y_OR_Z,
>>>> + IIO_EV_TYPE_THRESH, ev_dir),
>>> This is unusual for event detection as it's a simple or of separately
>>> applied thresholds on X, Y and Z axes. Given the effect of gravity that
>>> means you have to set the thresholds very wide.
>>>
>>> Also, I'd expect these to be magnitudes, not THRESH - no data sheet that
>>> I can find though so can't be sure.
>>>
>>
>> Actually, the chip has a referenced, and an absolute mode. We use reference mode
>> in this driver, as configured in write_event_config.
>> The motion detection details are about the same as ADXL362 (page 14).
>> https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL362.pdf
>
> Interesting. We should figure out some way to make that clear to userspace
> given right now it has no way of knowing that and might set inappropriate limits
> without that information.
>
Any suggestions on how I should do this?
> It's kind of similar to some of the adaptive thresholds, just that it uses
> the value at a particular moment.
>
> Worth noting that for the adxl362 at least the maths is
> ABS(Acceleration - reference) > Threshold which is a magnitude not a threshold
> unless you want to represent it as a pair of thresholds (above and below) which
> gets fiddly as I assume there is only one control
>
Indeed. I didn't catch onto the difference between magnitude and
threshold. So, I should use IIO_EV_TYPE_MAG rather than
IIO_EV_TYPE_THRESH? Or IIO_EV_TYPE_MAG_ADAPTIVE? The ABI doesn't
describe these too well.
>>
>>
>>>> + iio_get_time_ns(indio_dev));
>>>> +
>>>> + return true;
>>>> +}
>
> ...
>
>>>> +static int adxl367_write_event_config(struct iio_dev *indio_dev,
>>>> + const struct iio_chan_spec *chan,
>>>> + enum iio_event_type type,
>>>> + enum iio_event_direction dir,
>>>> + int state)
>>>> +{
>>>> + struct adxl367_state *st = iio_priv(indio_dev);
>>>> + enum adxl367_activity_type act;
>>>> + int ret;
>>>> +
>>>> + switch (dir) {
>>>> + case IIO_EV_DIR_RISING:
>>>> + act = ADXL367_ACTIVITY;
>>>> + break;
>>>> + case IIO_EV_DIR_FALLING:
>>>> + act = ADXL367_INACTIVITY;
>>>> + break;
>>>> + default:
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + ret = iio_device_claim_direct_mode(indio_dev);
>>>
>>> It's unusual (though not unheard of) to have events that cannot be enabled
>>> at the same time as a fifo. If that's true here, please add some comments
>>> to explain why. Or is this just about the impact of having to disable
>>> the measurement to turn it on and the resulting interruption of data
>>> capture?
>>>
>>> If so that needs more thought as we have a situation where you can (I think)
>>> have events as long as you enable them before the fifo based capture is
>>> started,
>>> but cannot enable them after.
>>>
>>
>> That is indeed the case. You mentioned in a previous patchset that various
>> attributes could toggle measurement mode while the FIFO capture was running,
>> so I checked all the possible places where that could happen and added claim
>> direct mode. Not too nice, but it's the nature of the chip...
>
> Hmm. I'm not sure what the right thing to do here is. Maybe we need a docs update
> to explicitly call out that this might happen for the event enables? Calling
> it out for all devices is fine because all we are doing is saying userspace would
> ideally cope with this situation and make the decision to disable the buffered
> mode if it wants to enable events then reenable it afterwards if that is what
> is desired.
By docs you mean the ABI file?
>
> Jonathan
>
>
next prev parent reply other threads:[~2022-01-10 22:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-17 11:45 [PATCH v3 0/2] Add ADXL367 driver Cosmin Tanislav
2021-12-17 11:45 ` [PATCH v3 1/2] dt-bindings: iio: accel: add ADXL367 Cosmin Tanislav
2021-12-17 11:45 ` [PATCH v3 2/2] iio: accel: add ADXL367 driver Cosmin Tanislav
2021-12-17 16:29 ` kernel test robot
2021-12-23 13:01 ` Jonathan Cameron
2021-12-27 13:00 ` Tanislav, Cosmin
2021-12-28 20:58 ` Jonathan Cameron
2022-01-10 22:43 ` Cosmin Tanislav [this message]
2022-01-15 17:50 ` Jonathan Cameron
2021-12-17 13:48 ` [PATCH v3 0/2] Add " Cosmin Tanislav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ab212905-2377-040b-ce8a-2cef3ae13002@gmail.com \
--to=demonsingur@gmail.com \
--cc=Cosmin.Tanislav@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=devicetree@vger.kernel.org \
--cc=jic23@jic23.retrosnub.co.uk \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox