On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
<m.szyprowski@xxxxxxxxxxx> wrote:
> Hi Krzysztof,
>
> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>
>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon <linux.amoon@xxxxxxxxx> wrote:
>>>
>>> On 24 January 2017 at 19:18, Richard Genoud <richard.genoud@xxxxxxxxx>
>>> wrote:
>>>>
>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>> the USB ports on odroid-XU4 don't work anymore.
>>>>
>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>> 20000 msec, port status = 0xc400fe3
>>>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
>>>> stop endpoint command.
>>>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>> host.
>>>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>>>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>>>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>> USB3.0 device (SATA to USB3 for instance).
>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>> realtek RTL8153 chip.
>>>>
>>>> If the lines:
>>>> if (dwc->revision > DWC3_REVISION_194A)
>>>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>> are commented out, the USB3.0 start working.
>>>>
>>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>>
>>>> Felipe suggested that suspend should be disabled temporarily while
>>>> what's wrong with DCW3 is figured out.
>>>>
>>>> Tested on Odroid XU4
>>>>
>>>> Suggested-by: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx>
>>>> Tested-by: Richard Genoud <richard.genoud@xxxxxxxxx>
>>>> Signed-off-by: Richard Genoud <richard.genoud@xxxxxxxxx>
>>>> Cc: stable@xxxxxxxxxxxxxxx # 4.4+
>>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>>> ---
>>>> arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>>>> 1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> @@ -43,6 +43,15 @@
>>>> status = "okay";
>>>> };
>>>>
>>>> +&usbdrd_dwc3_0 {
>>>> + /*
>>>> + * without that, usb devices are not recognized when
>>>> + * they are plugged.
>>>> + * cf: https://lkml.org/lkml/2017/1/18/678
>>>> + */
>>>> + snps,dis_u3_susphy_quirk;
>>>> +};
>>>> +
>>>> &usbdrd_dwc3_1 {
>>>> dr_mode = "host";
>>>> };
>>>> --
>>>
>>> Thanks for this patch.
>>> But could you consider moving this changes as below.
>>>
>>> https://lkml.org/lkml/2015/3/18/400
>>
>> The patch above (and other DTS patches from the set) was not even sent
>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>> disappear. Also, it is really worthless to solve the same problem
>> twice.
>
>
> Well, they were sent about 2 years ago... and you were also working on this
> topic. ;)
Nope, I have never worked on this. That time I was in Korea so my
tasks were completely different. Later when I got back, I took for a
second U3 OTG which was not involving this thing.
>> Cc Marek and Bartlomiej,
>> Guys, do you want to continue with Robert's patch (linked above by
>> Anand)? If yes, please take the ownership (Robert's address is not
>> valid anymore). If not, I will take Richard's patch after
>> resubmission.
>
>
> Take Richard's patch because it has a bit more details describing why such
> quirk
> is needed.
>
> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>
> Maybe it would make sense to set those quirks for both DWC3 controllers, as
> this
> issue with PHY suspend seems to be a Exynos specific thing.
Okay,
Richard, please continue with your patch.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
