rtc-hi35xx: bench-validate on board with populated 32.768 kHz crystal before mainline submission

[widgetii]

Context

New driver drivers/rtc/rtc-hi35xx.c was developed and integrated into the OpenIPC Linux 7.0 tree (branch fix/cv500-add-pl022-spi-nodes work, not yet committed). It covers the indirect-access RTC IP on the Hi35xx camera SoC family (Hi3516EV200/EV300, Hi3518EV300, Hi3516DV200, Hi3516CV500, Hi3516DV300, Hi3556V200, Hi3559V200). DT compatible: hisilicon,hi35xx-rtc.

What's validated

On a variant-1 OpenIPC rack-pod prototype board (Hi3516EV300, no RTC crystal / no RTC backup battery populated):

• Driver probes cleanly and registers as rtc0.
• cat /sys/class/rtc/rtc0/{date,time} returns valid values.
• hwclock -r and RTC_RD_TIME ioctl return valid values.
• hwclock -w / RTC_SET_TIME returns success and value is observable on subsequent read.
• No error spam in dmesg under normal operation.
• Alarm ops registered, device_init_wakeup() + dev_pm_set_wake_irq() wired.

What's NOT validated (this issue)

Because the test board has no 32.768 kHz RTC crystal physically populated, the RTC counter has no time-base and does not tick. The driver can store and retrieve values but cannot exercise:

1. Counter advance across reads (time-of-day actually progressing).
2. Subsecond / settle-time tolerances on snapshot reads (LOCK auto-clear behaviour).
3. Alarm match firing the wakeup interrupt.
4. Suspend-to-RAM wake via RTC alarm (the eventual goal — see the PM-port architecture doc).

What to test once a crystal-equipped board is available

Run on any Hi3516xV/Hi3518EV300/Hi3516DV200 board where the schematic shows an external 32.768 kHz crystal on the RTC_XIN/RTC_XOUT pins (most reference designs from HiSilicon do; many cheap derivatives strip it).

• cat /sys/class/rtc/rtc0/time returns a value that changes between calls 1 second apart.
• hwclock --set --date='now'; sleep 30; hwclock -r returns now + 30 s within ±1 s.
• echo \$((\$(date +%s)+60)) > /sys/class/rtc/rtc0/wakealarm; sleep 70; cat /proc/interrupts | grep -i rtc shows the alarm IRQ fired exactly once.
• Suspend-to-RAM (or its equivalent on whatever PM infrastructure exists) wakes from RTC alarm.
• Power-cycle the board with an RTC battery — time persists across boot.

Two hardware-related quirks observed on the no-crystal board that should be re-checked once there's a real time-base — these may simply disappear:

1. LORD register's LOCK bit auto-clear: vendor reference polls LORD waiting for the LOCK bit to clear after writing a snapshot trigger. On the no-crystal board this took anywhere from instant to never-clearing-within-1-second. Driver currently substitutes a fixed 20 ms sleep instead of polling. With a real time-base running, polling may work as vendor intended.
2. LORD register's LOAD bit auto-clear: same shape, driver uses 100 ms fixed sleep after writing LOAD.

If the polling-for-auto-clear works cleanly on a crystal-equipped board, restore vendor's polling pattern and remove the fixed sleeps.

Files (not yet committed)

• drivers/rtc/rtc-hi35xx.c (new, ~400 lines)
• drivers/rtc/Kconfig (add RTC_DRV_HI35XX entry, depends on ARCH_HISI || ARCH_HISI_BVT || COMPILE_TEST and OF)
• drivers/rtc/Makefile (add obj-\$(CONFIG_RTC_DRV_HI35XX) += rtc-hi35xx.o)
• Documentation/devicetree/bindings/rtc/hisilicon,hi35xx-rtc.yaml (DT binding)
• arch/arm/boot/dts/hisilicon/hi3516ev300-demb.dts (add &rtc { wakeup-source; };)

In openipc/firmware:

• br-ext-chip-hisilicon/board/hi3516ev200/hi3516ev300.neo.config: add CONFIG_RTC_DRV_HI35XX=y.