Message-ID: <378e2d1b-9b38-605b-c20f-fbfeefb07c6d@nvidia.com>
Date:   Tue, 23 Mar 2021 11:01:57 -0700
From:   Dipen Patel <dipenp@...dia.com>
To:     Linus Walleij <linus.walleij@...aro.org>
CC:     Kent Gibson <warthog618@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        Jon Hunter <jonathanh@...dia.com>,
        "Bartosz Golaszewski" <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-tegra <linux-tegra@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Arnd Bergmann <arnd@...db.de>,
        "Richard Cochran" <richardcochran@...il.com>
Subject: Re: GTE - The hardware timestamping engine



On 3/23/21 2:08 AM, Linus Walleij wrote:
> On Mon, Mar 22, 2021 at 9:17 PM Dipen Patel <dipenp@...dia.com> wrote:
> 
>> My follow-up concerns on both Linus's and Kent's feedback:
>>
>> 1.  Please correct me if I am wrong, lineevent in the gpiolib* is only
>>     serves the userspace clients.
>> 1.a What about kernel drivers wanting to use this feature for monitoring its
>>     GPIO lines, see gyroscope example somewhere below. In that regards,
>>     lineevent implementation is not sufficient.
>> 1.b Are you also implying to extend lineevent implementation to kernel
>>     drivers?
> 
> I was talking about lineevent because you mentioned things like
> motors and robotics, and those things are traditionally not run in
> kernelspace because they are not generic hardware that fit in the
> kernel subsystems.
> 
> Normally industrial automatic control tasks are run in a userspace
> thread with some realtime priority.
> 
I mentioned those two use cases as illustration purpose as GTE is not just
restricted to robotics and vehicles. I agree that those applications run
mostly from userspace with RT priority but there most certainly some
kernel drivers they interact and it may want to use GTE, for example,
BMI088 devices mostly used in drones and robotics, it could be extended to
use GTE for its GPIO hw timestamping, GPIO is used to indicate data ready.

> As Kent says, in-kernel events are exclusively using IRQ as
> mechanism, and should be modeled as IRQs. Then the question
> is how you join the timestamp with the IRQ. GPIO chips are
> just some kind of irqchip in this regard, we reuse the irqchip
> infrastructure in the kernel for all GPIO drivers that generate
> "events" in response to state transitions on digital lines.
> 
>>>> And certainly you will also want to use this timestamp for
>>>> IIO devices? If it is just GPIOs and IRQs today, it will be
>>>> gyroscopes and accelerometers tomorrow, am I right?
>>>>
>>
>> Gyroscope, accelerometers or any IIO are built on top of i2c/spi and/or GPIOs.
>> So they are covered as long as they serve as client to GTE framework, For
>> example, if gyroscope uses GPIO as an interrupt to indicate frame
>> ready, GTE could timestamp that GPIO as well any IRQs like i2c transaction
>> complete IRQ. To this to happen, gycroscope then register itself with
>> GTE framework and enable required signals that it interfaces/interested with.
> 
> I think there are IIO devices that provide their own
> hardware timestamp and as such they might want to use that,
> so the mechanism need to be generic enough that a certain
> hardware timestamp can be selected sooner or later.
> But let's not overcomplicate things for now.
> 

I agree, above BMI088 has its own timestamping engine. I have to look into
that aspect for bringing its TS engine into GTE framework as one of the possible
off-chip provides besides in-chip GTEs. We can defer that part for later. Thanks
for pointing that out.

> Yours,
> Linus Walleij
> 

Powered by blists - more mailing lists