Hi,
On Sat, Mar 5, 2016 at 12:41 PM, Michael Niewoehner
wrote:
> Hi Douglas,
> Hi John,
>
> Am 05.03.2016 um 01:33 schrieb Doug Anderson :
>
>> Michael,
>>
>> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner
>> wrote:
>
Hi,
On Sat, Mar 5, 2016 at 12:41 PM, Michael Niewoehner
wrote:
> Hi Douglas,
> Hi John,
>
> Am 05.03.2016 um 01:33 schrieb Doug Anderson :
>
>> Michael,
>>
>> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner
>> wrote:
> From testing and trying to make sense of the documentation, it
Hi Douglas,
Hi John,
Am 05.03.2016 um 01:33 schrieb Doug Anderson :
> Michael,
>
> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner
> wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is
Hi Douglas,
Hi John,
Am 05.03.2016 um 01:33 schrieb Doug Anderson :
> Michael,
>
> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner
> wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure
On 3/4/2016 10:23 AM, Douglas Anderson wrote:
> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent. Let's add it.
>
> In my testing (on rk3288) this allows us to
On 3/4/2016 10:23 AM, Douglas Anderson wrote:
> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent. Let's add it.
>
> In my testing (on rk3288) this allows us to
Hi,
On Fri, Mar 4, 2016 at 4:33 PM, Doug Anderson wrote:
> Michael,
>
> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner
> wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after
Hi,
On Fri, Mar 4, 2016 at 4:33 PM, Doug Anderson wrote:
> Michael,
>
> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner
> wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
Hi,
On Fri, Mar 4, 2016 at 3:46 PM, Karl Palsson wrote:
>> + /*
>> + * Sleep for 10-15 ms after the reset to let it finish.
>> + *
>> + * It's been confirmed on at least one version of the controller
>> + * that this is a requirement that this is a
Hi,
On Fri, Mar 4, 2016 at 3:46 PM, Karl Palsson wrote:
>> + /*
>> + * Sleep for 10-15 ms after the reset to let it finish.
>> + *
>> + * It's been confirmed on at least one version of the controller
>> + * that this is a requirement that this is a requirement in order
Michael,
On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner wrote:
>>> From testing and trying to make sense of the documentation, it appears
>>> that a 10 ms delay is needed after resetting the core to make sure that
>>> everything is stable and consistent. Let's add it.
Michael,
On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner wrote:
>>> From testing and trying to make sense of the documentation, it appears
>>> that a 10 ms delay is needed after resetting the core to make sure that
>>> everything is stable and consistent. Let's add it.
>>>
>>> In my testing
Hi Douglas,
Am 04.03.2016 um 23:54 schrieb Michael Niewoehner :
> Hi Douglas,
>
> Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
>
>> From testing and trying to make sense of the documentation, it appears
>> that a 10 ms delay is needed after
Hi Douglas,
Am 04.03.2016 um 23:54 schrieb Michael Niewoehner :
> Hi Douglas,
>
> Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
>
>> From testing and trying to make sense of the documentation, it appears
>> that a 10 ms delay is needed after resetting the core to make sure that
>>
Hello.
On 03/04/2016 09:23 PM, Douglas Anderson wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent. Let's add it.
In my testing (on rk3288) this allows us
Hello.
On 03/04/2016 09:23 PM, Douglas Anderson wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent. Let's add it.
In my testing (on rk3288) this allows us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Douglas Anderson wrote:
>
> + /*
> + * Sleep for 10-15 ms after the reset to let it finish.
> + *
> + * It's been confirmed on at least one version of the controller
> + * that this is a requirement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Douglas Anderson wrote:
>
> + /*
> + * Sleep for 10-15 ms after the reset to let it finish.
> + *
> + * It's been confirmed on at least one version of the controller
> + * that this is a requirement that this is a
Hi Douglas,
Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent. Let's add it.
>
> In my
Hi Douglas,
Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent. Let's add it.
>
> In my testing (on rk3288)
>From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent. Let's add it.
In my testing (on rk3288) this allows us to revert commit
192cb07f7928 ("usb: dwc2: Fix probe problem
>From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent. Let's add it.
In my testing (on rk3288) this allows us to revert commit
192cb07f7928 ("usb: dwc2: Fix probe problem
22 matches
Mail list logo