On Mon, 2008-12-15 at 16:26 +0000, John Stultz wrote:
[cyclecounter/timecounter]

Nice. The cyclecounter struct can work as a good base that I can shift
the clocksource bits over to as I clean that up.

We will probably want to split this out down the road, but for now its
small enough and related enough that I think its fine in the
clocksource.h/c.

Also since Magnus has been working on it, does enable/disable accessors
in the cyclecounter struct make sense for your hardware as well?

I don't think so. The usage model of the cyclecounter is that the
hardware is owned by someone who initializes and controls it, including
enable/disable. The abstract API with the read method is just there so
that common utility code can access the hardware in a uniform way.

For example, the igb driver owns and uses the NIC time register.
Disabling the NIC timer should be done together with disabling the NIC.
This is different from traditional clocksources which are independent
and controlled by the timing subsystem.

Also the corner cases on overflows (how we manage the state, should
reads be deferred for too long) will need to be addressed, but I guess
we can solve that when it becomes an issue. Just to be clear: none of
the hardware you're submitting this round has wrapping issues?

It has 64 bit registers, so there is indeed no wrapping issue.

Otherwise,
Acked-by: John Stultz <johnstul-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Thanks, will add that.

Can you (or someone else) also look at clocksync.[ch]? David wanted to
have that independently reviewed, too, before including it in
netdev-next.


--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html