Re: [PATCH 1/2] posix clocks: introduce a syscall for clock tuning.

On Thu, Sep 09, 2010 at 03:53:13PM -0700, john stultz wrote:

The only problem there is from the examples, it seems some PTP hardware
can be fairly self-contained. So its a actual ns clock that can be freq
adjusted in hardware, not a constant freq counter that is then converted
to nanoseconds and freq managed in software. So the interface probably
can't be quite as low-level as the clocksource/clockevent structures.

In fact, from the example drivers posted already, it looks like the
k_clock structure maps fairly close to what the hardware uses.

Yes, thats right. The PTP hardware clocks of which I know all follow
the same pattern.

Other clock types that we may want to expose, such as the RTC also can
map fairly close to k_clock. The audio clocks may need some research, as
I suspect they're just a clocksource style counter, so some additional
software cycle->ns layering similar to the timekeeping core (but likely
much simpler) may be needed.

We may also find clocks that are free running counters which can
timestamp network packets. In that case, one would also need software
support to implement rate adjustment. I have not seen that yet among
PTP hardware clocks, so I think we should cross that bridge when we
come to it. In any case, the proposed infrastructure does not exclude
the possibility to support that kind of clock.

So the question to Richard is, what does the above k_clock not provide
that the PTP driver needs?

Yes.

If you've already made some stabs at it,
seeing an example of the generic header and a trivial example driver
that includes the k_clock structure, so we can see what it removed from
your earlier chardev implementation would be helpful.

Okay, it seems that we are gradually coming around to a workable
solution. I will repost the posix clock idea including the PTP clock
drivers, so you all can see how it would fit together.

Thanks,
Richard