RTC driver for 1.75

[cjb]

The part's an IDT1338, and is sitting on TWSI2. Datasheet's at http://www.idt.com/products/getDoc.cfm?docID=18711422. The datasheet (page 9) says that the I2C addresses are 0xd0/0xd1.

[cjb]

Oh, and Mitch has a driver:

http://tracker.coreboot.org/trac/openfirmware/browser/cpu/arm/olpc/1.75/rtc.fth

[saadia]

I submitted a patch to devel and pushed it to the kernel tree.

[Quozl]

(In #10893) runin-sus needs RTC support for rtcwake.

[Quozl]

Saadia, is this ready for testing on os9? I'm seeing strange results, but I don't want to write them up if it isn't time to do so.

[saadia]

This should have been working in os9. I just saw the following behavior: Downloaded os9, set RTC using hwclock --set --date . Confirmed time set with hwclock. Rebooted, and time was Jan 1, 00:00. Rebooted again, repeat setting time, reboot and back to 00:00 time. Set time once more using hwclock, boot to OFW, examine time using select /rtc, get-time. Time is correct. Boot fully to Linux, and correct time is appearing now. From here on, correct time is retained over reboots, so I can't reproduce the problem. There seems to be some kind of initial state after loading the os9 build that is causing the clock to reset. I did not see this behavior in my development build. Quozl, please let me know if you see the same behavior.

[Quozl]

Replying to saadia:

Downloaded os9, set RTC using hwclock --set --date . Confirmed time set with hwclock. Rebooted, and time was Jan 1, 00:00. Rebooted again, repeat setting time, reboot and back to 00:00 time.

Reproduced as described. The time is reset by the reboot. I presume either the system reset or the firmware is the cause of the reset of the time.

Set time once more using hwclock, boot to OFW, examine time using select /rtc, get-time. Time is correct.

Does not reproduce here. Tried several times. Time is incorrect; stack after get-time shows 10 0 0 1 1 64, .clock shows 0100-01-01 00:00:16 UTC.

Boot fully to Linux, and correct time is appearing now.

The different result you got is concerning. I wonder if it depends on when the reboot happens in relation to the clock value. Can you tell me how you rebooted to OFW? Or it might depend on when I test in relation to UTC.

There seems to be some kind of initial state after loading the os9 build that is causing the clock to reset.

Yes, I agree. My gut feel is OpenFirmware startup.

I wonder it it might relate to #10989, where OpenFirmware doesn't seem to get consistent results either.

[Quozl]

My A3 unit is losing RTC oscillator over power cycle, this is tracked at #10999, and is the cause of my failure to keep time reported here on #10827. On my A3, doing a reboot in Linux causes #10999, but a reboot in OpenFirmware does not cause it. Different mechanisms used. That it works differently for you suggests a race of some sort. You may wish to report the OSF in your driver to assist with debugging. I'm interested to know if your unit also exhibits #10999, exclusive of Linux.

OpenFirmware startup was corrupting the century portion of the RTC, this was fixed in #10989. There should be no effect of this on Linux, since your driver does not read relative byte 8. I've tested that by manually corrupting the value and then booting Linux on my A2 unit ... the time set by Linux is kept over the reboot.

So all in all, no problems with your driver, everything I've found has been OpenFirmware or something at hardware level.

[Quozl]

runin-sus expects rtcwake support. rtcwake fails with

/sys/class/rtc/rtc0/device/power/wakeup: No such file or directory
rtcwake: /dev/rtc0 not enabled for wakeup events

[Quozl]

Runin relies on rtcwake for scheduling a short suspend cycle, and runs multiple cycles during the test run. Runin inability to suspend and resume was added 15th August by Quanta as SW issue 10 to be completed before C-stage.

[Quozl]

#10899 related.

[Quozl]

Testing with 3.0.0_xo1.75-20111011.1503.olpc.9d437c5, working well.