On Wed, Dec 16, 2009 at 11:11 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 16 Dec 2009, Yuping Luo wrote: > >> for our device controller when system suspended, it will stop phy >> clk, disable USBINTR, and release all eps, however,for gadget_driver, >> it only call the disconnet() -> fsg_disconnect(), I am wondering here >> it's enough for g_file_storage ? >> when system resumed, the device controller will be reinitialized and >> restarted. > > That should be okay. > >> I believe there exist some mismatch between our device controller >> and the mass storage gadget driver, but don't know where. > >> > You could speed it up by getting rid of the set_freezable() call near >> > the start of fsg_main_thread(), but then you might find there are other >> > problems. For example, the host might want to read data from the >> > backing storage before the backing storage device has been resumed. > > You should try removing the set_freezable() call. It might solve your > problem. > it works while some trivial complaints like "sending command-failure status" occur. > But a better approach would be to use register_pm_notifier (see > include/linux/suspend.h). When you get a PM_SUSPEND_PREPARE message, > call usb_gadget_disconnect(). When you get a PM_POST_SUSPEND message, > call usb_gadget_connect(). Then it won't matter that the thread gets > woken up late. > > Alan Stern > it doesn't work, since when system wakeup, the pm_notifier_call_chain() called very late, after the restarting the tasks. anyway, I will keep the workaround above. btw, another ARM platform (with same usb controller) with kernel version 2.6.28 is ok. Thanks. Yuping -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
