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

* Nishanth Menon [off-list ref] [160113 11:06]:

On 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote:

quoted

Am 13.01.2016 um 19:31 schrieb Nishanth Menon [off-list ref]:

quoted

On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote:

quoted

Since the scratchpad is not used we can permanently enable msecure. Which
means that we must somehow get the driving output to be "1".

This can be either done by
* a gpio with pull-up - switched to input mode as I proposed, or

I think you intended to suggest to do a mux to gpio with just pinmux
pull?

Yes.

quoted

The internal pull on padconf is very weak
- for typical needs like
these, it is rather suggested to stick with real GPIO drive to prevent
conditions like noise interference(for example).

well, on OMAP5 pull up/down are astonishingly strong :)
100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic.
So a noise source must be coupled by an impedance in the 1 kOhm range.
This is quite rare. So I would not worry about that.

Interesting. I did not know that, and have'nt dug at people to confirm
that either :).

An internal feedback I got some time back on AM57 (not OMAP5) - context
was that we were discussing if an external pull up resistor was needed
for a GPIO button:
"Internal pull-ups are relatively weak (ranging to 100kOhm or higher)
and are good for avoiding higher leakage due to floating input level,
and may not be sufficient for valid logic 1/0 depending on what else is
connected on the board.  If a signal must absolutely be pulled to a
valid logic 1 or 0 for system functionality, then an external pull
should be used."

Anyways... will let Tony decide where he wants to go on this..

Eek now we have at least three options! Time for online vote:

1. Use msecure pinmux and let whatever mystery software control
   the pin completely out of our control like we've been doing with
   the mainline kernel for years.

2. Set up the msecure pin as GPIO output high unconditionally.
   This is what the TI android kernel tree seems to be doing.

3. New suggestion to use the SoC internal pull to keep the msecure
   pin high. This might be a little bit more power friendly than
   option #2 or #3.

Maybe option #3 would save a little bit more power compared to
options 1 and 2?

Anyways, considering what's been discussed, after the minimal RTC fix
we could also add code to allow the TWL driver optionally configure the
GPIO. This way the TWL driver could also check the GPIO state in case
some out-of-our-control mystery software goes tweak the msecure pin
state. Or the RTC driver could just check that the bits really change
after= writing them. Then we would at least know things are not working
right for the TWL related RTC drivers.

Regards,

Tony