Hi,
Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> writes:
>> > I tested here, together with the Hikey 970 phy RFC patches I sent
>> > last week.
>> >
>> > Without this patch, the USB HID driver receives -EPROTO from
>> > submitted URBs, causing it to enter into an endless reset cycle
>> > on every 500 ms, at the hid_io_error() logic.
>>
>> > Tested-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx>
>> >
>> > If you prefer, I can re-submit this one with my SOB.
>>
>> Please do, but since you're changing device tree, I need Rob's acked-by.
>
> Ok, I'll do that.
thanks
>> > Em Sat, 20 Apr 2019 14:40:10 +0800
>> > Yu Chen <chenyu56@xxxxxxxxxx> escreveu:
>> >
>> >> SPLIT_BOUNDARY_DISABLE should be set for DesignWare USB3 DRD Core
>> >> of Hisilicon Kirin Soc when dwc3 core act as host.
>>
>> is this Kirin-specific or is this something that we should do a revision
>> check?
>
> I've no idea. I don't have any datasheets from this device.
I see
>> Why does it affect only Hikey kirin?
>
> As John Stultz didn't re-submit this one (and looking at the DT
> between Kirin 960 and 970 from the original Kernel 4.9 official
> drivers), I suspect that only Kirin 970 requires this quirk.
>
> It could well be due to some Dwc3 revision, but it could also be due
> to some differences at the USB part of the SoC, as there are a
the reason I ask is that if it's caused by dwc3 revision, then we don't
need the extra dt property, we can rely on a revision check. If it's
something that can't be detected in runtime, then we need a property.
> few other things different between hikey 960 and 970: it has a
> different PHY driver, and there are also some differences at the
> USB HUB which is connected into it.
>
> On both devices, the USB physical ports are actually connected
> into a HUB. In the case of Hikey 970, the hub seems to be a
> TI TUSB8041 4-Port Hub:
>
> $ lsusb
> Bus 002 Device 002: ID 0451:8140 Texas Instruments, Inc. TUSB8041 4-Port Hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 004: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
> Bus 001 Device 003: ID 413c:301a Dell Computer Corp. Dell MS116 Optical Mouse
> Bus 001 Device 002: ID 0451:8142 Texas Instruments, Inc. TUSB8041 4-Port Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>> What's the dwc3 revision on
>> that SoC (grep SNPSID /sys/kernel/debugfs/*dwc3/regdump)?
>
> GSNPSID = 0x33313130
This isn't even listed as a known revision in dwc3/core.h. Thinh, could
the issue being described here caused by a known Erratum with this
particular revision?
>> >> + reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
>> >> + reg |= DWC3_GUCTL3_SPLITDISABLE;
>> >> + dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
>> >> + }
>> >> +}
>> >> +#else
>> >> +#define dwc3_complete NULL
>> >> #endif /* CONFIG_PM_SLEEP */
>> >>
>> >> static const struct dev_pm_ops dwc3_dev_pm_ops = {
>> >> SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
>> >> + .complete = dwc3_complete,
>>
>> why is this done on complete? Why can't it be done at the end of
>> dwc3_resume()?
>
> Again, no idea. I didn't actually tried to suspend/resume.
>
> Maybe the original author can shed a light on it.
yeah, would be nice :-)
--
balbi
Attachment:
signature.asc
Description: PGP signature
