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