From: Jonathan Cameron <jic23@kernel.org>
To: Lothar Rubusch <l.rubusch@gmail.com>
Cc: lars@metafoo.de, Michael.Hennerich@analog.com,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
eraretuya@gmail.com
Subject: Re: [PATCH v2 15/22] iio: accel: adxl345: reset the FIFO on error
Date: Sun, 24 Nov 2024 18:54:49 +0000 [thread overview]
Message-ID: <20241124185449.6f81ade1@jic23-huawei> (raw)
In-Reply-To: <20241117182651.115056-16-l.rubusch@gmail.com>
On Sun, 17 Nov 2024 18:26:44 +0000
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> Add a function to empty the FIFO and reset the INT_SOURCE register.
> Reading out is used to reset the fifo again. For cleanup also a read
> on the INT_SOURCE register is needed to allow the adxl345 to issue
> interrupts again. Without clearing the fields no further interrupts
> will happen.
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/iio/accel/adxl345_core.c | 75 ++++++++++++++++++++++++++++----
> 1 file changed, 67 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> index 40e78dbdb0..82bd5c2b78 100644
> --- a/drivers/iio/accel/adxl345_core.c
> +++ b/drivers/iio/accel/adxl345_core.c
> @@ -356,6 +356,61 @@ static int adxl345_get_fifo_entries(struct adxl34x_state *st, int *fifo_entries)
> return 0;
> }
>
> +/**
> + * adxl345_read_fifo_elements() - Read fifo_entries number of elements.
> + * @st: The instance of the state object of this sensor.
> + * @fifo_entries: The number of lines in the FIFO referred to as fifo_entry,
> + * a fifo_entry has 3 elements for X, Y and Z direction of 2 bytes each.
> + *
> + * The FIFO of the sensor is read linewise. The read measurement values are
> + * queued in the corresponding data structure in *st.
> + *
> + * It is recommended that a multiple-byte read of all registers be performed to
> + * prevent a change in data between reads of sequential registers. That is to
> + * read out the data registers X0, X1, Y0, Y1, Z0, Z1 at once.
To ensure this, set avail_scan_modes.
Then if the user requests a subset, the IIO core code will extract what is necessary
from the read of everythign.
> + *
> + * Return: 0 or error value.
> + */
> +static int adxl345_read_fifo_elements(struct adxl34x_state *st, int fifo_entries)
> +{
> + size_t count, ndirs = 3;
> + int i, ret;
> +
> + count = 2 * ndirs; /* 2 byte per direction */
sizeof(st->fifo_buf[0] * ndirs);
> + for (i = 0; i < fifo_entries; i++) {
> + ret = regmap_noinc_read(st->regmap, ADXL345_REG_XYZ_BASE,
> + st->fifo_buf + (i * count / 2), count);
> + if (ret) {
> + pr_warn("%s(): regmap_noinc_read() failed\n", __func__);
> + return -EFAULT;
> + }
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * adxl345_empty_fifo() - Empty the FIFO.
> + * @st: The instance to the state object of the sensor.
> + *
> + * Reading all elements of the FIFO linewise empties the FIFO. Reading th
> + * interrupt source register resets the sensor. This is needed also in case of
> + * overflow or error handling to reenable the sensor to issue interrupts.
> + */
> +static void adxl345_empty_fifo(struct adxl34x_state *st)
> +{
> + int regval;
> + int fifo_entries;
> +
> + /* In case the HW is not "clean" just read out remaining elements */
> + adxl345_get_fifo_entries(st, &fifo_entries);
> + if (fifo_entries > 0)
> + adxl345_read_fifo_elements(st, fifo_entries);
> +
> + /* Reset the INT_SOURCE register by reading the register */
> + regmap_read(st->regmap, ADXL345_REG_INT_SOURCE, ®val);
> +}
> +
> static const struct iio_buffer_setup_ops adxl345_buffer_ops = {
> };
>
> @@ -401,30 +456,34 @@ static irqreturn_t adxl345_trigger_handler(int irq, void *p)
>
> ret = adxl345_get_status(st, &int_stat);
> if (ret < 0)
> - goto done;
> + goto err;
All this churn just makes things less readable. Better to have the bulk
of the addition of fifo handling in one patch. It won't be too large
for review.
>
> /* Ignore already read event by reissued too fast */
> if (int_stat == 0x0)
> - goto done;
> + goto err;
>
> /* evaluation */
>
> if (int_stat & ADXL345_INT_OVERRUN) {
> pr_debug("%s(): OVERRUN event detected\n", __func__);
> - goto done;
> + goto err;
> }
>
> if (int_stat & (ADXL345_INT_DATA_READY | ADXL345_INT_WATERMARK)) {
> pr_debug("%s(): WATERMARK or DATA_READY event detected\n", __func__);
> if (adxl345_get_fifo_entries(st, &fifo_entries) < 0)
> - goto done;
> - }
> - goto done;
> -done:
> + goto err;
>
> - if (indio_dev)
> iio_trigger_notify_done(indio_dev->trig);
> + }
>
> + goto done;
> +err:
> + iio_trigger_notify_done(indio_dev->trig);
> + adxl345_empty_fifo(st);
> + return IRQ_NONE;
NONE is probably a bad idea. Something went wrong but that doesn't
mean it wasn't our interrupt. In most cases it is better to just
return that we handled it. IRQ_NONE might be valid if the status
said it wasn't ours.
> +
> +done:
> return IRQ_HANDLED;
return where you have goto done and get rid of this.
> }
>
next prev parent reply other threads:[~2024-11-24 18:54 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-17 18:26 [PATCH v2 00/22] iio: accel: adxl345: add FIFO operating with IRQ triggered watermark events Lothar Rubusch
2024-11-17 18:26 ` [PATCH v2 01/22] iio: accel: adxl345: fix comment on probe Lothar Rubusch
2024-11-24 17:57 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 02/22] iio: accel: adxl345: rename variable data to st Lothar Rubusch
2024-11-17 18:26 ` [PATCH v2 03/22] iio: accel: adxl345: rename struct adxl34x_state Lothar Rubusch
2024-11-24 18:01 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 04/22] iio: accel: adxl345: rename to adxl34x_channels Lothar Rubusch
2024-11-24 18:02 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 05/22] iio: accel: adxl345: measure right-justified Lothar Rubusch
2024-11-24 18:07 ` Jonathan Cameron
2024-11-26 13:51 ` Lothar Rubusch
2024-11-26 17:44 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 06/22] iio: accel: adxl345: add function to switch measuring Lothar Rubusch
2024-11-24 18:10 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 07/22] iio: accel: adxl345: initialize IRQ number Lothar Rubusch
2024-11-24 18:14 ` Jonathan Cameron
2024-11-26 16:16 ` Lothar Rubusch
2024-11-26 17:49 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 08/22] iio: accel: adxl345: initialize FIFO delay value for SPI Lothar Rubusch
2024-11-24 18:16 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 09/22] iio: accel: adxl345: unexpose private defines Lothar Rubusch
2024-11-24 18:22 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 10/22] iio: accel: adxl345: set interrupt line to INT1 Lothar Rubusch
2024-11-24 18:23 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 11/22] iio: accel: adxl345: import adxl345 general data Lothar Rubusch
2024-11-24 18:31 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 12/22] iio: accel: adxl345: elaborate iio channel definition Lothar Rubusch
2024-11-24 18:34 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 13/22] iio: accel: adxl345: add trigger handler Lothar Rubusch
2024-11-24 18:46 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 14/22] iio: accel: adxl345: read FIFO entries Lothar Rubusch
2024-11-24 18:49 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 15/22] iio: accel: adxl345: reset the FIFO on error Lothar Rubusch
2024-11-24 18:54 ` Jonathan Cameron [this message]
2024-11-26 21:53 ` Lothar Rubusch
2024-11-17 18:26 ` [PATCH v2 16/22] iio: accel: adxl345: register trigger ops Lothar Rubusch
2024-11-24 18:56 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 17/22] iio: accel: adxl345: push FIFO data to iio Lothar Rubusch
2024-11-24 18:58 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 18/22] iio: accel: adxl345: start measure at buffer en/disable Lothar Rubusch
2024-11-24 19:00 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 19/22] iio: accel: adxl345: prepare FIFO watermark handling Lothar Rubusch
2024-11-24 19:05 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 20/22] iio: accel: adxl345: use FIFO with watermark IRQ Lothar Rubusch
2024-11-24 19:08 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 21/22] iio: accel: adxl345: sync FIFO reading with sensor Lothar Rubusch
2024-11-24 19:09 ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 22/22] iio: accel: adxl345: add debug printout Lothar Rubusch
2024-11-24 19:11 ` 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=20241124185449.6f81ade1@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=eraretuya@gmail.com \
--cc=l.rubusch@gmail.com \
--cc=lars@metafoo.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.