* H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [160115 06:34]: > Am 14.01.2016 um 19:35 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > updated patch, please retest that hwclock -w works properly with > > the RTC patch in this thread. > > I tried and it works. > > But then I found that you did set MUX_MODE7. Which is safe-mode. Oops, that's a typo, sorry! > And in safe-mode the gpio8_234/msecure ball should be "L". > > Then I experimented a little and it appears that you can remove > the gpio-hog entry: > > root@letux:~# devmem2 0x4A002980 > /dev/mem opened. > Memory mapped at address 0xb6f48000. > Value at address 0x4A002980 (0xb6f48980): 0x1080006 > root@letux:~# hwclock > Fri Jan 15 13:32:52 2016 -0.726651 seconds > root@letux:~# > > Or even mux the gpio to PIN_INPUT_PULLDOWN | MUX_MODE6: Hmm interesting. Have to test here too. FYI, it might be also worth draining the back-up battery with a small resistor while testing to make sure there's no initial state in the PMIC. > root@letux:~# devmem2 0x4A002980 > /dev/mem opened. > Memory mapped at address 0xb6f35000. > Value at address 0x4A002980 (0xb6f35980): 0x108010E > root@letux:~# hwclock > Fri Jan 15 14:30:05 2016 -1.155714 seconds > root@letux:~# > > So I now wonder if the twl6037 variant on the OMAP5432EVM really has > the gpio7 enabled as msecure input (there is some mention of OTP variants > in the Palmas docs I have, but I don't have the one of the exact chip variant used > on the EVM). > > If it were disabled by OTP (and then I assume it is automatically write-unprotected), > then we would simply have a useless connection from gpio8_234 to Palmas... > > So the outcome might depend on the Palmas chip version that is used on any > board that includes the omap5-board-common.dtsi. Could be different version yeah. > And the main difference between hwclock not-working and working on the omap5evm > should be the nirq1 part of your patch! OK so best to go back to square one with the testing with just the nirq1 change. > Please can someone else confirm that hwclock works without any init for > the msecure line and that I did not have a false positive by some other reason? Just to be sure.. Have you tested with hwclock -w and made sure it changes the time? Otherwise you may have started the RTC with some earlier kernel and it still keeps on ticking so the read test is not enough. Regards, Tony -- 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
