Re: [PATCH 00/19] ARM: OMAP4 device off support
On Thu, 2012-05-10 at 00:14 +0100, Russell King - ARM Linux wrote: On Wed, May 09, 2012 at 03:46:02PM -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Hi, First version for this work. Applies on top of mainline + iochain set + OMAP4 core retention set. Working tree available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off FYI... seems your get repo is corrupted. I tried fetching both with git and https protocols: $ git remote add tero git://gitorious.org/~kristo/omap-pm/omap-pm-work.git $ git fetch tero fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack heade $ git remote rm tero $ git remote add tero https://git.gitorious.org/~kristo/omap-pm/omap-pm-work.git $ git fetch tero error: Unable to find 653621e4dd02d4a2117e1b813d9c5f1ccb11c9ed under https://git.gitorious.org/~kristo/omap-pm/omap-pm-work.git Cannot obtain needed object 653621e4dd02d4a2117e1b813d9c5f1ccb11c9ed error: Fetch failed. You will have a partially transferred pack file in your repository... Strange, well I pushed 1 new branch and it looks like it is cloning properly now. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
Tero Kristo t-kri...@ti.com writes: Hi, First version for this work. Applies on top of mainline + iochain set + OMAP4 core retention set. Working tree available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off FYI... seems your get repo is corrupted. I tried fetching both with git and https protocols: $ git remote add tero git://gitorious.org/~kristo/omap-pm/omap-pm-work.git $ git fetch tero fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack heade $ git remote rm tero $ git remote add tero https://git.gitorious.org/~kristo/omap-pm/omap-pm-work.git $ git fetch tero error: Unable to find 653621e4dd02d4a2117e1b813d9c5f1ccb11c9ed under https://git.gitorious.org/~kristo/omap-pm/omap-pm-work.git Cannot obtain needed object 653621e4dd02d4a2117e1b813d9c5f1ccb11c9ed error: Fetch failed. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Wed, May 09, 2012 at 03:46:02PM -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Hi, First version for this work. Applies on top of mainline + iochain set + OMAP4 core retention set. Working tree available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off FYI... seems your get repo is corrupted. I tried fetching both with git and https protocols: $ git remote add tero git://gitorious.org/~kristo/omap-pm/omap-pm-work.git $ git fetch tero fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack heade $ git remote rm tero $ git remote add tero https://git.gitorious.org/~kristo/omap-pm/omap-pm-work.git $ git fetch tero error: Unable to find 653621e4dd02d4a2117e1b813d9c5f1ccb11c9ed under https://git.gitorious.org/~kristo/omap-pm/omap-pm-work.git Cannot obtain needed object 653621e4dd02d4a2117e1b813d9c5f1ccb11c9ed error: Fetch failed. You will have a partially transferred pack file in your repository... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Fri, Apr 20, 2012 at 8:37 PM, Tero Kristo t-kri...@ti.com wrote:
On Fri, 2012-04-20 at 20:21 +0530, Datta, Shubhrajyoti wrote:
On Fri, Apr 20, 2012 at 8:13 PM, Tero Kristo t-kri...@ti.com wrote:
On Fri, 2012-04-20 at 06:55 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
[...]
I tried your branch on gp/emu devices but could not reproduce this
issue.
My observation is that while resuming, omap_hsmmc.1 eMMC is
trying to turn on phoenix vaux1 regulator via i2c which fails due
to controller timeout.
Note: eMMC is present only on sdp/blaze
Did you try this with off-mode enabled and did you check the device
actually goes to off? (see pm_debug/count and verify core off count is
increasing.) And as said, I was only able to see this problem on a blaze
device, panda works fine. But yes, you are probably right and it is not
an MMC driver issue but I2C.
Can you try the patch below? It sounds like the same problem.
Doesn't help with this one. I guess I2C loses context during device off
and it is not restored properly.
-Tero
Could you try the following patch
https://lkml.org/lkml/2012/3/30/345
That does the trick, after this it is working fine on blaze, and this
also fixes the timeout issues seen on panda board (meaning wake-up from
device off is much faster.)
Thats great.
Feel free to try the following.
I2C conditional restore
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66859.html
Also cooked a below rfc/untested patch for mmc restore.
From c28ec76f8a20c3ce59b72245ab9f3bc293b1ac43 Mon Sep 17 00:00:00 2001
From: Shubhrajyoti D shubhrajy...@ti.com
Date: Mon, 23 Apr 2012 11:52:54 +0530
Subject: [RFC PATCH] hsmmc: omap: Support for device off
Attempt to have device off support. Current the function hsmmc_get_context_loss
is made NULL for OMAP4. Remove it as post Terro's patches context may be lost.
Also it is good to have no assumptions of the context loss in the
driver.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b0268ea..2361f24 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -32,17 +32,11 @@ static u16 control_mmc1;
#define HSMMC_NAME_LEN 9
-#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
-
static int hsmmc_get_context_loss(struct device *dev)
{
return omap_pm_get_dev_context_loss_count(dev);
}
-#else
-#define hsmmc_get_context_loss NULL
-#endif
-
static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/19] ARM: OMAP4 device off support
Hi, First version for this work. Applies on top of mainline + iochain set + OMAP4 core retention set. Working tree available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off Tested on omap4430 EMU blaze + omap4460 GP panda boards. Some drivers have issues with device off, most notably MMC, as it breaks device off on blaze device after 1 entry to device off mode: [ 208.906921] omap_i2c omap_i2c.1: XRDY IRQ while no data to send [ 209.905639] omap_i2c omap_i2c.1: controller timed out [ 209.905792] twl: i2c_read failed to transfer all messages [ 209.905792] omap_hsmmc omap_hsmmc.1: could not set regulator OCR (-110) [ 212.296203] mmc0: error -110 during resume (card was removed?) [ 212.562164] PM: resume of devices complete after 3656.007 msecs [ 212.660125] Restarting tasks ... done. # # echo mem /sys/power/state [ 220.376892] PM: Syncing filesystems ... done. [ 220.382476] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 220.408386] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 220.439605] Suspending console(s) (use no_console_suspend to debug) [ 220.454650] dpm_run_callback(): platform_pm_suspend+0x0/0x54 returns -110 [ 220.454711] PM: Device omap_hsmmc.1 failed to suspend: error -110 [ 220.454711] PM: Some devices failed to suspend [ 220.718261] PM: resume of devices complete after 263.539 msecs [ 220.743988] Restarting tasks ... done. Attempting to disable MMC from config prevented boot completely for me, so this issue is likely to stay until someone fixes the MMC driver. Panda device works fine though, although the wakeup from device off is slow due to problems with some other drivers (most likely I2C.) Off mode is disabled by default, it can be enabled by either calling omap4_pm_enable_off_mode(1) from board files or alternatively writing to a debugfs node from userspace: echo 1 /debug/pm_debug/enable_off_mode Device off entry can be tracked through the debugfs also, it increases the core_pwrdm OFF state counter / timer, as this is an invalid state for the chip normally (core enters OSWR in device off.) Not sure if this a good way to do this but comments are welcome. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Fri, Apr 20, 2012 at 3:03 PM, Tero Kristo t-kri...@ti.com wrote: Hi, First version for this work. Applies on top of mainline + iochain set + OMAP4 core retention set. Working tree available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off Tested on omap4430 EMU blaze + omap4460 GP panda boards. Some drivers have issues with device off, most notably MMC, as it breaks device off on blaze device after 1 entry to device off mode: [ 208.906921] omap_i2c omap_i2c.1: XRDY IRQ while no data to send [ 209.905639] omap_i2c omap_i2c.1: controller timed out [ 209.905792] twl: i2c_read failed to transfer all messages [ 209.905792] omap_hsmmc omap_hsmmc.1: could not set regulator OCR (-110) [ 212.296203] mmc0: error -110 during resume (card was removed?) Hi Tero, I tried your branch on gp/emu devices but could not reproduce this issue. My observation is that while resuming, omap_hsmmc.1 eMMC is trying to turn on phoenix vaux1 regulator via i2c which fails due to controller timeout. Note: eMMC is present only on sdp/blaze [ 212.562164] PM: resume of devices complete after 3656.007 msecs [ 212.660125] Restarting tasks ... done. # # echo mem /sys/power/state [ 220.376892] PM: Syncing filesystems ... done. [ 220.382476] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 220.408386] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 220.439605] Suspending console(s) (use no_console_suspend to debug) [ 220.454650] dpm_run_callback(): platform_pm_suspend+0x0/0x54 returns -110 [ 220.454711] PM: Device omap_hsmmc.1 failed to suspend: error -110 [ 220.454711] PM: Some devices failed to suspend [ 220.718261] PM: resume of devices complete after 263.539 msecs [ 220.743988] Restarting tasks ... done. Attempting to disable MMC from config prevented boot completely for me, so this issue is likely to stay until someone fixes the MMC driver. Panda device works fine though, although the wakeup from device off is slow due to problems with some other drivers (most likely I2C.) can you try this patch if you want to disable MMC http://permalink.gmane.org/gmane.linux.ports.arm.omap/74540 or http://www.spinics.net/lists/linux-omap/msg67879.html and build omap_hsmmc as module. Off mode is disabled by default, it can be enabled by either calling omap4_pm_enable_off_mode(1) from board files or alternatively writing to a debugfs node from userspace: echo 1 /debug/pm_debug/enable_off_mode Device off entry can be tracked through the debugfs also, it increases the core_pwrdm OFF state counter / timer, as this is an invalid state for the chip normally (core enters OSWR in device off.) Not sure if this a good way to do this but comments are welcome. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Fri, 2012-04-20 at 17:50 +0530, T Krishnamoorthy, Balaji wrote: On Fri, Apr 20, 2012 at 3:03 PM, Tero Kristo t-kri...@ti.com wrote: Hi, First version for this work. Applies on top of mainline + iochain set + OMAP4 core retention set. Working tree available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off Tested on omap4430 EMU blaze + omap4460 GP panda boards. Some drivers have issues with device off, most notably MMC, as it breaks device off on blaze device after 1 entry to device off mode: [ 208.906921] omap_i2c omap_i2c.1: XRDY IRQ while no data to send [ 209.905639] omap_i2c omap_i2c.1: controller timed out [ 209.905792] twl: i2c_read failed to transfer all messages [ 209.905792] omap_hsmmc omap_hsmmc.1: could not set regulator OCR (-110) [ 212.296203] mmc0: error -110 during resume (card was removed?) Hi Tero, I tried your branch on gp/emu devices but could not reproduce this issue. My observation is that while resuming, omap_hsmmc.1 eMMC is trying to turn on phoenix vaux1 regulator via i2c which fails due to controller timeout. Note: eMMC is present only on sdp/blaze Did you try this with off-mode enabled and did you check the device actually goes to off? (see pm_debug/count and verify core off count is increasing.) And as said, I was only able to see this problem on a blaze device, panda works fine. But yes, you are probably right and it is not an MMC driver issue but I2C. [ 212.562164] PM: resume of devices complete after 3656.007 msecs [ 212.660125] Restarting tasks ... done. # # echo mem /sys/power/state [ 220.376892] PM: Syncing filesystems ... done. [ 220.382476] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 220.408386] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 220.439605] Suspending console(s) (use no_console_suspend to debug) [ 220.454650] dpm_run_callback(): platform_pm_suspend+0x0/0x54 returns -110 [ 220.454711] PM: Device omap_hsmmc.1 failed to suspend: error -110 [ 220.454711] PM: Some devices failed to suspend [ 220.718261] PM: resume of devices complete after 263.539 msecs [ 220.743988] Restarting tasks ... done. Attempting to disable MMC from config prevented boot completely for me, so this issue is likely to stay until someone fixes the MMC driver. Panda device works fine though, although the wakeup from device off is slow due to problems with some other drivers (most likely I2C.) can you try this patch if you want to disable MMC http://permalink.gmane.org/gmane.linux.ports.arm.omap/74540 Tried this patch and disabled MMC completely. Device off now works with blaze board also multiple times. -Tero or http://www.spinics.net/lists/linux-omap/msg67879.html and build omap_hsmmc as module. Off mode is disabled by default, it can be enabled by either calling omap4_pm_enable_off_mode(1) from board files or alternatively writing to a debugfs node from userspace: echo 1 /debug/pm_debug/enable_off_mode Device off entry can be tracked through the debugfs also, it increases the core_pwrdm OFF state counter / timer, as this is an invalid state for the chip normally (core enters OSWR in device off.) Not sure if this a good way to do this but comments are welcome. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
Tero Kristo t-kri...@ti.com writes:
[...]
I tried your branch on gp/emu devices but could not reproduce this issue.
My observation is that while resuming, omap_hsmmc.1 eMMC is
trying to turn on phoenix vaux1 regulator via i2c which fails due
to controller timeout.
Note: eMMC is present only on sdp/blaze
Did you try this with off-mode enabled and did you check the device
actually goes to off? (see pm_debug/count and verify core off count is
increasing.) And as said, I was only able to see this problem on a blaze
device, panda works fine. But yes, you are probably right and it is not
an MMC driver issue but I2C.
Can you try the patch below? It sounds like the same problem.
Kevin
From 999f34629140f436099050eb7aac514bfd2a2235 Mon Sep 17 00:00:00 2001
From: NeilBrown ne...@suse.de
Date: Fri, 30 Dec 2011 12:40:30 +1100
Subject: [PATCH] OMAP/I2C - Fix timeout problem during suspend.
On a board with OMAP3 processor and TWL4030 Power management,
we need to talk to the TWL4030 during late suspend but cannot
because the I2C interrupt is disabled (as late suspend disables
interrupt).
e.g. I get messages like:
[ 62.161102] musb-omap2430 musb-omap2430: LATE power domain suspend
[ 63.167205] omap_i2c omap_i2c.1: controller timed out
[ 63.183044] twl: i2c_read failed to transfer all messages
[ 64.182861] omap_i2c omap_i2c.1: controller timed out
[ 64.198455] twl: i2c_write failed to transfer all messages
[ 65.198455] omap_i2c omap_i2c.1: controller timed out
[ 65.203765] twl: i2c_write failed to transfer all messages
The stack shows omap2430_runtime_suspend calling twl4030_set_suspend
which tries to power-down the USB PHY (twl4030_phy_suspend -
twl4030_phy_power - __twl4030_phy_power which as a nice WARN_ON
that helps).
Then we get the same in resume:
[ 69.603912] musb-omap2430 musb-omap2430: EARLY power domain resume
[ 70.610473] omap_i2c omap_i2c.1: controller timed out
[ 70.626129] twl: i2c_write failed to transfer all messages
etc.
So don't disable interrupts for I2C.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..e024c50 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1092,7 +1092,7 @@ omap_i2c_probe(struct platform_device *pdev)
isr = (dev-rev OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
omap_i2c_isr;
- r = request_irq(dev-irq, isr, 0, pdev-name, dev);
+ r = request_irq(dev-irq, isr, IRQF_NO_SUSPEND, pdev-name, dev);
if (r) {
dev_err(dev-dev, failure requesting irq %i\n, dev-irq);
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Fri, 2012-04-20 at 06:55 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
[...]
I tried your branch on gp/emu devices but could not reproduce this issue.
My observation is that while resuming, omap_hsmmc.1 eMMC is
trying to turn on phoenix vaux1 regulator via i2c which fails due
to controller timeout.
Note: eMMC is present only on sdp/blaze
Did you try this with off-mode enabled and did you check the device
actually goes to off? (see pm_debug/count and verify core off count is
increasing.) And as said, I was only able to see this problem on a blaze
device, panda works fine. But yes, you are probably right and it is not
an MMC driver issue but I2C.
Can you try the patch below? It sounds like the same problem.
Doesn't help with this one. I guess I2C loses context during device off
and it is not restored properly.
-Tero
Kevin
From 999f34629140f436099050eb7aac514bfd2a2235 Mon Sep 17 00:00:00 2001
From: NeilBrown ne...@suse.de
Date: Fri, 30 Dec 2011 12:40:30 +1100
Subject: [PATCH] OMAP/I2C - Fix timeout problem during suspend.
On a board with OMAP3 processor and TWL4030 Power management,
we need to talk to the TWL4030 during late suspend but cannot
because the I2C interrupt is disabled (as late suspend disables
interrupt).
e.g. I get messages like:
[ 62.161102] musb-omap2430 musb-omap2430: LATE power domain suspend
[ 63.167205] omap_i2c omap_i2c.1: controller timed out
[ 63.183044] twl: i2c_read failed to transfer all messages
[ 64.182861] omap_i2c omap_i2c.1: controller timed out
[ 64.198455] twl: i2c_write failed to transfer all messages
[ 65.198455] omap_i2c omap_i2c.1: controller timed out
[ 65.203765] twl: i2c_write failed to transfer all messages
The stack shows omap2430_runtime_suspend calling twl4030_set_suspend
which tries to power-down the USB PHY (twl4030_phy_suspend -
twl4030_phy_power - __twl4030_phy_power which as a nice WARN_ON
that helps).
Then we get the same in resume:
[ 69.603912] musb-omap2430 musb-omap2430: EARLY power domain resume
[ 70.610473] omap_i2c omap_i2c.1: controller timed out
[ 70.626129] twl: i2c_write failed to transfer all messages
etc.
So don't disable interrupts for I2C.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..e024c50 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1092,7 +1092,7 @@ omap_i2c_probe(struct platform_device *pdev)
isr = (dev-rev OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
omap_i2c_isr;
- r = request_irq(dev-irq, isr, 0, pdev-name, dev);
+ r = request_irq(dev-irq, isr, IRQF_NO_SUSPEND, pdev-name, dev);
if (r) {
dev_err(dev-dev, failure requesting irq %i\n, dev-irq);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Fri, Apr 20, 2012 at 8:13 PM, Tero Kristo t-kri...@ti.com wrote: On Fri, 2012-04-20 at 06:55 -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: [...] I tried your branch on gp/emu devices but could not reproduce this issue. My observation is that while resuming, omap_hsmmc.1 eMMC is trying to turn on phoenix vaux1 regulator via i2c which fails due to controller timeout. Note: eMMC is present only on sdp/blaze Did you try this with off-mode enabled and did you check the device actually goes to off? (see pm_debug/count and verify core off count is increasing.) And as said, I was only able to see this problem on a blaze device, panda works fine. But yes, you are probably right and it is not an MMC driver issue but I2C. Can you try the patch below? It sounds like the same problem. Doesn't help with this one. I guess I2C loses context during device off and it is not restored properly. -Tero Could you try the following patch https://lkml.org/lkml/2012/3/30/345 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Fri, 2012-04-20 at 20:21 +0530, Datta, Shubhrajyoti wrote: On Fri, Apr 20, 2012 at 8:13 PM, Tero Kristo t-kri...@ti.com wrote: On Fri, 2012-04-20 at 06:55 -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: [...] I tried your branch on gp/emu devices but could not reproduce this issue. My observation is that while resuming, omap_hsmmc.1 eMMC is trying to turn on phoenix vaux1 regulator via i2c which fails due to controller timeout. Note: eMMC is present only on sdp/blaze Did you try this with off-mode enabled and did you check the device actually goes to off? (see pm_debug/count and verify core off count is increasing.) And as said, I was only able to see this problem on a blaze device, panda works fine. But yes, you are probably right and it is not an MMC driver issue but I2C. Can you try the patch below? It sounds like the same problem. Doesn't help with this one. I guess I2C loses context during device off and it is not restored properly. -Tero Could you try the following patch https://lkml.org/lkml/2012/3/30/345 That does the trick, after this it is working fine on blaze, and this also fixes the timeout issues seen on panda board (meaning wake-up from device off is much faster.) -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
