On Mon, 2008-12-15 at 15:54 +0100, Patrick Ohly wrote:> So far struct clocksource acted as the interface between time/timekeeping.c> and hardware. This patch generalizes the concept so that a similar> interface can also be used in other contexts. For that it introduces> new structures and related functions *without* touching the existing> struct clocksource.> > The reasons for adding these new structures to clocksource.[ch] are> * the APIs are clearly related> * struct clocksource could be cleaned up to use the new structs> * avoids proliferation of files with similar names (timesource.h?> timecounter.h?)> > As outlined in the discussion with John Stultz, this patch adds> * struct cyclecounter: stateless API to hardware which counts clock cycles> * struct timecounter: stateful utility code built on a cyclecounter which> provides a nanosecond counter> * only the function to read the nanosecond counter; deltas are used internally> and not exposed to users of timecounter> > The code does no locking of the shared state. It must be called at least> as often as the cycle counter wraps around to detect these wrap arounds.> Both is the responsibility of the timecounter user.> > Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>

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

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

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

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