N, Pandith <pandith.n@xxxxxxxxx> 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
