Re: [PATCH 18/18] usb: dwc2: Reduce delay when forcing mode in reset

[John Youn]

On 12/9/2015 8:45 PM, Doug Anderson wrote:
> John,
> 
> On Wed, Dec 2, 2015 at 11:15 AM, John Youn  wrote:
>> The delay for force mode is only 25ms according to the databook.
>>
>> Signed-off-by: John Youn 
>> ---
>>  drivers/usb/dwc2/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>> index 91d63a8..a6fddbf 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -552,7 +552,7 @@ int dwc2_core_reset_and_force_mode(struct dwc2_hsotg 
>> *hsotg)
>>  * NOTE: This long sleep is _very_ important, otherwise the core will
>>  * not stay in host mode after a connector ID change!
>>  */
>> -   usleep_range(15, 16);
>> +   usleep_range(25000, 5);
> 
> This seems to work for me.  At least I've done reboots and not noticed
> any problems.  :-P
> 
> Personally I'd suggest tightening the range to something like (25000,
> 3) or even replacing with "msleep(25)".  From past experience I've
> found that usleep_range() nearly always picks the largest value you
> gave it.  That's supposed to be for power savings for things you do
> all the time.  For a rare thing like a reset it's just a waste of
> time.

I'm not sure why it was usleep_range or why the delay was so large. I
was being conservative in the change but I think I'll change it as you
suggest to msleep(25) and if issues come it we can deal with them.

Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 18/18] usb: dwc2: Reduce delay when forcing mode in reset

[Doug Anderson]

John,

On Wed, Dec 2, 2015 at 11:15 AM, John Youn  wrote:
> The delay for force mode is only 25ms according to the databook.
>
> Signed-off-by: John Youn 
> ---
>  drivers/usb/dwc2/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 91d63a8..a6fddbf 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -552,7 +552,7 @@ int dwc2_core_reset_and_force_mode(struct dwc2_hsotg 
> *hsotg)
>  * NOTE: This long sleep is _very_ important, otherwise the core will
>  * not stay in host mode after a connector ID change!
>  */
> -   usleep_range(15, 16);
> +   usleep_range(25000, 5);

This seems to work for me.  At least I've done reboots and not noticed
any problems.  :-P

Personally I'd suggest tightening the range to something like (25000,
3) or even replacing with "msleep(25)".  From past experience I've
found that usleep_range() nearly always picks the largest value you
gave it.  That's supposed to be for power savings for things you do
all the time.  For a rare thing like a reset it's just a waste of
time.

In any case, up to you.  What yo have is certainly better than what was there.

This is tested on some rk3288-based devices with a 3.14 kernel.

Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 18/18] usb: dwc2: Reduce delay when forcing mode in reset

[John Youn]

The delay for force mode is only 25ms according to the databook.

Signed-off-by: John Youn 
---
 drivers/usb/dwc2/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 91d63a8..a6fddbf 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -552,7 +552,7 @@ int dwc2_core_reset_and_force_mode(struct dwc2_hsotg *hsotg)
 * NOTE: This long sleep is _very_ important, otherwise the core will
 * not stay in host mode after a connector ID change!
 */
-   usleep_range(15, 16);
+   usleep_range(25000, 5);
 
return 0;
 }
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html