public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
> 
> 

  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