Re: [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO Driver with PHC interface changes to support additional H/W Features

["Christopher S. Hall" <christopher.s.hall@intel.com>]

Thanks for reviewing.

On Fri, Jan 31, 2020 at 07:14:49PM +0100, Thomas Gleixner wrote:
> christopher.s.hall@intel.com writes:
> > From: Christopher Hall <christopher.s.hall@intel.com>
> >
> > The TGPIO hardware doesn't implement interrupts. For TGPIO input, the
> > output edge-timestamp API is re-used to implement a user-space polling
> > interface. For periodic input (e.g. PPS) this is fairly efficient,
> > requiring only a marginally faster poll rate than the input event
> > frequency.
> 
> I really have a hard time to understand why this is implemented as part
> of PTP while you talk about PPS at the same time.

We primarily need support for periodic input and output uses cases.
Apologies for omitting the periodic output use case from the cover
letter. While TGPIO isn't associated with a PTP timestamp clock, the PHC
pin/clock interface fits the usage otherwise.

The PHC periodic output API is the closest fit for periodic output without
creating a new API. The PHC interface can also register as a PPS source. I
am, however, concerned in general about implementing PPS input in the
driver because the hardware doesn't implement interrupts - requiring
polling.

> Proper information about why this approach was chosen and what that
> magic device is used for would be really helpful.

The customer requested usages are 1 kHz and 1 Hz for both input and
output. Some higher level use cases are:
- using a GPS PPS signal to sync the system clock
- auditing timesync precision for financial services, especially high
	frequency trading (e.g. MiFID).

Apart from clock import/export applications, timestamping single I/O
events are potentially valuable for industrial control applications
(e.g. motor position sensing vs. time). As time sync precision
requirements for these applications are tightened, standard GPIO
timing precision will not be good enough.

> Thanks,
> 
>         tglx

Thanks,
Christopher