ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC

From: Kevin Hilman <[email protected]>

On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is connected to the MSECURE input of the TWL6030 PMIC. This signal controls the secure-mode operation of the PMIC. If its not mux'd correctly, some functionality of the PMIC will not be accessible since the PMIC will be in secure mode.

For example, if the TWL RTC is in secure mode, most of its registers are read-only, meaning (re)programming the RTC (e.g. for wakeup from suspend) will fail.

To fix, ensure the signal is properly mux'd as output when TWL is intialized.

This fix is required when using recent versions of u-boot (>= v2012.04.01) since u-boot is no longer setting the default mux for this pin.

Signed-off-by Kevin Hilman <[email protected]>

---
Based on v3.7-rc4. Targetted as a fix for v3.7.

A correponding DT fix for this is needed as well, but that will be part of a bigger series to get PM working with DT boot and needs to include other pins like sys_nirq1.

 arch/arm/mach-omap2/twl-common.c | 1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-omap2/twl-common.c +0 -0

index 635e109..96cae8b 100644

Hi,

Quoted 40 lines · Kevin Hilman

From: Kevin Hilman <[email protected]>

On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is connected to the MSECURE input of the TWL6030 PMIC. This signal controls the secure-mode operation of the PMIC. If its not mux'd correctly, some functionality of the PMIC will not be accessible since the PMIC will be in secure mode.

For example, if the TWL RTC is in secure mode, most of its registers are read-only, meaning (re)programming the RTC (e.g. for wakeup from suspend) will fail.

To fix, ensure the signal is properly mux'd as output when TWL is intialized.

This fix is required when using recent versions of u-boot (>= v2012.04.01) since u-boot is no longer setting the default mux for this pin.

Signed-off-by Kevin Hilman <[email protected]>

---
Based on v3.7-rc4. Targetted as a fix for v3.7.

A correponding DT fix for this is needed as well, but that will be part of a bigger series to get PM working with DT boot and needs to include other pins like sys_nirq1.

 arch/arm/mach-omap2/twl-common.c | 1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-omap2/twl-common.c +1 -0

index 635e109..96cae8b 100644
@@ -73,6 +73,7 @@ void __init omap4_pmic_init(const char *pmic_type,
 {
 	/* PMIC part*/
 	omap_mux_init_signal("sys_nirq1", OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE);
+	omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT);
 	omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START, pmic_data);
 

arch/arm/mach-omap2/twl-common.c void __init omap4_pmic_init(const char *pmic_type, · line 79

Quoted 1 line

arch/arm/mach-omap2/twl-common.c +0 -0

 	/* Register additional devices on i2c1 bus if needed */

not entirely related to $SUBJECT but this essentially means we're dropping the security feature whenever Linux runs.

Shouldn't we try to change that pin at register write boundaries so we keep the secure feature enabled until we know we're going to write to the HW ?

Maybe it could even be done later through pinctrl, perhaps ?

Quoted 43 lines · Felipe Balbi

Hi,

Quoted 40 lines · Kevin Hilman

From: Kevin Hilman <[email protected]>

On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is connected to the MSECURE input of the TWL6030 PMIC. This signal controls the secure-mode operation of the PMIC. If its not mux'd correctly, some functionality of the PMIC will not be accessible since the PMIC will be in secure mode.

For example, if the TWL RTC is in secure mode, most of its registers are read-only, meaning (re)programming the RTC (e.g. for wakeup from suspend) will fail.

To fix, ensure the signal is properly mux'd as output when TWL is intialized.

This fix is required when using recent versions of u-boot (>= v2012.04.01) since u-boot is no longer setting the default mux for this pin.

Signed-off-by Kevin Hilman <[email protected]>

---
Based on v3.7-rc4. Targetted as a fix for v3.7.

A correponding DT fix for this is needed as well, but that will be part of a bigger series to get PM working with DT boot and needs to include other pins like sys_nirq1.

 arch/arm/mach-omap2/twl-common.c | 1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-omap2/twl-common.c +1 -0

index 635e109..96cae8b 100644
@@ -73,6 +73,7 @@ void __init omap4_pmic_init(const char *pmic_type,
 {
 	/* PMIC part*/
 	omap_mux_init_signal("sys_nirq1", OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE);
+	omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT);
 	omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START, pmic_data);
 

Quoted 4 lines

arch/arm/mach-omap2/twl-common.c void __init omap4_pmic_init(const char *pmic_type, · line 79

Quoted 1 line

arch/arm/mach-omap2/twl-common.c +0 -0

 	/* Register additional devices on i2c1 bus if needed */

not entirely related to $SUBJECT but this essentially means we're dropping the security feature whenever Linux runs.

Unless we intend to remove RTC driver in it's entirety and implement RTC time change update in secure driver, current twl rtc driver was never meant to exist with RTC time updates only in trustzone mode. Neither does it drop any security feature when ever Linux runs- msecure pin has not been used for any other purpose to my knowledge with Linux. So, this change does not change the status quo we are currently in,

Quoted 6 lines

Shouldn't we try to change that pin at register write boundaries so we keep the secure feature enabled until we know we're going to write to the HW ?

Maybe it could even be done later through pinctrl, perhaps ?

That might be a better solution I agree. We might be locking down to a specific pin name here, which could potentially change in a future SoC. The right approach IMHO would be omap_gpio_mux equivalent.

Example change for OMAP5 purely from a board perspective(gerrit warning):
http://review.omapzoom.org/#/c/23819/5/arch/arm/mach-omap2/board-omap5evm.c,unified

Further, depending on how it is hooked on a different board (not that I have seen any different other than msecure), it might even be hooked on to another GPIO, making this scenario not scaling to "theoretical board configuration".