From: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
To: "John Youn" <John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>,
"Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
"Greg Kroah-Hartman"
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Cc: "linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v5 3/3] usb: dwc2: Properly account for the force mode delays
Date: Thu, 15 Sep 2016 09:08:25 +0200 [thread overview]
Message-ID: <ad02126f-6c0e-9216-f7ab-ec528eeda2e2@i2se.com> (raw)
In-Reply-To: <6b0c9143-63b3-c5c3-7122-bbbb0c9f610b-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hi John,
[add Felipe and Greg]
Am 14.09.2016 um 23:10 schrieb John Youn:
> On 9/14/2016 7:05 AM, Heiko Stübner wrote:
>> Am Dienstag, 13. September 2016, 12:04:12 schrieb John Youn:
>>> On 9/13/2016 11:39 AM, Heiko Stübner wrote:
>>>> Am Dienstag, 13. September 2016, 20:07:25 schrieb Stefan Wahren:
>>>>> Hi Heiko,
>>>>>
>>>>>> Heiko Stuebner <heiko@sntech.de> hat am 12. September 2016 um 13:05
>>>>>> geschrieben:
>>>>>>
>>>>>>
>>>>>> Hi Stefan,
>>>>>>
>>>>>> Am Montag, 12. September 2016, 07:20:44 CEST schrieb Stefan Wahren:
>>>>>>>> Heiko Stuebner <heiko@sntech.de> hat am 11. September 2016 um 23:19
>>>>>>>> geschrieben:
>>>>>>>>
>>>>>>>> Am Mittwoch, 7. September 2016, 19:39:43 CEST schrieb John Youn:
>>>>>>>>> When a force mode bit is set and the IDDIG debounce filter is
>>>>>>>>> enabled,
>>>>>>>>> there is a delay for the forced mode to take effect. This delay is
>>>>>>>>> due
>>>>>>>>> to the IDDIG debounce filter and is variable depending on the
>>>>>>>>> platform's
>>>>>>>>> PHY clock speed. To account for this delay we can poll for the
>>>>>>>>> expected
>>>>>>>>> mode.
>>>>>>>>>
>>>>>>>>> On a clear force mode, since we don't know what mode to poll for,
>>>>>>>>> delay
>>>>>>>>> for a fixed 100 ms. This is the maximum delay based on the slowest
>>>>>>>>> PHY
>>>>>>>>> clock speed.
>>>>>>>>>
>>>>>>>>> Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>> Signed-off-by: John Youn <johnyoun@synopsys.com>
>>>>>>>>> ---
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> @@ -475,12 +478,6 @@ void dwc2_force_dr_mode(struct dwc2_hsotg
>>>>>>>>> *hsotg)
>>>>>>>>>
>>>>>>>>> __func__, hsotg->dr_mode);
>>>>>>>>>
>>>>>>>>> break;
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> - /*
>>>>>>>>> - * NOTE: This is required for some rockchip soc based
>>>>>>>>> - * platforms.
>>>>>>>>> - */
>>>>>>>>> - msleep(50);
>>>>>>>>>
>>>>>>>>> }
>>>>>>>> sorry for not finding the time to test your subsequent versions, but
>>>>>>>> this
>>>>>>>> still
>>>>>>>> acts up on my Rockchip boards, as I'm still running into errors like
>>>>>>>>
>>>>>>>> [ 4.875570] usb usb2-port1: connect-debounce failed
>>>>>>> could you please name the relevant DTS file of the affected boards?
>>>>>> So far I've been able to see that on
>>>>>>
>>>>>> rk3188-radxarock
>>>>>> rk3036-kylin
>>>>>>
>>>>>> both on host-only dwc2 controllers.
>>>>> thanks, does patch 1 & 2 already have a negative effect on these
>>>>> controllers?
>>>> nope, patches 1+2 alone are ok and only the msleep(50) going away causes
>>>> problems. I'm back home now, so I'll hopefully have time to check
>>>> host-only
>>>> vs. otg dwc2 controllers tomorrow as well.
>>> Ok, thanks for testing Heiko.
>>>
>>> Given that, let's try to fix this in the next -rc (or before) because
>>> I think the Raspberry Pi needs the other parts of that last patch. We
>>> can just revert the msleep(50) if needed.
>> I could nicely confirm, that only the host-only controller seems affected by
>> this. Same kernel image that fails on the host-only one with the "connect-
>> debounce failed" message seems to work once I switch that over to the otg
>> controller and the system comes up nicely again.
>>
>> So if we don't find the root cause in the short term, maybe we could at least
>> limit the delay for host-only variants, like
>>
>> ---------------------- 8< -------------------
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>> index fa9b26b..4c0fa0b 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -463,9 +463,18 @@ static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
>> */
>> void dwc2_force_dr_mode(struct dwc2_hsotg *hsotg)
>> {
>> + bool ret;
>> +
>> switch (hsotg->dr_mode) {
>> case USB_DR_MODE_HOST:
>> - dwc2_force_mode(hsotg, true);
>> + ret = dwc2_force_mode(hsotg, true);
>> + /*
>> + * NOTE: This is required for some rockchip soc based
>> + * platforms on their host-only dwc2.
>> + */
>> + if (!ret)
>> + msleep(50);
>> +
>> break;
>> case USB_DR_MODE_PERIPHERAL:
>> dwc2_force_mode(hsotg, false);
>> ---------------------- 8< -------------------
>>
>> I've been running with that change for some time now on both the
>> rk3036-kylin and rk3188-radxarock. Plugged and unplugged different
>> combinations of usb-devices on the usb otg and host ports, so far
>> seems to work.
>>
> Ok great. We'll use that for the -rc if we can't find the root cause.
>
> Then hopefully we can apply the final dropped patch for 4.10.
unfortunately i noticed too late that Felipe and Greg didn't get the
whole conversation. The series v5 has been merged in Greg's USB tree.
Stefan
>
> Regards,
> John
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2016-09-15 7:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1473302184.git.johnyoun@synopsys.com>
[not found] ` <b4aac4b197241b8199c5300656d245692eb45856.1473302184.git.johnyoun@synopsys.com>
[not found] ` <b4aac4b197241b8199c5300656d245692eb45856.1473302184.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
2016-09-11 21:19 ` [PATCH v5 3/3] usb: dwc2: Properly account for the force mode delays Heiko Stuebner
2016-09-12 5:20 ` Stefan Wahren
[not found] ` <1336050364.27663.591ba3c4-a2b5-418f-9999-6b3cd631f440.open-xchange-7tX72C7vayboQLBSYMtkGA@public.gmane.org>
2016-09-12 11:05 ` Heiko Stuebner
2016-09-13 18:07 ` Stefan Wahren
[not found] ` <19473401.122600.97acfbc9-df96-4427-b533-911010ce5c3f.open-xchange-7tX72C7vayboQLBSYMtkGA@public.gmane.org>
2016-09-13 18:39 ` Heiko Stübner
2016-09-13 19:04 ` John Youn
[not found] ` <97a3539d-7176-086f-71f9-371d8d4b016c-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
2016-09-14 14:05 ` Heiko Stübner
2016-09-14 21:10 ` John Youn
[not found] ` <6b0c9143-63b3-c5c3-7122-bbbb0c9f610b-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
2016-09-15 7:08 ` Stefan Wahren [this message]
[not found] ` <ad02126f-6c0e-9216-f7ab-ec528eeda2e2-eS4NqCHxEME@public.gmane.org>
2016-09-15 19:39 ` John Youn
2016-09-16 2:16 ` John Youn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ad02126f-6c0e-9216-f7ab-ec528eeda2e2@i2se.com \
--to=stefan.wahren-es4nqchxeme@public.gmane.org \
--cc=John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org \
--cc=felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox