Hello, I've been trying to get suspend working with musb compiled in on 3.2. It seems both patches from this thread are needed, Kevin's patch stops omap2430_runtime_suspend() from being called at inappropriate time (when i2c is suspended [1]) and Felipe's patch brings that call back at better time (when i2c is still active). Perhaps they can be applied now, as current state crashes for me (see [1])?
However there is a new issue with these patches applied, core_pwrdm no longer enters low power state, but I think I've found why. After omap_device_disable_idle_on_suspend() call, _od_suspend_noirq() function in omap_device.c no longer calls omap_device_idle(), which means things (clocks?) are not properly stopped before entering suspend, preventing core_pwrdm from going down. So I guess the question is, can it be done that omap2430_runtime_suspend() could access i2c and omap_device_idle() would be called? [1] For some reason I get data abort on i2c register access if it's suspended, not i2c timeouts that some people report.. On Wed, Dec 7, 2011 at 9:37 PM, Kevin Hilman <khil...@ti.com> wrote: > Felipe Balbi <ba...@ti.com> writes: > >> Hi, >> >> On Mon, Nov 28, 2011 at 04:56:30PM -0800, Kevin Hilman wrote: >>> The MUSB driver does not currently implment suspend/resume callbacks, >> >> this is not entirelly true, actually. Such methods are missing for >> omap2430 glue layer, not for MUSB itself. And the fact is that it's only >> missing because we failed to use UNIVERSAL_DEV_PM_OPS for declaring >> dev_pm_ops structure. > > I guess that also means that nobody has tested MUSB host suspend/resume > with devices attached. > >> Can you see if this patch helps: > > Sure. > > That patch makes sense, and seems necessary, but doesn't fix the problem. > > The root of the problem is that the PM domain code will call the > driver's runtime PM methods late in the suspend if the device is not > already runtime suspended. > > In your patch, you make the driver's suspend/resume methods call the > runtime methods, but, the PM core doesn't know that that the device is now > runtime suspended, so the OMAP PM domain code will still call the > driver's runtime PM methods to try and suspend the device. > > In the case of this glue layer, the runtime PM methods call some PHY > code which is trying to use I2C. When this happens late in the suspend > process, I2C may already be suspended, so you get a bunch of I2C > timeouts. > > 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 -- Gražvydas -- 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
