Hi, Am 15.01.2016 um 16:47 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > * 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. You were right (and I as well to doubt my first results). And I also didn't take ntpd in account. Now: root@letux:~# hwclock Fri Jan 15 16:53:19 2016 -0.699173 seconds root@letux:~# hwclock --set --date="2011-08-14 16:45:05" root@letux:~# hwclock Fri Jan 15 16:54:08 2016 -0.451544 seconds root@letux:~# devmem2 0x4A002980 w 0x108010E /dev/mem opened. Memory mapped at address 0xb6f58000. Value at address 0x4A002980 (0xb6f58980): 0x108010E Written 0x108010E; readback 0x108010E root@letux:~# hwclock --set --date="2011-08-14 16:45:05" root@letux:~# hwclock Fri Jan 15 16:55:18 2016 -0.555951 seconds root@letux:~# devmem2 0x4A002980 w 0x108011E /dev/mem opened. Memory mapped at address 0xb6f7e000. Value at address 0x4A002980 (0xb6f7e980): 0x108010E Written 0x108011E; readback 0x108011E root@letux:~# hwclock --set --date="2011-08-14 16:45:05" root@letux:~# hwclock Sun Aug 14 16:45:10 2011 -0.813317 seconds root@letux:~# ^C root@letux:~# So the pull-up in gpin-mode6 must be enable to *write* the RTC, i.e. the msecure pin must indeed be pulled up (or hogged to "1"). It also works with gpio-hog + PIN_OUTPUT | MUX_MODE6. This means: * nirq1 is needed so that we don't have the timeout (on read/write) * gpio-hog is needed on MODE6 or MODE0 to be able to really write (and not be silently ignored) Thanks and BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
