On Thu, 26 Apr 2012, Chen Peter-B29397 wrote: > > I don't think you are right. Suppose an individual port is suspended, > > and then some minutes later the bus is suspended. Let's say the PHY is > > set to low power only 2 ms after the bus stops sending SOF packets. > > Nevertheless, the device attached to the suspended port could send a > > wakeup signal while the PHY is entering low-power mode. After all, the > > device has already been suspended for much more than 5 ms. > > > Does your case like below: > Assume there is a intermediate hub which has two-port, and the hub > connects to roothub (controller), one port is connecting 3G modem, another port is > connect u-disk. 3G is auto-suspend at runtime, when we plug out u-disk from > another port, the bus will go to suspend, later the PHY is going to enter low power mode, > at that time, remote wakeup occurs, the resume signal will go to intermediate hub, > then go to roothub. Please attention here, the intermediate hub must not send resume to > roothub until the bus enters idle 5ms later. > > So, the resume signal will not go to roothub within 5ms after we set PORT_SUSPEND, > then the resume signal will not go to roothub while the PHY is entering low power > mode if we put set PORT_SUSPEND and PHY enters low power mode code together. No, that's not what I meant. Suppose there is no intermediate hub, only a 3G modem plugged directly into the root hub. The 3G modem does a runtime autosuspend, and then 2 seconds later sends a wakeup request. But the autosuspend timeout for the root hub is also 2 seconds, so the root hub suspends and the PHY goes into low-power mode at just the same time as when the wakeup request arrives. > > This is very unlikely to happen, but it isn't impossible. Therefore > > the hardware needs to be able to handle it. > > > After discussing with IC (Synopsis-chipidea core)guys, the possibilities for > making hardware abnormal is low at this corner case, just having potential problem > after below conditions are met: > > - The device only sends about 1ms resume signal > - Software haven't seen portsc.fpr = 1, and goes on putting PHY to low power mode, > the time between device issues resume to PHY have entered low power mode is > larger than 1ms. > > Combining the PHY operation with hcd can avoid this potential risk. > > The reason why I raise this issue is want to see if PHY's code must be combined > with controller's (host or device), or PHY's code can be put at some glue layer, > like at otg driver, this otg driver like bus driver for gadget and host, > (here, otg, host, gadget driver shares the same register mapping) > it manages the share resources, like PHY, controller clock, pinmux, register mapping > etc. Well, we can indeed do this if you figure out a good way to interface ehci-hcd with the PHY code. For example, the OTG/PHY layer could export routines to control the power mode, and these routines could be implemented by empty inline routines on platforms that don't need them. I would prefer that approach over merging the PHY's code into ehci-hub.c or ehci-hcd.c. But if you need to, you could put the code into a platform driver like ehci-fsl.c. Alan Stern -- 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
