Am 13.01.2016 um 19:00 schrieb Tony Lindgren [off-list ref]:

* Nishanth Menon [off-list ref] [160113 09:30]:

quoted

On 01/13/2016 10:48 AM, Tony Lindgren wrote:

quoted

So if we start changing things to GPIO mode, we really need some
further explanations and neeed to handle the GPIO pin properly in
the TWL driver. And it should be done in a separate patch for all
of the TWL SoCs.

That does not make sense to me. The original intent of MSECURE is to use
PMIC control (in specific certain usecases - which are no longer
relevant) in trustzone or equivalent secure processor modes. when such a
mode is not planned on being used, you just tell PMIC that it is always
in secure mode. In fact, there was discussion internally that MSECURE
should never even have been connected to SoC if the SoC was GP SoC - but
ofcourse, the want to have a consistent reference schematics for evms
(since EVMs have HS/Non-HS parts) trumped such talk.

trying to split this up into further steps adds 0 additional
functionality - what is the pmic driver supposed to do with the GPIO even?

in *real* HS product devices, in fact, the register space is really
firewalled out

Right, OK here we are finally getting some answers to the "why" part :)

And I also have few more "why" question in mind. If this change from
msecure to GPIO muxing is so important.

Why it was never fixed in the mainline kernel for omap4 and omap5 and
it was just sitting in various TI trees?

And it sounds like any kind of muxing on HS devices here for this
pin will oops the device?

quoted

The last TI product kernel tree that seriously focussed on OMAP5/OMAP4
was
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4
things changed definitions (in terms of descope) since then.. but
anyways.. thought I'd just pitch it out here.

sevm: - this board got scrapped
http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097

omap5-panda is the omap5uevm/evm now:
http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816

OK

quoted

quoted

I don't have anything against adding GPIO handling to the TWL driver
so it can be optionally specified. But that's clearly a separate patch

TWL/TPS driver will need no change in the proposal I made with "gpio
hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt -
gpio-hog property) - just a dt change for the right configuration.

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.

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
* a real gpio output which is actively set to value 1 in u-boot or kernel driver, or
* the not well documented feature of MUX_MODE1 (OMAP5), other MUX_MODEs for OMAP3/4.

For my application we do not need to change the msecure state. We just need
to be able to write the rtc. And since the gpio7 of the Palmas is connected to
gpio8_234 of the OMAP5 we just have to initialize it properly once.

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