[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdb-AFvLhwOLSs5ocqiZ6ZwZbQMzWGfQ6C3AX+=ouH+=ng@mail.gmail.com>
Date: Sun, 27 Jun 2021 13:49:08 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Dipen Patel <dipenp@...dia.com>
Cc: "thierry.reding@...il.com" <thierry.reding@...il.com>,
Jon Hunter <jonathanh@...dia.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-tegra <linux-tegra@...r.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Kent Gibson <warthog618@...il.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>
Subject: Re: [RFC 08/11] gpiolib: cdev: Add hardware timestamp clock type
On Sat, Jun 26, 2021 at 1:48 AM Dipen Patel <dipenp@...dia.com> wrote:
Just a quick question about this:
> + GPIO_V2_LINE_FLAG_EVENT_CLOCK_HARDWARE | \
Is the usage intended to be such that since hardware timestamp
can not be guaranteed we need to ask for it and fail and if that
fails maybe the software wants to fall back to the realtime or
common timestamp?
I'm thinking from the view of libgpiod or similar apps that abstract
this and they will be "I want to use hardware timestamps if and
only if it is available, otherwise I want to use this other timestamp"
or is that use case uncommon, such that either you know exactly
what you want or you should not be messing with hardware
timestamps?
Yours,
Linus Walleij
Powered by blists - more mailing lists