Bind / unbind stress testing of the USB controller on rk3399 found
that we'd often end up with lots of failures that looked like this:
phy phy-ff800000.phy.9: phy poweron failed --> -110
dwc3 fe900000.dwc3: failed to initialize core
dwc3: probe of fe900000.dwc3 failed with error -110
Those errors were sometimes seen at bootup too, in which case USB
peripherals wouldn't work until unplugged and re-plugged in.
I spent some time trying to figure out why the PHY was failing to
power on but I wasn't able to. Possibly this has to do with the fact
that the PHY docs say that the USB controller "needs to be held in
reset to hold pipe power state in P2 before initializing the Type C
PHY" but that doesn't appear to be easy to do with the dwc3 driver
today. Messing around with the ordering of the reset vs. the PHY
initialization in the dwc3 driver didn't seem to fix things.
I did, however, find that if I simply retry the power on it seems to
have a good chance of working. So let's add some retries. I ran a
pretty tight bind/unbind loop overnight. When I did so, I found that
I need to retry between 1% and 2% of the time. Overnight I found only
a small handful of times where I needed 2 retries. I never found a
case where I needed 3 retries.
I'm completely aware of the fact that this is quite an ugly hack and I
wish I didn't have to resort to it, but I have no other real idea how
to make this hardware reliable. If Rockchip in the future can come up
with a solution we can always revert this hack. Until then, let's at
least have something that works.
This patch is tested atop Enric's latest dwc3 patch series ending at:
https://patchwork.kernel.org/patch/10095527/
...but it could be applied independently of that series without any
bad effects.
For some more details on this bug, you can refer to:
https://bugs.chromium.org/p/chromium/issues/detail?id=783464
Change-Id: I7909731247739694f56bf89ab3064889f2b34d3c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(am from https://patchwork.kernel.org/patch/10105833/)
We found that some Sonix usb cameras(e.g. idVendor=0c45,
idProduct=64ab or idProduct=64ac) can't support auto-suspend
well on rockchip platforms(e.g. rk3399).With auto-suspend,
these usb cameras MJPEG will display abnormally on all usb
controllers(DWC2/DWC3/EHCI). So we need to disable auto-
suspend for these special usb cameras.
Change-Id: I08c87cf5c9fa5ebe076b5dd3e873b74c5ec2cb83
Signed-off-by: William Wu <william.wu@rock-chips.com>
The commit 62b2a34a21 ("uvcvideo: add quirk for devices
with broken auto suspend") introduced quirk to workaround
an issue with some HD Cameras.
There is one more model that has the same issue - idProduct
=0x9320, so applying the same quirk as well.
Change-Id: I24e3fc1746a9d21d529bc91f52fd5822e998bd93
Signed-off-by: William Wu <william.wu@rock-chips.com>
We found that some usb cameras(e.g. Manufacturer: HD Camera
Manufacturer, idVendor=05a3, idProduct=9230) can't support
auto-suspend well on rockchip platforms. With auto-suspend,
these usb cameras MJPEG will display abnormally on all usb
controllers(DWC2/DWC3/EHCI). So we need to disable auto
suspend for these special usb cameras.
Change-Id: Ibf50ed77edff0012a112dc42f09e022055908829
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
The xhci hcd use the port polling timer (rh_timer) to poll the
roothub for port events. But we can't allow the USB core to poll
the port events during shutdown because the xhci controller may
be disable and can't be accessed in shutdown. If we access xhci
port registers with port polling timer after xhci shutdown, it
may cause kernel crash or unexpected behavior. So we need to stop
the port polling timer while shutdown xhci.
I can easily reproduce the issue on rk3399 platform, plug in a
Type-C hub and an USB ethernet dongle, then do reboot test,
result in a crash with the following backtrace.
Unhandled fault: synchronous external abort (0x96000010) at 0xffffff80002f0430
Internal error: : 96000010 [#1] PREEMPT SMP
task: ffffffc001092cb0 ti: ffffffc00107c000 task.ti: ffffffc00107c000
PC is at xhci_hub_status_data+0xec/0x1e4
LR is at xhci_hub_status_data+0xb0/0x1e4
[<ffffffc00067a210>] xhci_hub_status_data+0xec/0x1e4
[<ffffffc00063ebf8>] usb_hcd_poll_rh_status+0x54/0x148
[<ffffffc00063ed0c>] rh_timer_func+0x20/0x2c
[<ffffffc0002845cc>] call_timer_fn+0xa4/0x1c8
[<ffffffc000284964>] run_timer_softirq+0x248/0x2cc
[<ffffffc000200928>] __do_softirq+0x178/0x338
[<ffffffc000224b08>] irq_exit+0x78/0xc0
[<ffffffc00027089c>] __handle_domain_irq+0x9c/0xbc
[<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188
BUG=chrome-os-partner:59111
TEST=Plug in a Type-C hub, then do reboot test, check if
kernel crash during shutdown.
Change-Id: I3ca3d12d101241cd78138ea5d995708a2893d1a0
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401121
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
On some sepcial platforms (e.g. rk3399 platform), they will call
usb_remove_hcd() to remove xhci hcd if no device connected, and
also call xhci_stop() to halt and reset xhci. So we don't need to
do the same thing in shutdown if hcd has been unregistered.
In addition to remove hcd, rk3399 platform will disable xhci power
domain in runtime suspend, if we try to access xhci registers in
shutdown, it might cause kernel crash or unexpected behavior.
BUG=chrome-os-partner:59111
TEST=reboot the system
Change-Id: I7ecfce068211ff1c4a884fc4a8a54ca5b84c1c09
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401120
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
The xhci driver provides xhci_shutdown() to be called with the main
usb_hcd (the USB3 roothub) while do reboot. But actually, xhci-plat
never call xhci_shutdwon() during reboot because it doesn't use the
usb_hcd_platform_shutdown() helper.
So we use the usb_hcd_platform_shutdown() for xhci-plat, and the
normal shutdown call trace is:
kernel_restart -> kernel_restart_prepare -> device_shutdown ->
platform_drv_shutdown -> usb_hcd_platform_shutdown -> xhci_shutdown
BUG=chrome-os-partner:59111
TEST=reboot the system
Change-Id: I9be424257ea6ba1e51521cbdd01f4698ae1752ad
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401119
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Due to the u2phy registers are separated from general grf, we need to
add u2phy grf node and place u2phy node in it. And on some platform,
the 480m clock may need to assign clock parent in dts in stead of
clock driver. So this patch add u2phy grf node and property of
assigned-clocks and assigned-clock-parents to assign parent for 480m
clock.
Change-Id: I88e63745e38265814169136f079a00791f5813b3
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
In current code, the connect status will be set to connected state when
reset interrupt occur and change to disconnected state in disconnect
interrupt.
But the usb charger may bring about reset signal in accident if we
connect and disconnect quickly. In this case, the dwc3 controller will
change link state and set to connect status, yet not change to
disconnected state when disconnect. So the dwc3 controller suspend
fail and result in a mistake when quick reconnect.
This patch set connect status to connected state when transfer complete
to make sure that usb is connect to PC exactly.
Change-Id: I8e5894d2e08b88bb5434222100d8f5c91c9f1a9d
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
Set charge current according to bat temperature and
the v1 is abandoned on kernel 4.19.
Change-Id: I6462e5de1c153c7f774136ef67a8a17a3c7fec8a
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Set charge current according to bat temperature.
Change-Id: I409bf33614c9e689f7a85382d6033af6b18755e1
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
This video codec driver used in kernel 4.19 version,
which is a new design framework.
In this version, codecs integrate similar hardware,
so are divided into vdpux vepux rkvdec rkvenc vepu22,
and so on.
Change-Id: Ic29b28cef8fce394ac9f950472204c172842a2df
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
RK816 has 1 pin to be used as GPIO or TS function.
When used as GPIO function, the pin can be output or input.
Change-Id: I8607595826ac3125dfa2a4c7c483be6b084204c2
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
The i2c maybe stopped before pm_power_off() is called, which
results in the PMIC power off failure issue.
Moving PMIC power off operation to syscore shutdown is better.
Change-Id: Ib43827ebd49059719b8899f90a696b6c32a6ddd1
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
This setting will be added by ddr binary when necessary to
handle the high temperature-voltage issue on BUCK3.
Change-Id: Ief7d4954e459317ae571400496c4c5ef74f664af
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Show the reason of this power on and last shutdown.
Change-Id: Id540433065859a0c3f4817ed66e295b7c6dfccb5
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
The registers relative with fuel gauge must be volatile.
Change-Id: I8e942e8f15f66dabf24ede48b81857947575fa23
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Because the default frequency is 300M will cause green horizontal
stripes when in 4K resolution zoom mode:
Change-Id: Ia571e8eb32ba62ee3e3857e2a1ee3187a14e408f
Signed-off-by: Alex Wang <alex.wang@rock-chips.com>
From u-boot 5e817a0ea427 ("tools: rockchip: resource_tool: add sha1 for file entry").
Merge all C files to one resource_tool.c
Change-Id: If63ba77d1f5a3660bd6ef87769bb456fa086ae71
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
On an eDP connection, the eDP sink must operate only in Enhanced Framing Mode.
The Source must send only Enhanced Framing on the main link, and must only
write a '0' to DPCD 00101h: LANE_COUNT_SET Bit 7: ENHANCED_FRAME_EN bit.
Independent of method used, DP1.2-compliant eDP Receivers shall indicate any
eDP protocol differentiation method they support through the Receiver
Capability Field of DPCD (DPCD:0000Dh).
Change-Id: Ia57f3242c16e2ace0c13076992c2c14eda9e7ca7
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
DP firmware uses fixed phy config values to do training, but some
boards need to adjust these values to fit for their unique hardware
design. So get phy config values from dts and use software link training
instead of relying on firmware, if software training fail, keep firmware
training as a fallback if sw training fails.
Change-Id: I075bff6aa153a5e18b6a5ddec2645131f1411913
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
