RE: Intel timed i/o driver in HTE

[N, Pandith]

> -----Original Message-----
> From: Dipen Patel <dipenp@xxxxxxxxxx>
> Sent: Saturday, November 19, 2022 8:04 AM
> To: N, Pandith <pandith.n@xxxxxxxxx>; linus.walleij@xxxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx; Hall, Christopher S
> <christopher.s.hall@xxxxxxxxx>; Gross, Mark <mark.gross@xxxxxxxxx>;
> Sangannavar, Mallikarjunappa <mallikarjunappa.sangannavar@xxxxxxxxx>;
> D, Lakshmi Sowjanya <lakshmi.sowjanya.d@xxxxxxxxx>; T R, Thejesh Reddy
> <thejesh.reddy.t.r@xxxxxxxxx>; andriy.shevchenko@xxxxxxxxxxxxxxx;
> timestamp@xxxxxxxxxxxxxxx; dipenp@xxxxxxxxxx
> Subject: Re: Intel timed i/o driver in HTE
> 
> 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.
> >
Yes, Functionally they are quite similar. 1c is relatively slow where each event is scheduled by the driver to be aligned the system clock.
1b is relatively fast (in periodic mode). we are checking to support this is in a single interface.

> > 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.
Yes, current interfaces can support input mode. Since few Intel timed i/o devices do not have interrupt support.
There is a need to enhance current framework, to support polling mode.
> 
> 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.
This is the possibility we wanted to check, to accommodate different output modes.
Something like hte_configure_timestamp or hte_request_pulse.
> 
> 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?
In 1a, event counter holds the input trigger count on configured pin.
Output mode is case 1b and 1c.
> 
> > 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.
> 
This native hte consumer is also intended to handle ioctl based user space interaction.
Use the services of enhanced hte provider (with a new char device type creation).

> 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.
> 
Since the current gpio framework is inadequate to periodic output modes.
I thought to disentangle from gpio and develop a new hte consumer. Something like hte-libcdev.c  

> >
> > 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