Re: [PATCH/RFC] ARM: OMAP: MUSB: disable omap_device auto-suspend

[Grazvydas Ignotas <notasas@gmail.com>]

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 <khilman@ti.com> wrote:
> Felipe Balbi <balbi@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 majordomo@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html