Am 08.01.2016 um 19:15 schrieb Tony Lindgren [off-list ref]:

* H. Nikolaus Schaller [off-list ref] [160108 09:50]:

quoted

Tony,
it is strange. It now works under unknown conditions - without any obvoius change.

Am 06.01.2016 um 18:09 schrieb Tony Lindgren [off-list ref]:

quoted

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.

quoted

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.

quoted

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html