Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [160108 09:50]: >> Tony, >> it is strange. It now works under unknown conditions - without any obvoius change. >> >> Am 06.01.2016 um 18:09 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: >>> >>> OK. It could be also some .config change with something built-in? >> >> I have compared /proc/config.gz from both systems and /sys/firmware/fdt >> with no significant and obvious change. >> >> Then I booted the 4.4-rc8 again and this time it worked. >> >> To verify, I have checked out linux-next this morning, cherry-picked this palmas >> rtc patch, compiled with omap2plus defconfig, and used the omap5-uevm.dtb. And >> hwclock works after doing a modprobe rtc_palmas. > > Weird. No luck here with current linux next or anything. > >> Then I did the same with official v4.4-rc8 and hwclock hangs. And now our >> 4.4-rc8 production kernel hangs again as well. Even if I use the >> DTB from the 4.3 kernel. > > I'm not seeing the RTC second increase in u-boot either, this > should show it: > > # i2c md 0x48 0x100 > > Of course the rtc may not be enabled in u-boot unlike for x15. > >> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in >> linux-next and unrelated to this DT patch. >> >> But I have no hint or idea what it is. > > Or something hangs the RTC? And the back-up battery has to drain to > reset the RTC somehow? Indeed it could be something like this. I already suspected that it depends on boot order of some components. But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch should enable (and not fix potential driver issues). BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
