I want to propose a few more changes to the todr interface "driver
interface" (struct todr_chip_handle), and I'd like to get opinions:


    * change instances of struct timeval to struct timespec

        this makes everything a bit more consistent, and removes an
        extra copy in the kernel.  we seem to be moving away from struct
        timeval in the kernel anyway

    * add todr_settime_ymdhms and todr_gettime_ymdhms

        a lot of clock chips store time as a full date (year, month,
        day, hour, min, sec).  we have a lot of duplicated code to do
        the conversion back and forth.  additionally, some of the
        drivers check for things like year rollover (2038), etc.  but
        some do not.  this could should be centralized.  a driver can
        then choose whether it prefers to work with a struct timespec,
        or a struct clock_ymdhms.

    * add todr_flags

        primarily I want to add a new flag, TODR_USE_LOCALTIME, that
        indicates that the clock chip stores time in the local timezone,
        rather than using a GMT offset.  essentially, this will allow
        the common code to apply the rtc_offset adjustments on behalf of
        the rtc chip.

    * add todr_offset

        this is the offset in seconds that the rtc stores time in.  a
        lot of chips store time using some number of seconds since a
        previous date, but different platforms (and in a many cases,
        different ports using the same rtc chip) use a different value
        for the start of time.  again, the idea here is to move this
        handling into the common code.


For everyone who has asked, "TODR" is believed to be an acronym for
"time-of-day register" possibly from VAX heritage.  (If I had been
designing this interface, I would have used "rtc" rather than todr, but
the interface exists and there isn't a compelling reason to change it.)

If I don't hear any objections, I'll probably go ahead and start making
these changes.  Btw, all of these changes /except/ the conversion of
struct timeval to struct timespec are automatically backwards compatible
-- i.e. they won't break clocks that aren't converted.  so they don't
force another massive rototill.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191