Messages in this thread | | | Subject | Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery | From | "H. Nikolaus Schaller" <> | Date | Fri, 8 Jan 2016 19:32:54 +0100 |
| |
Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@atomide.com>:
> * H. Nikolaus Schaller <hns@goldelico.com> [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@atomide.com>: >>> >>> 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
| |