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

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

quoted

quoted

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.

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.

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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html