All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Gregor Boirie <gregor.boirie@parrot.com>,
	Jonathan Cameron <jic23@jic23.retrosnub.co.uk>,
	Lars-Peter Clausen <lars@metafoo.de>,
	linux-iio@vger.kernel.org
Subject: Re: using monotonic clok for timstamping
Date: Tue, 9 Feb 2016 20:49:47 +0000	[thread overview]
Message-ID: <56BA50EB.5040101@kernel.org> (raw)
In-Reply-To: <56B9F570.1050108@parrot.com>

On 09/02/16 14:19, Gregor Boirie wrote:
> On 02/09/2016 12:06 PM, Gregor Boirie wrote:
>> One remaining question is : how do we ensure sample and event timestamps
>> consistency with respect to clock changes ? 2 suggestions:
>> * reject the ability to select a new clock as long as an events chardev is opened
>>   or a buffered samples channel is enabled ;
> Actually, this may be the only viable solution since some drivers save timestamps for
> futur usage (see drivers/iio/accel/bmc150-accel-core.c). Changing reference clock
> between 2 timestamping operations would lead to inconsistencies.
Agreed.  It will want to be locked unless we can be fairly sure it's not in use.
In most cases I can't see why a user wouldn't set it before opening any of the chardevs
so that would cover the direct userspace access case.  The more complex option is in
kernel use of the buffered interface (or events once I we actually add an interface
to get those in client drivers).  As you say, locking when the channel is enabled
would work - or during the buffer set up and unlock in the tear down.  Hold
mlock when updating as well to prevent any odd windows of buffer going up or coming down.

Should work I think.... Though the proof as ever will be in the code!

Jonathan
>> * clock may be changed at any time since it could be implemented in an atomic
>>   way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2016-02-09 20:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 10:55 Gregor Boirie
2016-02-03 11:22 ` Lars-Peter Clausen
2016-02-06 18:33   ` Jonathan Cameron
2016-02-08  9:55     ` Lars-Peter Clausen
2016-02-08 17:15       ` Jonathan Cameron
2016-02-09 11:06         ` Gregor Boirie
2016-02-09 14:19           ` Gregor Boirie
2016-02-09 20:49             ` Jonathan Cameron [this message]
2016-02-09 20:52           ` Lars-Peter Clausen
2016-02-09 21:02             ` Jonathan Cameron
2016-02-10  9:46             ` Gregor Boirie

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=56BA50EB.5040101@kernel.org \
    --to=jic23@kernel.org \
    --cc=gregor.boirie@parrot.com \
    --cc=jic23@jic23.retrosnub.co.uk \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --subject='Re: using monotonic clok for timstamping' \
    /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

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.