Hi,

Am 15.01.2016 um 16:47 schrieb Tony Lindgren [off-list ref]:

* H. Nikolaus Schaller [off-list ref] [160115 06:34]:

quoted

Am 14.01.2016 um 19:35 schrieb Tony Lindgren [off-list ref]:

quoted

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!

quoted

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.

quoted

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.

quoted

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.

quoted

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