Re: Intel timed i/o driver in HTE

[Dipen Patel]

On 11/17/22 10:47 AM, N, Pandith wrote:
> Hi Dipen,
> 
> To support Intel timed i/o driver, it was suggested by Linux community to enhance hte framework.
> However, we see some limitations to support complete Intel timed i/o device.
> 
> 1. The current framework supports Nvidia IP, which has two IP blocks (hw timestamping engine interfaced with GPIO)
> Intel timed i/o is a single IP block handling multiple functionalities like:
> 
> 	a. Input timestamping with event counter.
> 	b. Timed output  - single shot or periodic pulse train.
> 	Uses TSC(Timestamp counter) for timestamp or generate events, which could be translated to system time.
> 	c. Implement PPS functionality to export time.
Isn't 1c similar to 1b, where IO (mostly GPIO) is programmed to toggle/periodic pulse train at 1s.
> 
> This requires new functionality(interface) to be developed in hte framework specific to timed-io device.
I can see 1a is straight case for the HTE.

For 1b, the timestamp part can be added as hte provider. I see opportunity to enhance hte framework to provide
translation facility between the domain, system time in this case. However programming interface to facilitate
timed IO output can not fit into HTE the way it is right now. May be one possible way is to enchance HTE with API something like
hte_configure_timestamp_periodic/timed could be possible in which case HTE does something more than just timestamping the event.

I have to see how in GPIO case that proposed API works out, if it will bypass gpio framework etc...

Adding Linus W into the discussion....

> 
> 2. The current hte framework has a provider and consumer concept.
> Consumer is responsible for user space interaction.
> Currently Nvidia is using GPIO for input timestamping  (by adding hw timestamps in gpiolib-cdev.c)
> 
> For Intel timed i/o functionalities, current gpio user interfaces cannot support event counter
> or output modes.
Can you elaborate on event counter and output mode?

> Rather than jigging hte consumer into other subsystems to support timed i/o device. 
> Any possibility of developing a native consumer in hte subsystem, which could handle user space interactions for timestamping engines.
yes, feel free to send patches to me and cc timestamp@xxxxxxxxxxxxxxx, I guess you can register your IP as one of the provider.

To explain why GPIO was treated specially, there was already a
user facing framework i,e gpio-cdev and range of userspace tools which could be leveraged for the HTE GPIO consumers. However this does
not prevent kernel space GPIO HTE consumer from using HTE core directly.
 
> 
> I cannot think of an existing subsystem that handles Intel timed i/o functionalities 1a, 1b and 1c (mentioned above).
> 
> Regards,
> Pandith
> 
> 
> 
> 
Best Regards,
Dipen Patel