Re: [PATCH v2 1/1] phy: sun4i-usb: fix phy write on H3 and newer

[Evgeny Boger <boger@wirenboard.com>]

10.04.2022 07:36, Icenowy Zheng пишет:
>
> 于 2022年4月10日 GMT+08:00 下午12:28:25, Samuel Holland <samuel@sholland.org> 写到:
>> On 1/11/22 10:51 AM, Evgeny Boger wrote:
>>> We noticed that USB hosts won't reliably enumerate USB HS (480Mb/s) devices
>>> in our custom A40i-based design. What we observe is that after several
>>> attempts USB device would fail to enumerate on EHCI port (HS) and will be
>>> enumerated instead on OHCI (FS, 12Mb/s) only:
>>>
>>> [    6.368009] usb 1-1: new high-speed USB device number 5 using ehci-platform
>>> [    6.818008] usb 1-1: device not accepting address 5, error -71
>>> [    6.823868] usb usb1-port1: unable to enumerate USB device
>>> [    7.308013] usb 3-1: new full-speed USB device number 2 using ohci-platform
>>> [    7.575045] usb 3-1: not running at top speed; connect to a high speed hub
>>>
>>> On some boards one of the ports would work in high-speed mode, but
>>> on most of the boards all three USB ports would only work in FS mode.
>>>
>>> At the same time, USB work flawlessly in high-speed mode in vendor kernel.
>>>
>>> Looking for the differences in USB code, we found the issue with USB PHY
>>> register initialization. Basically, USB PHY driver sets a couple of
>>> internal undocumented PHY registers to the predefined constants. These PHY
>>> registers are accessed in a very (and I mean VERY) weird way by shifting
>>> register addresses and values bit-by-bit. This access method was slightly
>>> changed starting from H3 SoC, according to the BSP source for different
>>> SoCs.
>>>
>>> As a result, mainline PHY driver won't set these PHY registers properly
>>> resulting in unreliable enumeration in high-speed mode.
>>>
>>> We don't know whether this issue will result in broken HS mode on all
>>> affected SoCs or instead the A40i is an unfortunate exception. What we
>>> indeed verified, is that BSPs for all affected SoCs write these registers
>>> properly while mainline kernel don't. We also were able to reproduce the
>>> USB issue on a couple of A40i boards from other vendors, so we are pretty
>>> sure these registers have to always be properly set, regardlress of
>> typo: regardless
>>
>>> a hardware layout.
>>>
>>> The proposed patch is tested on A40i-based Wiren Board 7 building
>>> automation controller. More details are below.
>>>
>>> On older SoCs (prior to H3) PHY register are accessed by manipulating
>>> the common register for all PHYs. PHY index is specified by pulsing
>>> usbc bit.
>>>
>>> Newer SoCs leave the access procedure mostly unchanged, the
>>> difference being that the latch registers are separate for each PHY.
>>>
>>> Additionally, accessing USB PHY registers is only possible if phy0 is
>>> routed to musb IP instead of HCI.
>>>
>>> Introduce phy_reg_access_v2 cfg flag for H3 (H2+, H5),
>>> R40 (V40, A40i, T3), V3s (V3, S3) and A64 SoCs.
>>>
>>> On A83t, H6, H616, T507 and probably on more recent hardware,
>>> these PHY registers are not used in vendor BSP.
>>> So don't set v2 flag for these even newer SoCs as a precaution.
>>>
>>> Signed-off-by: Evgeny Boger <boger@wirenboard.com>
>> Tested-by: Samuel Holland <samuel@sholland.org> # A40i, H3
>>
>> I tested this patch on a Banana Pi M2 Berry (A40i) board. My board did not have
>> any USB reliability problems without this patch, but the patch didn't break
>> anything either. So since it fixes USB for you, the patch looks like a net
>> improvement.
>  From my memory, R40 OTG used to be broken.
>
> I may check whether this is fixed by this patch when I am back home (I am
> trapped in Shanghai because of COVID now).
Hi Icenowy,

I don't think OTG being broken has something to do with this patch.

Actually, on R40 USB OTG is implemented in the same way as on many other 
Allwinner SoCs: there are both HCI and OTG controllers for the first USB 
port and
there is a PHY which can route signals to either one.

Vendor kernel reroute signals to HCI controller whenever a host role is 
activated. The mainline kernel does the same, albeit in a very obscure way.

So enabling OTG on R40 is just a matter of adding a few lines to dtsi 
and, preferably, making a few modifications to phy code.

Could you please test OTG using our kernel tree: 
https://github.com/wirenboard/linux ?

There a few patches there waiting for being submitted which make it work.


>
>> And with Maxime's comments resolved:
>>
>> Reviewed-by: Samuel Holland <samuel@sholland.org>
>>



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel