Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

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