On 05/15/2015 17:13, Maciej W. Rozycki wrote: > On Fri, 15 May 2015, Paul Burton wrote: > >>>> I'd prefer RTC state not to be touched at all if its state is sane. >>>> That is read Register B, check for the only valid divider setting >>>> (32kHz), and if so then exit right away, and otherwise initialise the >>>> chip from scratch. Consistency with YAMON might be a good idea in that >>>> initialisation, but I have no strong feeling towards that. If you think >>>> there's value in having the chip set to the BCD mode, then feel free to >>>> keep that option. >>>> >>>> Note that any inhibition of the RTC previously initialised by >>>> temporarily setting the SET bit in Register B during bootstrap will >>>> disturb timekeeping that the system may carry over reset using >>>> adjtimex(8). >>> >>> So you're instead suggesting to revoke a87ea88d8f6c ? > > No, now that I have the full picture -- everyone, please try to include > as much details with our commit messages as required for the reader to be > able to have a full understanding of the reasons behind the change without > having to guess or ask around. You may not be around in a few years' > time, having moved on with your career or interests, or suchlike, and > people will have to cope without your assistance. It's OK to give these > messages a meaning, they are not GNU ChangeLogs! Maybe not in the commit message for rtc-ds1685, but a good chunk of that driver is comments. I found one of the most frustrating things in working on that driver to be not understanding what other RTC drivers were doing because no one else commented their code clearly. Hopefully, if someone winds up in the same position I was in, they'll be able to understand quicker what rtc-ds1685 does and maybe use some of its code in their setup. >>> If YAMON and U-Boot are differing in RTC handling then I suggest to >>> treat that as a U-Boot bug. YAMON was there first. > > And that is a grand first, 15+ years! > >> That would be fair enough, and is why I added RTC handling to Malta >> U-boot at all. I could see logic in suggesting U-boot be changed to use >> the binary mode instead of BCD. But... > > I find it a shame BTW that the handling of RTC has fallen so bad recently > across various platforms. Here you shouldn't have been required to do > anything beyond enabling the right RTC driver (the Motorola clone has been > so ubiquitous that a driver must have been done eons ago), defining its > mapping on the bus (again 0x70/0x71 in the PCI I/O space is the vastly > most common arrangement) and maybe setting some configuration flags for > the mode (binary vs BCD and the like). SGI O2 and SGI Octane both use the same RTC, a DS1687-5. But with the O2, the ARCS PROM forces the RTC to BCD on startup, while the Octane's ARCS PROM forces it to binary on startup. And if the Octane's PROM discovers the RTC is in BCD mode, it resets it to 1969. That really confused e2fsck... Also on the O2, you can MMIO the RTC and make life easy. But on the Octane, the RTC is kludged onto the IOC3 ByteBus...so you have to write the address of interest to an addr port, then read the data from the data port. I've discovered since then that, if you spam 'hwclock --show' on the shell, the O2 never misses a beat, but on the Octane, because the IOC3 ByteBus is so slow, I can actually catch the RTC in the middle of an update cycle, which locks out access for 1 second until the update completes. --J
