Re: Intel timed i/o driver in HTE

[Linus Walleij]

Hi Christopher!

thanks for the lengthy explanation, I think I get it now.

As usual I have now a slight impostor syndrome for now knowing
what PPS is and what it is for despite it has its own subsystem
and all.

On Thu, Dec 8, 2022 at 5:52 AM Hall, Christopher S
<christopher.s.hall@xxxxxxxxx> wrote:

> For PPS input, we plan to use the PPS subsystem.

Why are you not planning to use the PPS "generators" for output?

> The application configures the pin for PPS input
> A device in created /dev/ppsX
> while 1:
>         The timed I/O device captures / timestamps a pulse from an
>                 external PPS provider
>         The timestamp is translated to system time(TN)
>         A PPS event is generated using pps_event(TN
>
> Another application like PHC2SYS or Chrony consumes the timestamps from
> the PPS device and disciplines the system clock.

This is great and to the point.

> Currently, most - maybe all - PPS clients (drivers/pps/clients) capture
> timestamps in software (pps_get_ts()). We can do at least 50x better
> timestamping using hardware. The timestamp accuracy is in the range of
> a few 10s of nanoseconds. I think this is a good thing.

So the plan is to let a driver in drivers/pps obtain a timed IO input
from the HTE subsystem with high resution, which is great.

> Again we provided an example application. Let's not get "hung up" on GPS.
> There are many GPS receivers that produce a PPS output.

OK I'm sorry for being so stubborn with that example.

> If I may, I would like to re-focus the discussion. The question we want
> to answer in this thread is whether it makes sense to modify the HTE
> subsystem to accommodate our device and whether it "belongs" there.

Yeah I agree.

> To summarize this and previous threads the Timed IO use case is
> importing and exporting system time with about nanosecond precision.

Yeah I think that point has not been the main focus actually:
maybe I'm especially dumb but it looked to me as posed for
"random events" in and "random pulsetrains" out. But in this
context it makes much more sense.

> We also want to be able to timestamp / generate single events.
> Existing HTE already do the first.
>
> Are these use cases that you are willing to support in the HTE
> subsystem? We seem to be unable to dig into the implementation
> without circling back to the use cases which I believe are
> clearly defined.

Sorry for the misunderstandings. This is really Dipen's decision.

If you ask me, it seems like you should begin with making a
PPS input using the HTE as back-end, then think about the next
thing.

If this *makes* *sense*, and is not over-generalizing the
timed input. I.e. if you expect people to be using it for some
random other line sampling unrelated to PPS. There is no
point in putting it into drivers/hte for random abstraction.

Otherwise by all means put the whole thing into drivers/pps
why not? If that is what it is for?

This *could* be one of those cases where the subsystem is not
a clear cut, and that does not matter because we are not especially
OCD about pigeon-holeing hardware into one subsystem and
one subsystem only.

Perhaps the output mode should just go into drivers/pps/generators
without any HTE back-end while the input mode uses
HTE?

The fact that this is one single HW block doesn't really matter
as long as you can share the hw access using something like
MFD or regmap in worst case.

Yours,
Linus Walleij