Ticket #10827 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

RTC driver for 1.75

Reported by: cjb Owned by: saadia
Priority: normal Milestone: 1.75-software
Component: kernel Version: not specified
Keywords: Cc:
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking: #10893

Description

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.

Change History

  Changed 3 years ago by cjb

  • owner changed from buytenh to saadia

  Changed 3 years ago by saadia

  • status changed from new to assigned

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

  Changed 3 years ago by Quozl

  • blocking 10893 added

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

  Changed 3 years ago by 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.

follow-up: ↓ 7   Changed 3 years ago by 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.

in reply to: ↑ 6   Changed 3 years ago by 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.

  Changed 3 years ago by 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.

  Changed 3 years ago by 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

  Changed 3 years ago by 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.

  Changed 3 years ago by Quozl

#10899 related.

  Changed 3 years ago by Quozl

  • next_action changed from never set to add to build

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

  Changed 2 years ago by Quozl

  • status changed from assigned to closed
  • next_action changed from add to build to no action
  • resolution set to fixed
Note: See TracTickets for help on using tickets.