Tested on with the RK808-D on a rk3399 board.
Details
Details
- Reviewers
manu andrew - Group Reviewers
arm64 - Commits
- rG292bcaa4ba28: arm64: Add support for the RK805/RK808 RTC
rG07564e176201: arm64: Add support for the RK805/RK808 RTC
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
LGTM, only need to force 24 hours mode just in case.
| sys/arm64/rockchip/rk805.c | ||
|---|---|---|
| 515 | I think that we should force 24 hours mode here in case some other OS uses it and the user booted it before booting FreeBSD. | |
| sys/arm64/rockchip/rk805.c | ||
|---|---|---|
| 516 | Typo 'RRK' | |
| sys/arm64/rockchip/rk805.c | ||
|---|---|---|
| 518 | Does this sequence of CTRL_STOP being set/cleared cause the rtc's internal sub-second counters to reset to zero? If so, then after registering the clock in the attach code, you should call clock_schedule(dev, 1), so that rk805_settime() is scheduled to run right after top-of-second so that the rtc's internal phase matches the kernel clock's phase. Some rtc chips restart their counters at the halfway point (.5 sec), in which case you should use something like clock_schedule(dev, 500000000). | |
Comment Actions
Most boards don't have a battery connected. What happens in this case? I don't see any validity detection in this code
Comment Actions
There are 2 obvious options for validity detection:
- Bit 7 of RTC_STATUS_REG is set on a reset. That could be read in rk805_gettime() (and cleared in rk805_settime()).
- According to the datasheets, the RK805 resets to Monday, [20]13-01-21 0850 and the RK808 resets to Thursday, [20]16-01-21 0850. Since those dates predate support for these devices, a date sanity check could be used - eg if the year reads as less than [20]19 then the clock isn't valid. This won't any special code to clear the "clock invalid" state because just setting the clock to a sane time will pass that test.
Presumably any board that will accept a battery will have a crystal installed (rather than using the RC fallback that exists in at least the RK805). Detecting that the RTC is not running correctly is a significantly harder task than simply detecting that the time looks sane.
| sys/arm64/rockchip/rk805.c | ||
|---|---|---|
| 466 | This code assumes that the RTC is configured for direct access to the dynamic time registers (which might imply that there's a race condition reading the time - the datasheets don't mention one way or the other). Since this function is (normally) only called once on boot (from inittodr()), it would seem preferable to transfer the time to the static shadow registers and read them (this requires an additional 1 I2C read and 3 writes). | |
| 515 | Actually, the calls to clock_bcd_to_ts() and clock_ts_to_bcd() both assume that the RTC is running in 12h mode. That said, I agree that the code should force the RTC mode to match the time format. | |
| 518 | Unfortunately, the neither the RK805 nor RK808 datasheets that I've found on the web document this. I suspect it will need experimentation. | |
| sys/arm64/rockchip/rk805reg.h | ||
| 34 | There should probably be a comment that states:
| |
Comment Actions
Since I don't seem to be able to update the patch here, I've created D29140 as a replacement that addresses all the comments above.
Comment Actions
There hasn't been any response by andrew to previous comments and I have a revised patch.
Comment Actions
Updated to account for previous comments:
- Force the RK805/808 into 24hr mode and adapt the code to assume 24hr mode
- When reading, transfer the time into the shadow registers and read them, rather than reading the live registers.
- If the year is read from the RTC is prior to [20]19, assume the time is invalid. This accounts for the reset date in either the RK805 or RK808
- Report the time written to or read from the RTC in bootverbose mode.
- Document that the RTC registers are the same on both the RK805 and RK808
- Document that the code assumes the RTC registers start from 0.
Based on experiments on my RK808, setting the time doesn't alter the internal/inaccessible sub-second counter, therefore there's no point in calling clock_schedule().