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
On Tue, Dec 30, 2014 at 10:16:39AM -0500, Alan Stern wrote:
On Tue, 30 Dec 2014, Peter Chen wrote:
On Mon, Dec 29, 2014 at 10:44:28AM -0500, Alan Stern wrote:
On Mon, 29 Dec 2014, Peter Chen wrote:
For chipidea, its resume sequence is not-EHCI compatible, see
below description
On Wed, 31 Dec 2014, Peter Chen wrote:
The only solution I can think of is not very satisfactory. Suppose the
controller doesn't send any SoF packets within 3 ms of getting a wakeup
signal. Then the device will go back into suspend. Later on, when the
controller starts running, the
On Tue, 30 Dec 2014, Peter Chen wrote:
On Mon, Dec 29, 2014 at 10:44:28AM -0500, Alan Stern wrote:
On Mon, 29 Dec 2014, Peter Chen wrote:
For chipidea, its resume sequence is not-EHCI compatible, see
below description for FPR at portsc. So in order to send SoF in
time for remote
On Mon, 29 Dec 2014, Peter Chen wrote:
For chipidea, its resume sequence is not-EHCI compatible, see
below description for FPR at portsc. So in order to send SoF in
time for remote wakeup sequence(within 3ms), the RUN/STOP bit must
be set before the resume signal is ended.
Force Port
On Mon, Dec 29, 2014 at 10:44:28AM -0500, Alan Stern wrote:
On Mon, 29 Dec 2014, Peter Chen wrote:
For chipidea, its resume sequence is not-EHCI compatible, see
below description for FPR at portsc. So in order to send SoF in
time for remote wakeup sequence(within 3ms), the RUN/STOP bit
