On 01/13/2016 09:05 PM, Nishanth Menon wrote: > 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: >>> [...] >>> >>>>> OK. So are we sure the TWL driver will never have to toggle this pin? >>>> >>>> After studying the Palmas TRM it appears that this pin just should be "high" >>>> to be able to write to RTC and some scratchpad register. If the Palmas OTP >>>> is programmed to use gpio7 as msecure input. >>> >>> Thanks for digging it up. we dont use the scratchpad, but in some cases >>> where SoC cold reset is involved, those registers may store additional >>> information. >> >> I remember a similar thing from omap3-twl4030 where the boot source is stored >> so that a warm reboot searches there. But I don#t know if the OMPAP5 Boot ROM >> is using that. >> > > I believe that nonsense of OMAP ROM accessing PMIC stopped with OMAP3. I > dont believe OMAP4 or any later generation processors does any PMIC > access anymore - they instead make assumptions about specific voltage > levels they will work on (So called OPP_BOOT) instead of assuming > specific PMIC they will work with.. > >>>> 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." MUX_MODE1(secure modes) is not working well as i mentioned. Here I agree with Nishanth - "gpio hog" mechanism looks like the best solution now, because of: - it exist now :P. At the moment when omap4/5 were fixed the pinmux solution was the simplest and fastest one, with not too many alternatives. - explicit gpio hog definition in DT will help other developer (and what is more important HW designers) to better understand that this gpio can be used as generic GPIO (at minimum without HW modification). -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
