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

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!

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