> On Nov 29, 2019, at 10:14, Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> wrote: > >> 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! >> > > According to this link, bit 24 is Crystal Enable which I would think > would also enable the RTC. Yes, my bad. > >>> >>> 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. > > Yes, this is exactly what should be done. leave the RTC in PON state > until userspace sets the time. Until then, -EINVAL must be returned by > .read_time. Mathieu Gallichand pointed out, from ug1085: IMPORTANT: The control register must be programmed every time the LPD is powered on. Otherwise, the value returned by reading the control register can be different from the actual control settings stored in the BPD. So according to this, reading the control register to get bit 31 status is not a recommended way to determine whether current_time is valid or not.
