RE: Intel Timed-IO driver in IIO/Counter subsystem

["Hall, Christopher S" <christopher.s.hall@intel.com>]

N, Pandith <pandith.n@intel.com> wrote:
> Hi,
> 
> We have a Intel Timed IO peripheral with following functionalities :
> 
> 1. Event capture capability - Captures event count and timestamp.

An event is an edge on the input or output signal. Rising, falling,
or both edges can be selected for counting / timestamping. The
timestamp and count are captured synchronously.

If, for example, the hardware is configured to capture both types of
input edges, each input edge causes the count to increment by one and
the ART value (see below) to be captured atomically.

To see how this may be useful, consider the case where two event
occur before software is able to read the first. A count delta of >1
indicates that an event timestamp was missed.

For another example: If the input signal is periodic, the frequency
offset between the input clock and the local clock can be computed:

 (delta ART / delta count) * (nom. input freq / 1e9 ns) *
	(1e9 / ART frequency)

It is not necessary to read each event to determine the average
frequency for multiple events.

> 2. Pulse generation - periodic or single event generation.
> 3. Return cross-timestamp on request.

This may imply that the Timed I/O logic is driven by a separate device clock.
It is not. It is driven by the platform clock - the Always Running
Timer (ART). ART is directly related to the CPU timestamp counter (TSC).
ART and TSC can be converted to one another using the following equation:

TSC_Value = (ART_Value * CPUID.15H:EBX[31:0] )/ CPUID.15H:EAX[31:0] + K

ART ticks at the core crystal frequency. Typically this is 38.4 MHz. The
frequency can be discovered by reading CPUID.15H:ECX[31:0].

More information can be found in the Intel Software Developer's
Manual (SDM) in the Invariant Timekeeping section
17.17.4 and Determining the Processor Base Frequency section 18.7.3
(https://cdrdv2.intel.com/v1/dl/getContent/671200)

K is typically zero. A virtualized guest is an example where K != 0. In
this case, K is offset by the value of the VMCS TSC offset.

An example of how ART can be directly converted to system time is in the
e1000e driver:

drivers/net/ethernet/intel/e1000e/ptp.c:e1000e_phc_getcrosststamp()

using the following functions:

- arch/x86/kernel/tsc.c:convert_art_to_tsc() [ART->TSC]
- kernel/time/timekeeping.c:get_device_system_crosststamp() [TSC->System Time]

These are dependent upon TSC being selected as the clocksource. The
attempted conversion results in an error otherwise.

A PHC driver implementation of Timed I/O was proposed:
- https://lkml.org/lkml/2020/1/31/25

that included a cross-timestamp function. This crosstimestamp - in the sense
of determining the relationship between two independent clocks - is a
software fiction because system time is based on ART. The cross-timestamp
value enabled conversion of an event timestamp from ART -> System Time in
the application in the usual way when using the PHC API.

In my opinion, given a (more) greenfield API implementation. ART timestamps
should not be exposed at the application level at all. All timestamps
returned to the application should be in terms of system time.

There is a chapter (21.3.5) in the Atom(r) x6000E datasheet for Timed I/O:

https://cdrdv2.intel.com/v1/dl/getContent/636112?explicitVersion=true&wapkw=EHL%20datasheet

Note that the hardware function is called TGPIO.

There is also Timed I/O example code using the PHC driver referenced above:

https://www.intel.com/content/www/us/en/develop/documentation/tcc-tools-2021-2-developer-guide/top/time-synchronization-and-communication-tools/time-aware-gpio-tgpio-samples.html

Thanks,
Christopher