[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1M78gtJm95eMjrk+N4KdiY3T=dqyksYdNJotd90qV60A@mail.gmail.com>
Date: Fri, 13 Jul 2018 11:16:16 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Gregor Boirie <gregor.boirie@...rot.com>,
Jonathan Cameron <jic23@...nel.org>, linux-iio@...r.kernel.org,
Lars-Peter Clausen <lars@...afoo.de>,
Randy Dunlap <rdunlap@...radead.org>,
Dave Chinner <david@...morbit.com>,
John Stultz <john.stultz@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Stephen Boyd <sboyd@...nel.org>,
Jonathan Corbet <corbet@....net>,
Matthew Wilcox <willy@...radead.org>,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [v2] Documentation: document ktime_get_*() APIs
On Fri, Jul 13, 2018 at 9:24 AM, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Tue, Jul 10, 2018 at 4:48 PM Arnd Bergmann <arnd@...db.de> wrote:
>>
>> Cc: Dave Chinner <david@...morbit.com>
>> Cc: John Stultz <john.stultz@...aro.org>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: Stephen Boyd <sboyd@...nel.org>
>> Cc: Linus Walleij <linus.walleij@...aro.org>
>> Tested-by: Randy Dunlap <rdunlap@...radead.org>
>> Reviewed-by: Randy Dunlap <rdunlap@...radead.org>
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>> ---
>> v2: minor changes suggested by Randy
>
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
Thanks!
> This brings into question commit bc2b7dab629a5
> "iio:core: timestamping clock selection support"
> that has bothered me for some time. Now that is ABI, but
> we might be able to do some recommendations based on the
> time base and have a sensible default moving forward.
>
> As I want to make that clock base parsing similar for GPIO
> I first thought it was a good idea to support the same clocks,
> but now it seems like a bad idea.
>
> IIRC you told me to simply hammer down the clock that
> makes the most sense.
Right, my general recommendation would be to return the
result of ktime_get_ns() in a __u64, since this does not suffer
from the settimeofday or leap second issues that clock_realtime
has, using the coarse clock to save 100 cycles per call probably
won't help.
Arnd
Powered by blists - more mailing lists