Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191211214852.26317-1-christopher.s.hall@intel.com>
 <87eevf4hnq.fsf@nanos.tec.linutronix.de> <20200224224059.GC1508@skl-build> <87mu95ne3q.fsf@nanos.tec.linutronix.de>
In-Reply-To: <87mu95ne3q.fsf@nanos.tec.linutronix.de>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Tue, 3 Mar 2020 14:00:48 +0100
Message-ID: <CACRpkdadbWvsnyrH_+sRha2C0fJU0EFEO9UyO7wHybZT-R1jzA@mail.gmail.com>
Subject: Re: [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO
 Driver with PHC interface changes to support additional H/W Features
To:     Thomas Gleixner <tglx@linutronix.de>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Jonathan Cameron <jic23@kernel.org>
Cc:     "Christopher S. Hall" <christopher.s.hall@intel.com>,
        netdev <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        jacob.e.keller@intel.com,
        Richard Cochran <richardcochran@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Sean V Kelley <sean.v.kelley@intel.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Feb 27, 2020 at 12:06 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> "Christopher S. Hall" <christopher.s.hall@intel.com> writes:

> > Apart from clock import/export applications, timestamping single I/O
> > events are potentially valuable for industrial control applications
> > (e.g. motor position sensing vs. time). As time sync precision
> > requirements for these applications are tightened, standard GPIO
> > timing precision will not be good enough.

If you are using (from userspace) the GPIO character device
and open the events using e.g. tools/gpio/gpio-event-mon.c
you get GPIO events to userspace.

This uses a threaded interrupt with an top half (fastpath)
that timestamps it as the IRQ comes in using
ktime_get_ns(). It's as good as we can get it with just
software and IRQs (I think).

This uses a KFIFO to userspace, same approach as the IIO
subsystem.

> Anyway, the device we are talking about is a GPIO device with inputs and
> outputs plus bells and whistles attached to it.
>
> On the input side this provides a timestamp taken by the hardware when
> the input level changes, i.e. hardware based time stamping instead of
> software based interrupt arrival timestamping. Looks like an obvious
> extension to the GPIO subsystem.

That looks like something I/we would want to support all the way
to userspace so people can do their funny industrial stuff in some
standard manner.

IIO has a config file in sysfs that lets them select the source of the
timestamp like so (drivers/iio/industrialio-core.c):

s64 iio_get_time_ns(const struct iio_dev *indio_dev)
{
        struct timespec64 tp;

        switch (iio_device_get_clock(indio_dev)) {
        case CLOCK_REALTIME:
                return ktime_get_real_ns();
        case CLOCK_MONOTONIC:
                return ktime_get_ns();
        case CLOCK_MONOTONIC_RAW:
                return ktime_get_raw_ns();
        case CLOCK_REALTIME_COARSE:
                return ktime_to_ns(ktime_get_coarse_real());
        case CLOCK_MONOTONIC_COARSE:
                ktime_get_coarse_ts64(&tp);
                return timespec64_to_ns(&tp);
        case CLOCK_BOOTTIME:
                return ktime_get_boottime_ns();
        case CLOCK_TAI:
                return ktime_get_clocktai_ns();
        default:
                BUG();
        }
}

After discussion with Arnd we concluded the only timestamp that
makes sense is ktime_get_ns(). So in GPIO we just use that, all the
userspace I can think of certainly prefers monotonic time.
(If tglx does not agree with that I stand corrected to whatever
he says, I suppose.)

Anyway in GPIO we could also make it configurable for users who
know what they are doing.

HW timestamps would be something more elaborate and
nice CLOCK_HW_SPECIFIC or so. Some of the IIO sensors also
have that, we just don't expose it as of now.

Yours,
Linus Walleij