From: "Stefan Brüns" <stefan.bruens@rwth-aachen.de>
To: Jonathan Cameron <jic23@kernel.org>
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 5/7] iio: adc: ina2xx: Use a monotonic clock for delay calculation
Date: Sun, 10 Dec 2017 21:47:37 +0100 [thread overview]
Message-ID: <2674819.FhFV8Gkxuq@pebbles> (raw)
In-Reply-To: <20171210173157.6cc78b4b@archlinux>
[-- Attachment #1: Type: text/plain, Size: 4145 bytes --]
On Sunday, December 10, 2017 6:31:57 PM CET Jonathan Cameron wrote:
> On Fri, 8 Dec 2017 18:41:50 +0100
>
> Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
> > The iio timestamp clock is user selectable and may be non-monotonic. Also,
> > only part of the acquisition time is measured, thus the delay was longer
> > than intended.
> >
> > Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
> > ---
> >
> > drivers/iio/adc/ina2xx-adc.c | 35 +++++++++++++++++++++--------------
> > 1 file changed, 21 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
> > index 2621a34ee5c6..65bd9e69faf2 100644
> > --- a/drivers/iio/adc/ina2xx-adc.c
> > +++ b/drivers/iio/adc/ina2xx-adc.c
> > @@ -703,10 +703,10 @@ static int ina2xx_work_buffer(struct iio_dev
> > *indio_dev)>
> > /* data buffer needs space for channel data and timestap */
> > unsigned short data[4 + sizeof(s64)/sizeof(short)];
> > int bit, ret, i = 0;
> >
> > - s64 time_a, time_b;
> > + s64 time;
> >
> > unsigned int alert;
> >
> > - time_a = iio_get_time_ns(indio_dev);
> > + time = iio_get_time_ns(indio_dev);
> >
> > /*
> >
> > * Because the timer thread and the chip conversion clock
> >
> > @@ -752,11 +752,9 @@ static int ina2xx_work_buffer(struct iio_dev
> > *indio_dev)>
> > data[i++] = val;
> >
> > }
> >
> > - time_b = iio_get_time_ns(indio_dev);
> > + iio_push_to_buffers_with_timestamp(indio_dev, data, time);
> >
> > - iio_push_to_buffers_with_timestamp(indio_dev, data, time_a);
> > -
> > - return (unsigned long)(time_b - time_a) / 1000;
> > + return 0;
> >
> > };
> >
> > static int ina2xx_capture_thread(void *data)
> >
> > @@ -764,7 +762,9 @@ static int ina2xx_capture_thread(void *data)
> >
> > struct iio_dev *indio_dev = data;
> > struct ina2xx_chip_info *chip = iio_priv(indio_dev);
> > int sampling_us = SAMPLING_PERIOD(chip);
> >
> > - int buffer_us, delay_us;
> > + int ret;
> > + struct timespec64 next, now, delta;
> > + s64 delay_us;
> >
> > /*
> >
> > * Poll a bit faster than the chip internal Fs, in case
> >
> > @@ -773,15 +773,22 @@ static int ina2xx_capture_thread(void *data)
> >
> > if (!chip->allow_async_readout)
> >
> > sampling_us -= 200;
> >
> > + ktime_get_ts64(&next);
> > +
> >
> > do {
> >
> > - buffer_us = ina2xx_work_buffer(indio_dev);
> > - if (buffer_us < 0)
> > - return buffer_us;
> > + ret = ina2xx_work_buffer(indio_dev);
> > + if (ret < 0)
> > + return ret;
> >
> > - if (sampling_us > buffer_us) {
> > - delay_us = sampling_us - buffer_us;
> > - usleep_range(delay_us, (delay_us * 3) >> 1);
> > - }
> > + ktime_get_ts64(&now);
> > +
> > + do {
> > + timespec64_add_ns(&next, 1000 * sampling_us);
> > + delta = timespec64_sub(next, now);
> > + delay_us = timespec64_to_ns(&delta) / 1000;
> > + } while (delay_us <= 0);
>
> Umm. I'm lost, what is the purpose of the above dance?
> A comment perhaps.
next is the timestamp for the next read to happen, now is the current time.
Obviously we have to sleep for the remainder.
Each sampling interval the "next" timestamp is pushed back by sampling_us.
Normally this happens exactly once per read, i.e. we schedule the reads to
happen exactly each sampling interval.
The sampling inteval is *only* added multiple times if it is faster than the
bus can deliver the data (at 100 kBits/s, each register read takes about 400
us, so sampling faster than every ~1 ms is not possible.
The old code measured the time spent for reading the registers and slept for
the remainder of the interval. This way the sampling drifts, as there is some
time not accounted for - usleep_range, function call overhead, kthread
interrupted.
Using a timestamp avoids the drift. It also allows simple readjustment of the
"next" sampling time when polling the status register.
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2017-12-10 20:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20171208174152.30341-1-stefan.bruens@rwth-aachen.de>
2017-12-08 17:41 ` [PATCH v1 1/7] iio: adc: ina2xx: Remove bogus cast for data argument Stefan Brüns
2017-12-17 9:43 ` Jonathan Cameron
2017-12-08 17:41 ` [PATCH v1 2/7] iio: adc: ina2xx: Clarify size requirement for data buffer Stefan Brüns
2017-12-17 9:44 ` Jonathan Cameron
2017-12-08 17:41 ` [PATCH v1 3/7] iio: adc: ina2xx: Remove unneeded dummy read to clear CNVR flag Stefan Brüns
2017-12-10 17:27 ` Jonathan Cameron
2017-12-10 20:53 ` Stefan Brüns
2017-12-12 20:15 ` Jonathan Cameron
2017-12-12 23:48 ` Stefan Brüns
2017-12-17 10:09 ` Jonathan Cameron
2017-12-08 17:41 ` [PATCH v1 4/7] iio: adc: ina2xx: Do not udelay for several seconds Stefan Brüns
2017-12-17 11:53 ` Jonathan Cameron
2017-12-08 17:41 ` [PATCH v1 5/7] iio: adc: ina2xx: Use a monotonic clock for delay calculation Stefan Brüns
2017-12-10 17:31 ` Jonathan Cameron
2017-12-10 20:47 ` Stefan Brüns [this message]
2017-12-12 20:21 ` Jonathan Cameron
2017-12-17 11:56 ` Jonathan Cameron
2017-12-08 17:41 ` [PATCH v1 6/7] iio: adc: ina2xx: Align timestamp with conversion ready flag Stefan Brüns
2017-12-08 17:41 ` [PATCH v1 7/7] iio: adc: ina2xx: Actually align the loop with the " Stefan Brüns
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=2674819.FhFV8Gkxuq@pebbles \
--to=stefan.bruens@rwth-aachen.de \
--cc=afd@ti.com \
--cc=javier@osg.samsung.com \
--cc=jic23@kernel.org \
--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 \
/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