All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: "Stefan Brüns" <stefan.bruens@rwth-aachen.de>
Cc: <linux-iio@vger.kernel.org>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Maciej Purski <m.purski@samsung.com>,
	<linux-kernel@vger.kernel.org>, "Andrew F . Davis" <afd@ti.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Hartmut Knaack <knaack.h@gmx.de>,
	"Javier Martinez Canillas" <javier@osg.samsung.com>
Subject: Re: [PATCH v1 0/7] iio: adc: ina2xx: Rework CNVR alignment, fix busy loops
Date: Sun, 10 Dec 2017 17:36:54 +0000	[thread overview]
Message-ID: <20171210173654.0d6cb19a@archlinux> (raw)
In-Reply-To: <8e8ef11e-37df-44f3-b4a4-06e995924ca8@rwthex-w2-a.rwth-ad.de>

On Fri, 8 Dec 2017 18:41:45 +0100
Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:

> Currently, the INA2xx driver may end up causing 100% load on a single core
> and fully loading the I2C bus, which is caused by two different issues:
> 
> The code uses a udelay to bridge the gab between two subsequent samples.
> As the sampling interval may be up to 16 seconds, the CPU is busy
> waiting most of the time.
> 
> The second issue manifests when using the (default) "synchronous" mode.
> The code polls for a set conversion ready flag, but fails to align the
> sampling interval to the raising flag. The polling interval is
> (rightfully) slighly shorter than the sampling interval, so after some
> samples the sampling thread is continously polling.

I'm confused.  Would you mind doing an asci art example perhaps?

Thanks,

Jonathan
> 
> The patch series fixes both issues:
> Patch 1 and 2 are just some small cosmetic changes.
> 
> Patch 3 removes an unnecessary read. According to the datasheet, the
> CNVR flag is only cleared by reading the power register, but is cleared
> by reading any of the measurement registers, thus the dummy read can
> be skipped. This behaviour has been confirmed by TI technical support.
> 
> Patch 4 replaces the udelay with usleep_range.
> 
> Patch 5 reworks the delay logic. Previously the IIO timestamp clock was
> used to capture entry and exit times of the work function. The
> timestamp clock is user selectable and may be non-monotonic. Also,
> any time spent outside the work function is not accounted for.
> 
> Patch 6 moves the timestap capture to the end of the conversion ready
> status poll.
> 
> Patch 7 addresses the alignment issue. Every time an unset flag is seen
> on poll loop entry, the reference timestamp is readjusted.
> 
> Both old and fixed behaviour has been verified using a logic analyzer.
> In synchrounous mode, every few samples a double read of the status
> register can be observed, showing the raising status flag, the other
> samples are evenly spaced at sampling intervals inbetween.
> 
> 
> Stefan Brüns (7):
>   iio: adc: ina2xx: Remove bogus cast for data argument
>   iio: adc: ina2xx: Clarify size requirement for data buffer
>   iio: adc: ina2xx: Remove unneeded dummy read to clear CNVR flag
>   iio: adc: ina2xx: Do not udelay for several seconds
>   iio: adc: ina2xx: Use a monotonic clock for delay calculation
>   iio: adc: ina2xx: Align timestamp with conversion ready flag
>   iio: adc: ina2xx: Actually align the loop with the conversion ready
>     flag
> 
>  drivers/iio/adc/ina2xx-adc.c | 104 ++++++++++++++++++++++++-------------------
>  1 file changed, 59 insertions(+), 45 deletions(-)
> 


  reply	other threads:[~2017-12-10 17:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08 17:41 [PATCH v1 0/7] iio: adc: ina2xx: Rework CNVR alignment, fix busy loops Stefan Brüns
2017-12-10 17:36 ` Jonathan Cameron [this message]
2017-12-10 20:22   ` Stefan Brüns
2017-12-12 20:08     ` 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=20171210173654.0d6cb19a@archlinux \
    --to=jic23@kernel.org \
    --cc=afd@ti.com \
    --cc=javier@osg.samsung.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.purski@samsung.com \
    --cc=pmeerw@pmeerw.net \
    --cc=stefan.bruens@rwth-aachen.de \
    /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.