s3c2443 hangs on msleep on resume from suspend

s3c2443 hangs on msleep on resume from suspend

[Alexander Varnin]

Hello.
I'm developing on Samsung s3c2443 CPU and now my aim is to make suspend
mode working properly. My kernel version is 3.6. Everything was OK,
however Linux hanged on resume, if usb ohci driver was loaded. My
investigation showed, that it hangs on msleep function, that is getting
called in ohci_run() function in drivers/usb/host/ohci-hcd.c file. Exact
line of code is [1]. I found on the web, that there was [2] similar
problem on s3c2410. The reason of hang is that msleep locks the only
working thread in system, and nobody can unlock it. The simple
workaround is to replace msleep with mdelay. But the usage of msleep is
in platform-independent usb-ohci code. That means, that other platforms
somehow bypass this problem, and work with msleep correctly. But I will
prefer to fix it in platform-depended, than to make workaround in common
code.

What bugs in platform-depended code could lead to such problem?

I suggest, that there is some problem with sequence of resume actions,
and usb resume happens much earlier, than it have to. But where exactly
should I search for the problem?

Thanks,
Alexander.

[1]
http://lxr.free-electrons.com/source/drivers/usb/host/ohci-hcd.c?v=3.6;a=arm#L621
[2] http://osdir.com/ml/handhelds.openmoko.kernel/2008-05/msg00168.html

s3c2443 hangs on msleep on resume from suspend

[Alexander Varnin]

Hello.
I'm developing on Samsung s3c2443 CPU and now my aim is to make suspend
mode working properly. My kernel version is 3.6. Everything was OK,
however Linux hanged on resume, if usb ohci driver was loaded. My
investigation showed, that it hangs on msleep function, that is getting
called in ohci_run() function in drivers/usb/host/ohci-hcd.c file. Exact
line of code is [1]. I found on the web, that there was [2] similar
problem on s3c2410. The reason of hang is that msleep locks the only
working thread in system, and nobody can unlock it. The simple
workaround is to replace msleep with mdelay. But the usage of msleep is
in platform-independent usb-ohci code. That means, that other platforms
somehow bypass this problem, and work with msleep correctly. But I will
prefer to fix it in platform-depended, than to make workaround in common
code.

What bugs in platform-depended code could lead to such problem?

I suggest, that there is some problem with sequence of resume actions,
and usb resume happens much earlier, than it have to. But where exactly
should I search for the problem?

Thanks,
Alexander.

[1]
http://lxr.free-electrons.com/source/drivers/usb/host/ohci-hcd.c?v=3.6;a=arm#L621
[2] http://osdir.com/ml/handhelds.openmoko.kernel/2008-05/msg00168.html