Linux/AM3352: Device tree settings for TPS65910 RTC

I just noticed the error hctosys: unable to open rtc device (rtc0)

I would like to see tps6910-rtc loaded earlier as rtc0 so hctosys can use it. I assumed that would be accomplished by the device tree. If that isn't the I need to have hctosys load after tps65910-rtc. That would load the system time from the PMIC rtc at boot, correct?

Thanks that is useful for setting the load order of the rtc.

I think there still may be an issue with the device tree. When I try to set the tps65910-rtc hw clock from system time the command hangs.

# dmesg | grep 'as rtc'
[ 3.501557] tps65910-rtc tps65910-rtc: rtc core: registered tps65910-rtc as rtc0
[ 6.371448] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc1

# date --set="27 JAN 2018 10:09"
Sat Jan 27 10:09:00 UTC 2018
# hwclock -f /dev/rtc1 -w
# cat /sys/class/rtc/rtc1/time
10:09:24
# hwclock -f /dev/rtc0 -w <--------------------- this command hangs
^C
# cat /sys/class/rtc/rtc0/time
01:08:29


Here is the tree node for the TPS65910:
&tps {
reg = <0x2d>;
interrupt-parent = <&intc>;
interrupts = < 0 118 0x04 >;

#gpio-cells = <2>;
gpio-controller;

#interrupt-cells = <2>;
interrupt-controller;

ti,en-ck32k-xtal;

vcc1-supply = <&vbat>;
vcc2-supply = <&vbat>;
vcc3-supply = <&vbat>;
vcc4-supply = <&vbat>;
vcc5-supply = <&vbat>;
vcc6-supply = <&vbat>;
vcc7-supply = <&vbat>;
vccio-supply = <&vbat>;

regulators {
vrtc_reg: regulator@0 {
regulator-always-on;
};

vio_reg: regulator@1 {
regulator-name = "vio,vdds_ddr";
regulator-always-on;
};

vdd1_reg: regulator@2 {
/* VDD_MPU voltage limits 0.95V - 1.325V with +/-4% tolerance */
regulator-name = "vdd_mpu,vdd1";
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <1378000>;
regulator-boot-on;
regulator-always-on;
};

vdd2_reg: regulator@3 {
/* VDD_CORE voltage limits 1.056V - 1.144V with +/-4% tolerance */
regulator-name = "vdd_core";
regulator-min-microvolt = <1056000>;
regulator-max-microvolt = <1144000>;
regulator-boot-on;
regulator-always-on;
};

vdd3_reg: regulator@4 {
regulator-always-off;
};

vdig1_reg: regulator@5 {
regulator-always-on;
};

vdig2_reg: regulator@6 {
regulator-always-on;
};

vpll_reg: regulator@7 {
regulator-always-on;
};

vdac_reg: regulator@8 {
regulator-always-on;
};

vaux1_reg: regulator@9 {
regulator-always-on;
};

vaux2_reg: regulator@10 {
regulator-always-on;
};

vaux33_reg: regulator@11 {
regulator-always-on;
};

vmmc_reg: regulator@12 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
};
};

I found that the command that I said hangs was just very slow to complete. It takes almost 10 seconds to set the tps65910-rtc hw clock while the omap_rtc hw clock is set in less than a second.

[ 3.049489] tps65910-rtc tps65910-rtc: rtc core: registered tps65910-rtc as rtc0
[ 6.403069] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc1

# cat /sys/class/rtc/rtc0/time
11:41:56
# date --set="27 JAN 2018 11:11"
Sat Jan 27 11:11:00 UTC 2018
# hwclock -f /dev/rtc1 -w # This takes about a second to complete
# cat /sys/class/rtc/rtc1/time
11:11:16
# cat /sys/class/rtc/rtc0/time
11:42:33
# hwclock -f /dev/rtc0 -w # This takes 10 seconds to complete
# cat /sys/class/rtc/rtc0/time
11:11:51

Is there a problem or should the PMIC i2c communication cause it to take so long?

I was able to eliminate the error with time hctosys:

hctosys: unable to open rtc device (rtc0) 

I saw the error when the rtc driver was a loadable module, I configured the rtc driver as a built-in kernel module instead and it loaded earlier in the boot process.  I could not find a way to delay the time synchronization instead.

I have this working with omap_rtc as rtc0.  Now the time looks correct after powering up the board.  I'm still working to control the order the drivers are loaded.

Are you still having any problems? If not we can close this.

Steve K.

Code changes were merged into the next release which is being tested, I'm waiting for the results from the product test engineer. Please do not close yet.

Hi Aaron,
Any results for the test engineer?

Steve K.