On 01/13/2016 04:55 PM, Nishanth Menon wrote:

On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote:
[...]

quoted

quoted

quoted

quoted

Signed-off-by: Tony Lindgren <redacted>

--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi

@@ -213,6 +213,12 @@

		>;
	};

+	palmas_msecure_pins: palmas_msecure_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */

I wonder now what MODE1 is.

In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved".

Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15?

And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software).

Good catch. This one is interesting. If my memory serves me right,
MSECURE signal from SoC is triggered in secure mode (trustzone) - the
requirement was that certain PMIC modifications should only be done in
secure mode for certain product applications. What this means is that
certain functions of the PMIC will be unavailable when the SoC is
running in "untrusted" mode.

Instead, the usual mode of operation is to set it up as GPIO (as Nikolas
pointed below) and either use GPIO HOG or default weak pull to keep it
in the required state.

I think it is better to set it as GPIO than as DRM_MSECURE.

This is probably also the reason why this mode is NOT in public TRM -
all security related topics are probably in the NDA only secure TRM
addendum.


I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we
are not doing any HS OMAP5 at least in public domain :) ).

Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi)
and, again if i remember correctly, someone reported that sys_drm_msecure might have different values
on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality
was always modeled using GPIO.
 

-- 
regards,
-grygorii
--
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