linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
Cc: jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de,
	pmeerw@pmeerw.net, linux-iio@vger.kernel.org
Subject: Re: [PATCH] iio: imu: st_lsm6dsx: irq not handled unless data pushed to buffers
Date: Wed, 11 Jul 2018 17:26:35 +0200	[thread overview]
Message-ID: <20180711152634.GB12995@localhost.localdomain> (raw)
In-Reply-To: <2d1f0810-a6d0-3785-6692-003bb3f817e0@baylibre.com>

On Jul 11, Jorge Ramirez-Ortiz wrote:
> On 07/11/2018 02:29 PM, Lorenzo Bianconi wrote:
> > > Currently IRQ_NONE is returned only when there is no data on the fifo.
> > > 
> > > When there is no data on the fifo the driver can not push to the
> > > buffers and therefore user space readers polling for data available
> > > will not be awoken and continue to wait.
> > > 
> > > This commit just extends the same semantics to fifo read errors.
> > Hi Jorge,
> > 
> > IRQ_NONE is used to indicate this interrupt is not intended for this driver
> > (this could happen if the irq line is in open-drain). If the interrupt is for
> > st_lsm6dsx I would prefer to return IRQ_HANDLED even in case of error.
> 
> yes I understand.
> 
> This was just a trivial attempt (I guess a really bad idea) to get some
> debug info (via /proc/irq/.../spurious) any time the driver read (spi/i2c)
> fails when processing the data ready irq.
> do you think it would make sense to add a dev_err to
> st_lsm6dsx_i2c_read/st_lsm6dsx_spi_read? at the moment the driver would fail
> silently

do you mean something like (just compiled, not tested):

--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
@@ -298,8 +298,11 @@ static int st_lsm6dsx_read_fifo(struct st_lsm6dsx_hw *hw)
 	err = regmap_bulk_read(hw->regmap,
 			       hw->settings->fifo_ops.fifo_diff.addr,
 			       &fifo_status, sizeof(fifo_status));
-	if (err < 0)
+	if (err < 0) {
+		dev_err(hw->dev, "failed to read fifo status reg (err=%d)\n",
+			err);
 		return err;
+	}
 
 	if (fifo_status & cpu_to_le16(ST_LSM6DSX_FIFO_EMPTY_MASK))
 		return 0;
@@ -313,8 +316,12 @@ static int st_lsm6dsx_read_fifo(struct st_lsm6dsx_hw *hw)
 
 	for (read_len = 0; read_len < fifo_len; read_len += pattern_len) {
 		err = st_lsm6dsx_read_block(hw, hw->buff, pattern_len);
-		if (err < 0)
+		if (err < 0) {
+			dev_err(hw->dev,
+				"failed to read pattern from fifo (err=%d)\n",
+				err);
 			return err;
+		}
 
 		/*
 		 * Data are written to the FIFO with a specific pattern
@@ -385,8 +392,11 @@ static int st_lsm6dsx_read_fifo(struct st_lsm6dsx_hw *hw)
 
 	if (unlikely(reset_ts)) {
 		err = st_lsm6dsx_reset_hw_ts(hw);
-		if (err < 0)
+		if (err < 0) {
+			dev_err(hw->dev, "failed to reset hw ts (err=%d)\n",
+				err);
 			return err;
+		}
 	}
 	return read_len;
 }

Regards,
Lorenzo

> 
> thanks for coming back to me despite the bad patch
> 
> > 
> > Regards,
> > Lorenzo
> > 
> > > Signed-off-by: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
> > > ---
> > >   drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > > index 4994f92..4959923 100644
> > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > > @@ -472,7 +472,7 @@ static irqreturn_t st_lsm6dsx_handler_thread(int irq, void *private)
> > >   	count = st_lsm6dsx_read_fifo(hw);
> > >   	mutex_unlock(&hw->fifo_lock);
> > > -	return !count ? IRQ_NONE : IRQ_HANDLED;
> > > +	return (!count || count < 0) ? IRQ_NONE : IRQ_HANDLED;
> > >   }
> > >   static int st_lsm6dsx_buffer_preenable(struct iio_dev *iio_dev)
> > > -- 
> > > 2.7.4
> > > 
> 

  parent reply	other threads:[~2018-07-11 15:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-11  8:32 [PATCH] iio: imu: st_lsm6dsx: irq not handled unless data pushed to buffers Jorge Ramirez-Ortiz
2018-07-11 12:29 ` Lorenzo Bianconi
2018-07-11 13:24   ` Jorge Ramirez-Ortiz
2018-07-11 14:17     ` Lorenzo Bianconi
2018-07-11 15:26     ` Lorenzo Bianconi [this message]
2018-07-11 16:00       ` Jorge Ramirez-Ortiz
2018-07-11 16:34         ` Lorenzo Bianconi
2018-07-11 16:59           ` Jorge Ramirez-Ortiz
2018-07-11 17:07             ` Lorenzo Bianconi
2018-07-12  7:59             ` Lorenzo Bianconi

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=20180711152634.GB12995@localhost.localdomain \
    --to=lorenzo.bianconi@redhat.com \
    --cc=jic23@kernel.org \
    --cc=jramirez@baylibre.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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;
as well as URLs for NNTP newsgroup(s).