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

[William Breathitt Gray <william.gray@linaro.org>]

[-- Attachment #1: Type: text/plain, Size: 5589 bytes --]

On Sat, Jun 18, 2022 at 01:01:47AM +0000, Hall, Christopher S wrote:
> 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

Hi Christopher,

I'm not familiar with the recent HTE code, so I don't know whether it
can handle arbitrary data values; does the HTE code only track GPIO line
states (whether high or low) with respective timestamps, or can it also
track events count values with a respective timestamps?

Despite the events being triggered by GPIO, it seems from your
description that what you're actually concerned with is getting the
count of "events" and a "timestamp" derived from the ART ticks. If those
two values are what you're trying to handle, then the Counter subsystem
character device should be suitable for your needs:
https://www.kernel.org/doc/html/latest/driver-api/generic-counter.html#counter-character-device

This could be implemented by creating a Counter driver that treats the
events count as its "Count", and the respective ART-derived timestamp as
a its "Count Extension". When an event is triggered, the driver can push
that event to the respective Count character device via a
counter_push_event() call; userspace can add a "Counter Watch" via the
ioctl COUNTER_ADD_WATCH_IOCTL code to watch changes to these two values
(see tools/counter/counter_example.c).

As a side note, the "timestamp" member of struct counter_event serves
more as an event ID for your particular case here because your actual
timestamp is provided by your ART-derived Counter extension component
(whose value can be in terms of system time if you so wish); it'll come
as the "value" member of another struct counter_event following the
struct counter_event containing your events count.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]