Bonjour Alexandre! > On Nov 28, 2019, at 12:29, Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> wrote: > >> Then we enable the RTC: >> >> xsct% rwr rtc control 0x81000000 >> > > Doesn't that enable battery switchover instead of simply enabling the > rtc, I though you didn't have a battery. In our tests, psbatt present only means that the RTC preserves it's state and registers when the platform is powered off. Before toggling bit 31, the counter (current_time) doesn't move despite the platform being on (psbatt present or not). This indicates that effectively, the bit turns on the RTC. > > Or does that mean that your previous read of control returning bit 24 > set is also bogus? https://www.xilinx.com/html_docs/registers/ug1087/rtc___control.html# Bits 30:28 are reserved, and not 0x0 as this reference page suggests, so who knows what the bits mean... well someone at Xilinx knows! > > I ask because the simpler solution would simply to return -EINVAL in > xlnx_rtc_read_time when you detect a power on condition. That could also work, but how would we determine that? Oh, perhaps by looking at the Battery_Enable (31) bit. But then we would need to keep it disabled during probe so that the time_read could test the bit to see if current_time is valid, and then after this, when would we enable it? Perhaps at the first call to set_time_write? This is all interesting but for now we have run out of time to investigate further. Unless someone comes up with a ready made alternative solution, we here are actually going to go into production with our patch. It works well. Cheers!
