On Thu, 8 Jan 2015, Peter Chen wrote: > I have traced three cases: > Case 1: with my patch > Case 2: without my patch > Case 3: without my patch, and add PORT_SUSPEND before sending the resume ... > Let's see why case 3 can't work: > - At packet 31187, it is resume signal for remote wakeup, after the resume (K) ends, the bus state is > high speed idle (SE0), when the device sees high speed idle no less than 3.0 ms and no more than 3.125 ms > (TWTREV), it will reverse to full speed by disconnecting its termination resistors and reconnecting its > D+ pull-up resistor. If device sees full speed J, it will consider it is suspend process, If device sees it is > still SE0, it will consider it is reset process. (In spec: 7.1.7.6 Suspending & 7.1.7.5 Reset Signaling) > - At packet 31188-31191, the device consider it is reset process, so it starts high speed negotiation with > ChirpK. Unfortunately, the host is not in reset state, so the that negotiation will be failed, then the > device goes to full speed state, but the host is still at high speed. > - At packet 31192, we put port in suspend mode, so the bus is in suspend state. > - At packet 31193: due to the port is at suspend mode, it will set PORT_RESUME, and then we see resume > signal at the bus, after resume has ended. The mismatch should occur due to the host is high speed, > but the device is full speed. > - When the host sends SoF send, it will detect the disconnection. > > Since the port will switch to high speed idle automatically after resume ends, we had to set RS before that, in that way, it can > send SoF in time, the device will not reverse to full speed state. Yes, I see. It is a difficult situation. It looks like your patch is the only way to make this non-standard controller work. Go ahead and post an updated version that doesn't test the wrong wakeup setting. Since this change affects only the chipidea driver, it should be acceptable. 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
