On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote:
[...]
>>>>
>>>> Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
>>>>
>>>> --- 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 :) ).
>
> This one
>
>>>> OMAP5_IOPAD(0x180, PIN_INPUT _PULLUP | MUX_MODE6) /* gpio8_234 used for sys_drm_msecure */
>
>
> works for me on the OMAP5 EVM as well.
>
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
