Re: [PATCH] ARM: dts: imx6qdl-hummingboard: Add rtc0 and rtc1 aliases to fix hctosys

[Russell King (Oracle)]

On Fri, Jan 19, 2024 at 01:46:26PM +0000, Josua Mayer wrote:
> Am 19.01.24 um 13:07 schrieb Josua Mayer:
> > Am 18.01.24 um 17:07 schrieb Russell King (Oracle):
> >> On Thu, Jan 18, 2024 at 04:01:10PM +0100, Josua Mayer wrote:
> >>> HummingBoard has two RTCs, first integrated within SoC that can be used to
> >>> wake up from sleep - and a second on the carrier board including back-up
> >>> battery which is intended for keeping time during power-off.
> >>>
> >>> Add aliases for both, ensuring that the battery-backed clock is primary
> >>> rtc and used by default during boot for restoring system time.
> >> Given that the snvs RTC isn't battery backed, should we even be enabling
> >> that in DT?
> > In imx6qdl.dtsi it is not disabled.
> > According to Jon it is useful because it can wake up the soc from sleep,
> > whereas the external rtc can't.
> >> Also, have you seen any issues such as:
> >>
> >> [    0.933249] rtc-pcf8523 0-0068: failed to set xtal load capacitance: -11
> >> [    0.933505] rtc-pcf8523: probe of 0-0068 failed with error -11
> >>
> >> which seems to be exhibiting itself on my SolidSense board?
> > Not on my HummingBoard Gate Rev. 1.4., but indeed on my solidsense
> > unit too, which is probably same age as yours.
> > Only tested imx6dl-hummingboard2-emmc-som-v15.dtb,
> > but solidsense one should make no difference.
> 
> I was reading control registers 1-3:
> debian@sr-imx6:~$ sudo i2cget -y -a -f 0 0x68 0x00
> 0x00
> debian@sr-imx6:~$ sudo i2cget -y -a -f 0 0x68 0x01
> 0x00
> debian@sr-imx6:~$ sudo i2cget -y -a -f 0 0x68 0x02
> 0x04
> 
> ^^ This means low voltage on back up battery

Interesting - in my case, the solidsense has been powered on for months
(it's my internet router on the boat).

I've rebooted it again today, and this time it seems to have been
successful, and is using the time from it.

> After a few power-cycles that error went away.
> Why pcf8523_load_capacitance would ever return EAGAIN I don't see.
> 
> In any case now that probe succeeded, I read these values:
> 0x80
> 0x00
> 0x04

For me, after the last reboot, they contain:
0x80
0x00
0x08

> Long story short I don't think the EAGAIN during probe is related
> to adding aliases.
> HOWEVER imo pcf8523_probe should return an error when
> pcf8523_load_capacitance fails.

I think the real question is where is the EAGAIN coming from and
why.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!