Suspend/Resume related questions in omap4

Hello Kaushal,

#Q1,2,3:  how suspend and resume function is getting called in omap4430 ? which core function is calling suspend ? how power is getting reduced while suspend function is called ?

The answer is:

The power management functions for Android utilized a system called "wakelocks", which was a set of patches to the Linux kernel to allow a caller to prevent the system from going to low power state.

Each wakelock is defined with a name and type. The type is one of:

• WAKE_LOCK_IDLE, or
• WAKE_LOCK_SUSPEND.

When a wake lock of type "IDLE" is in effect, the system will not enter idle (low power) state, and this should make the device more responsive. That is, it does not have to wake up from idle to respond to interrupts or events. When a wake lock of type "SUSPEND" is held, then the system will not suspend, which takes even longer to resume from.

shell@android:/ $ cd /sys/power
shell@android:/sys/power $ ls
pm_async
pm_test
state
wait_for_fb_sleep
wait_for_fb_wake
wake_lock
wake_unlock
wakeup_count

Creating a wakelock:

From user space, a process can write a name to

/sys/power/wake_lock

You can, from user space, see the currently defined wakelocks and a bunch of information about their status, using 'cat /proc/wakelocks'

Using a wakelock from user space:

To release a suspend wake lock from user space, a process can write the lock name to: /sys/power/wake_unlock

#Q4: i want to know each n related things to PM of suspend and resume..

- Refer to sections 3.1.1.2 Power Management and 3.4.1 Device Power-Management Layout in OMAP4430 TRM.

For the idle protocol management on the PRCM module side, the behavior of PRCM module is configured
in the CM_<Power domain>_<module>_CLKCTRL[x] MODULEMODE bit field.
If you want to suspend the I2C module which you use for interface between OMAP4 and MPU9150, you must write the bit-field in the register:

For example: see the register CM_L4PER_I2C1_CLKCTRL in the PRCM register manual.

Could you provide more information for schematic of mpu9150 to OMAP connection?

Which OS do you use on your board?

Best regards,

Yanko

Hi Kaushal,

I think you have the same problem as I faced for MPU9150. After suspend/resume mpu9150 goes crazy and gives junk values. 

This was happening for me due to the fact that in suspend/resume the TWLXXXX PMIC regulator which was used  to power the mpu9150 was suspended/resumed.  And MPU9150 driver stack from Invensense assumption the power will be present all the time and they put the  mpu9150 in low power mode in suspend and brings back from low power mode in resume. Since regulator is powered off in suspend in resume we need to reconfigure mpu9150 which is not the case 9150 gives junk values.  

I could able to solve the problem by hacking the kernel/drivers/regulator/twl-regulator.c code and avoid suspending and resuming that specific regulator and let 9150 go into low power mode and resume from low power mode.

Just check how your mpu9150 is powered if it is powered with TWL PMIC regulator you will see the problem I have explained. And if this is not the issue  you are facing please ignore.

Regards

Anuroop

Hi Anuroop,

Can u send me the patch for same ??
I think, I'm having the similar problem upto some extend.

n One more thing, Why deep suspend is getting called 2 times ?
any suggestion?

with regards
-Kaushal

Hi Kaushal,

In our case VAUX3 used to power 9150 so this code is for VAUX3 you need to modify the code according to your regulator. Anyways here is code snipped if it helps

diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c

index d736b16..2760a18 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -107,6 +107,7 @@ struct twlreg_info {
*/
#define TWL6030_CFG_TRANS_STATE_AUTO 0x01
#define TWL6030_CFG_TRANS_SLEEP_SHIFT 2
+#define TWL6030_CFG_TRANS_STATE_ON 0x0F

/* TWL6030 LDO register values for CFG_STATE */
#define TWL6030_CFG_STATE_OFF 0x00
}

+// kee the VAUX3 active during suspend as the 9150 as it is not reconfigured and assumption is  the power will +//always  present, also keeping power on does not affect the overll system
+static int twl6030reg_regulator_check(struct regulator_dev *rdev)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+ int ret = 0;
+
+ /* This is only required for the VAUX3 to stay alive all the time */
+ if (info->desc.id == TWL6032_REG_LDO3)
+ {
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_TRANS, TWL6030_CFG_TRANS_STATE_ON);
+
+ if (ret)
+ printk(KERN_ERR "%s: VAUX3 Write Err TWL6030_CFG_TRANS_STATE_ON \r\n",__func__);
+
+ udelay(info->delay);
+ ret = 1;
+ }
+ return ret;
+}

static int twl6030reg_enable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
@@ -265,6 +290,11 @@ static int twl6030reg_enable(struct regulator_dev *rdev)
ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
grp << TWL6030_CFG_STATE_GRP_SHIFT |
TWL6030_CFG_STATE_ON);
+
+ if(twl6030reg_regulator_check(rdev))
+ return ret;
+#endif
/*
* Ensure it stays in Auto mode when we enter suspend state.
* (TWL6030 in sleep mode).
@@ -431,12 +461,20 @@ static int twl6030reg_set_mode(struct regulator_dev *rdev, unsigned mode)

static int twl6030ldo_suspend_enable(struct regulator_dev *rdev)
{
+ if(twl6030reg_regulator_check(rdev))
+ return 0;

return twl6030reg_set_trans_state(rdev, TWL6030_CFG_TRANS_SLEEP_SHIFT,
TWL6030_CFG_TRANS_STATE_AUTO);
}

static int twl6030ldo_suspend_disable(struct regulator_dev *rdev)
{
+ if(twl6030reg_regulator_check(rdev))
+ return 0;
return twl6030reg_set_trans_state(rdev, TWL6030_CFG_TRANS_SLEEP_SHIFT,
TWL6030_CFG_TRANS_STATE_OFF);
}

Regards

Anuroop