On Tue, Dec 15, 2009 at 11:21 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 15 Dec 2009, Yuping Luo wrote: > >> Dear friends, >> It's my first time to post, please feel free to correct me if any concern. >> >> I have one ARM board with linux version (Linux localhost >> 2.6.27-default #3 PREEMPT Thu Dec 10 15:17:44 CST 2009 armv6l >> unknown), and the usb device controller used for mass storage. it's >> normal if without sleep/wakeup procedure, however, if the procedure >> happen and the host is Linux Ubuntu OS, the device can't be >> enumerated, it's ok with the host as Window XP since >> USB_REQ_CLEAR_FEATURE will be sent to the device. >> after adding some debug info in the file_storage.c, and I found >> there are several raise_exception() called, but no corresponding >> handle_exception() when comparing the plug/unplug usb cable procedure, >> so the fsg->state not reset properly. >> it' ok if commenting the "if (fsg->state <= new_state) " in >> function raise_exception(). but I think it may be not the formal way. > > g_file_storage doesn't really support system suspend. This is because > different systems treat their USB device controllers differently during > suspend. > 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. I believe there exist some mismatch between our device controller and the mass storage gadget driver, but don't know where. > You'll probably find it works better if you wake up the ARM board > _before_ plugging in the USB cable. better do like this, it's also the android ADB way. when mounted as one disk to pc, the system will stand awake always. >> it seem that the fsg_main_thread() rescheduled very late by the system. > > Yes. But it ends up doing the right thing, doesn't it? You end up in > the configured state. if don't comment the state comparison code in raise_exception(), it can't enter the state. > 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. > > Alan Stern > > Thanks for your advices. 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
