From: Jonathan Cameron <jic23@kernel.org>
To: Alexandru Tachici <alexandru.tachici@analog.com>
Cc: <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/6] iio: accel: adxl372: Add support for FIFO peak mode
Date: Sat, 7 Mar 2020 12:02:41 +0000 [thread overview]
Message-ID: <20200307120241.7bee0dc8@archlinux> (raw)
In-Reply-To: <20200225120909.12629-2-alexandru.tachici@analog.com>
On Tue, 25 Feb 2020 14:09:04 +0200
Alexandru Tachici <alexandru.tachici@analog.com> wrote:
> From: Stefan Popa <stefan.popa@analog.com>
>
> By default, if all three channels (x, y, z) are enabled, sample sets of
> concurrent 3-axis data is stored in the FIFO. This patch adds the option
> to configure the FIFO to store peak acceleration (x, y and z) of every
> over-threshold event. Since we cannot store 1 or 2 axis peak acceleration
> data in the FIFO, then all three axis need to be enabled in order for this
> mode to work.
>
> Signed-off-by: Stefan Popa <stefan.popa@analog.com>
First apologies this was one of the sets that I didn't get to last week.
This is a bit of an odd one, but I suppose the general approach is fine.
A few questions on specifics inline.
> ---
> drivers/iio/accel/adxl372.c | 46 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index 67b8817995c0..ed93534f8dba 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -264,6 +264,7 @@ struct adxl372_state {
> u8 int2_bitmask;
> u16 watermark;
> __be16 fifo_buf[ADXL372_FIFO_SIZE];
> + bool peak_fifo_mode_en;
> };
>
> static const unsigned long adxl372_channel_masks[] = {
> @@ -722,6 +723,40 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
> }
> }
>
> +static ssize_t adxl372_peak_fifo_en_get(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct adxl372_state *st = iio_priv(dev_to_iio_dev(dev));
> +
> + return sprintf(buf, "%d\n", st->peak_fifo_mode_en);
> +}
> +
> +static ssize_t adxl372_peak_fifo_en_set(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct adxl372_state *st = iio_priv(indio_dev);
> + bool val;
> + int ret;
> +
> + if (iio_buffer_enabled(indio_dev))
> + return -EBUSY;
Prefer if you use the iio_claim_direct_mode to ensure we are in
non buffered mode until we reach a consistent state. Then set
the variable and release direct mode.
Otherwise you might have a race between a write
to this and enabling the buffered mode.
> +
> + ret = kstrtobool(buf, &val);
> + if (ret)
> + return ret;
> +
> + st->peak_fifo_mode_en = val;
> +
> + return len;
> +}
> +
> +static IIO_DEVICE_ATTR(buffer_peak_mode_enable, 0644,
> + adxl372_peak_fifo_en_get,
> + adxl372_peak_fifo_en_set, 0);
> +
> static ssize_t adxl372_show_filter_freq_avail(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -817,11 +852,21 @@ static int adxl372_buffer_postenable(struct iio_dev *indio_dev)
> st->fifo_format = adxl372_axis_lookup_table[i].fifo_format;
> st->fifo_set_size = bitmap_weight(indio_dev->active_scan_mask,
> indio_dev->masklength);
> +
> + /* Configure the FIFO to store sets of impact event peak. */
> + if (st->peak_fifo_mode_en) {
> + st->fifo_format = ADXL372_XYZ_PEAK_FIFO;
> + if (st->fifo_set_size != 3)
> + dev_warn(&indio_dev->dev,
> + "All axis must be enabled in peak mode.");
What happens otherwise? Real question is should this just be an error and
result in us dropping out of buffered mode again? How would a userspace
program that had hit this know there was an issue?
> + }
> +
> /*
> * The 512 FIFO samples can be allotted in several ways, such as:
> * 170 sample sets of concurrent 3-axis data
> * 256 sample sets of concurrent 2-axis data (user selectable)
> * 512 sample sets of single-axis data
> + * 170 sets of impact event peak (x, y, z)
> */
> if ((st->watermark * st->fifo_set_size) > ADXL372_FIFO_SIZE)
> st->watermark = (ADXL372_FIFO_SIZE / st->fifo_set_size);
> @@ -894,6 +939,7 @@ static IIO_DEVICE_ATTR(in_accel_filter_low_pass_3db_frequency_available,
> static struct attribute *adxl372_attributes[] = {
> &iio_const_attr_sampling_frequency_available.dev_attr.attr,
> &iio_dev_attr_in_accel_filter_low_pass_3db_frequency_available.dev_attr.attr,
> + &iio_dev_attr_buffer_peak_mode_enable.dev_attr.attr,
> NULL,
> };
>
next prev parent reply other threads:[~2020-03-07 12:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 12:09 [PATCH v2 0/6] iio: accel: adxl372: add peak mode Alexandru Tachici
2020-02-25 12:09 ` [PATCH v2 1/6] iio: accel: adxl372: Add support for FIFO " Alexandru Tachici
2020-03-07 12:02 ` Jonathan Cameron [this message]
2020-02-25 12:09 ` [PATCH v2 2/6] iio: accel: adxl372: add sysfs for time registers Alexandru Tachici
2020-03-07 12:15 ` Jonathan Cameron
2020-02-25 12:09 ` [PATCH v2 3/6] iio: accel: adxl372: Add sysfs for g thresholds Alexandru Tachici
2020-02-25 12:09 ` [PATCH v2 4/6] iio: accel: adxl372: add iio events Alexandru Tachici
2020-03-07 12:12 ` Jonathan Cameron
2020-02-25 12:09 ` [PATCH v2 5/6] iio: accel: adxl372: add additional events ABIs Alexandru Tachici
2020-02-25 12:09 ` [PATCH v2 6/6] iio: accel: adxl372: Update sysfs docs Alexandru Tachici
2020-03-07 12:09 ` Jonathan Cameron
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=20200307120241.7bee0dc8@archlinux \
--to=jic23@kernel.org \
--cc=alexandru.tachici@analog.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.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