On Mon, 30 Jan 2012 00:57:13 +0200 Grazvydas Ignotas <notasas@xxxxxxxxx> wrote: > 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.. 1/ I don't know what your problem might be, but I have suspend working quite well with musb compiled in. CORE goes to RET. The code is at git://neil.brown.name/gta04 in the 3.2-gta04 branch. There are various additions and hacks in there, I don't know which ones might be important. 2/ If you see i2c register access abort, I think that is because the iclk is being turned off. Timeouts are because the interrupt is disabled or ignored. good luck, NeilBrown > > > On Wed, Dec 7, 2011 at 9:37 PM, Kevin Hilman <khilman@xxxxxx> wrote: > > Felipe Balbi <balbi@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Attachment:
signature.asc
Description: PGP signature
