On 06/28/2012 08:42 AM, Jon Hunter wrote:
On 06/27/2012 07:41 PM, Franky Lin wrote:
On 06/26/2012 08:37 PM, Kevin Hilman wrote:
"Franky Lin" <frankyl@xxxxxxxxxxxx> writes:
I noticed Kevin raised some similar cases on other platforms and also
provided two patches in the patch mail thread. But unfortunately those
two patches doesn't help in our case. I tested the driver with 3.5-rc3
mainline kernel and the issue is still there. I can only "fix" the
hang by either reverting the commit or disabling
CONFIG_PM_RUNTIME. Also, the hang only happens on Panda ES board. Old
Panda with 4430 works good.
Any thoughts and suggestions?
If reverting the patch fixes your problem, can you isolate down to which
part of that patch causes the problem? IOW, can you fix your problem if
you undo just the hunk added in runtime_suspend or undo just the moved
hunk runtime_resume? Or is reverting both required?
I suspect the added runtime_suspend hunk is causing the problems, so can
you see if just undoing that part works[1]. If that works, I will give
a bit more of a thinking on it tomorrow.
runtime_suspend hunk is fine. The hang still exist after reverting it.
The culprit is the moved hunk in runtime_resume. Reverting it makes the
hang disappear.
Thanks. From reviewing the code the only thing that appears suspect based
upon your findings is the return if we find the context has not been lost.
We are not checking if "workaround_enabled" is set before we return.
Could you try the following change on top of v3.5-rc3?
The patch doesn't help. And I also managed to probe the signal. It's
active when it hung.
Also, could you add a print in the runtime_suspend/resume() functions so
we can see how often these are being called. In my case, I really don't see
these being exercised and I am wondering how often you see suspend/resume
being called in your setup.
Well, the runtime_suspend/resume never get called during the test.
Thanks,
Franky
--
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
