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. > >> >> 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. But if there is MUX_MODE1 for this purpose that works equally well, we should use it instead of a gpin+pullup. BR, Nikolaus-- 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
