* Nishanth Menon <nm@xxxxxx> [160113 11:06]: > On 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote: > > > > Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm@xxxxxx>: > > > >> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote: > >>> 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. > > > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
