> You should use a sleeping function call, not a delay.
Whoops... yes, of course. Guess too much firmware work made me forget
what multithreading is there for a moment. Will send a v2.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
You should use a sleeping function call, not a delay.
Whoops... yes, of course. Guess too much firmware work made me forget
what multithreading is there for a moment. Will send a v2.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Fri, 23 Jan 2015, Julius Werner wrote:
> The EHCI controller on the RK3288 SoC is violating basic parts of the
> USB spec and thereby unable to properly resume a suspended port. It does
> not start SOF generation within 3ms of finishing resume signaling, so
> the attached device will drop off
On Fri, 23 Jan 2015, Julius Werner wrote:
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop off the
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop off the bus again. This is a particular
problem with
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop off the bus again. This is a particular
problem with
6 matches
Mail list logo
