This patch adds disable usb2 suspend phy quirk for rk3399 platform.
TEST=Plug in USB-C HUB, then do suspend_stress_test;
Plug in Yubico/Gnubby security key, check if it can
work normally.
Change-Id: I98f344d9fb47baa892f7653ca43dad2b581611f9
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
In 4 lane dp mode, the dwc3 controller need to config to usb2.0
only mode, while the dwc3 controller must finish config between usb3.0
and usb2.0 only mode, otherwise if will be failed when connect with usb
device. In current code, the config process is done in typec phy init
function, and is called durling dwc3 controller init, so it is too late
for dwc3 controller to config. This patch config usb2.0 only mode when
usb phy power on and config to usb3.0 when usb phy power off if it is
dp mode only. Finish change to usb3.0 before dwc3 controller reinit to
usb3.0 mode.
Change-Id: Iad69dc730408a88bb5f3b9d9bd366754f82db182
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
The queues the the dwc2 host controller used are truly queues. That
means FIFO or first in first out.
Unfortunately though the code was iterating through these queues
starting from the head, some places in the code was adding things to the
queue by adding at the head instead of the tail. That means last in
first out. Doh.
Go through and just always add to the tail.
Doing this makes things much happier when I've got:
* 7-port USB 2.0 Single-TT hub
* - Microsoft 2.4 GHz Transceiver v7.0 dongle
* - Jabra speakerphone playing music
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
(cherry picked from commit 94ef7aee11)
Change-Id: Idf0f468b0e849698a637548f9520b9965368ef35
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
When dwc3 core enters into suspend mode, the system (especially for mobile
device) may power off the dwc3 controller for power saving, that will cause
dwc3 controller lost the mode operation when resuming dwc3 core.
Thus we can move the mode setting into dwc3_core_init() function to avoid this
issue.
Change-Id: I2999291d8f6632e02ceba35d957f7129e18919e6
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 00af62330c)
We found a bug that i2c transfer sometimes failed on 3066a board with
stabel-4.8, the con register would be updated by uninitialized tuning
value, it made the i2c transfer failed.
So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
Change-Id: I8686b8525e7fc8adc896f60dec4ae74d6c2a173c
Signed-off-by: David Wu <david.wu@rock-chips.com>
Tested-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
For rockchip serial, received data available and character timeout
interrupts are both enabled by IER[0]. Then when there is data in
the FIFO, received data available interrupt will occurd frequently.
So we must disable it, but which may disable the character timeout
interrput. Then it is useful to add a timer to report the data received
in dma buffer every 10 microsecond.
Change-Id: I1cf9dee495453d3530ab66c95a4e4cfef46b7795
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
For rockchip serial, received data available and character timeout
interrupts are both enabled by IER[0]. Then when there is data in
the FIFO, received data available interrupt will occurd frequently.
So we must disable it, but which may disable the character timeout
interrput. Then it is useful to add a timer to report the data received
in dma buffer every 10 microsecond.
Change-Id: I6530b17800435b288a7309bb5998176decb94297
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
Change the configs for RAYKEN 5.46' lcd which is defaultly used for
discrete vr lcd.
Change-Id: I3894697367229ea059b9200fd2ad5aac8781b7df
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>
We should also Disable vbus-5v gpio control in retulator node,otherwise
vbus-5v will always power on.
Change-Id: Icb42f687866174398917ced3e53a3e876ea37b86
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>
Consider two devices, A and B, where B is a child of A, and B utilizes
asynchronous suspend (it does not matter whether A is sync or async). If
B fails to suspend_noirq() or suspend_late(), or is interrupted by a
wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
variable. However, device A does not (immediately) check the async_error
variable; it may continue to run its own suspend_noirq()/suspend_late()
callback. This is bad.
We can resolve this problem by checking the async_error flag after
waiting for children to suspend, using the same logic for the noirq and
late suspend cases as we already do for __device_suspend().
It's easy to observe this erroneous behavior by, for example, forcing a
device to sleep a bit in its suspend_noirq() (to ensure the parent is
waiting for the child to complete), then return an error, and watch the
parent suspend_noirq() still get called. (Or similarly, fake a wakeup
event at the right (or is it wrong?) time.)
Change-Id: I9f6d9a599b45aaeb2debccc50a47525f138ad07e
Fixes: de377b3972 ("PM / sleep: Asynchronous threads for suspend_late")
Fixes: 28b6fd6e37 ("PM / sleep: Asynchronous threads for suspend_noirq")
Reported-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
The printouts writen to the logs by suspend can be a bit opaque: it can
be hard to track them down to the actual function called. You might
see:
calling rfkill1+ @ 19473, parent: phy0
call rfkill1+ returned 0 after 1 usecs
calling phy0+ @ 19473, parent: mmc2:0001:1
call phy0+ returned 0 after 19 usecs
It's a bit hard to know what's actually happening. Instead, it's nice
to see:
calling rfkill1+ @ 15793, parent: phy0, cb: rfkill_suspend
call rfkill1+ returned 0 after 1 usecs
calling phy0+ @ 15793, parent: mmc2:0001:1, cb: wiphy_suspend [cfg80211]
call phy0+ returned 0 after 7 usecs
That makes it very obvious what's going on. It also has the nice side
effect of making the suspend/resume spew a little more obvious, since
many resume functions have the word "resume" in the name:
calling phy0+ @ 15793, parent: mmc2:0001:1, cb: wiphy_resume [cfg80211]
call phy0+ returned 0 after 12 usecs
calling rfkill1+ @ 15793, parent: phy0, cb: rfkill_resume
call rfkill1+ returned 0 after 1 usecs
Change-Id: I32dcedfa013393aab79af852304c7d9f3465f183
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Add usb super speed,support dp 4 lanes and usb2.0 function.
Also add power domain control function and optimize the logic
of dp recognizing flow.And also change the logic of dp suspend,
the clock of dp will be disabled after early suspend, and enabled
after early resume by trigger a hotplug event.
Change-Id: I917d0d34b0909373ba037c62b3582893d7dce00b
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>
Add the sensor node "power-off-in-suspend" to support sensor poweroff in
system suspend.
Change-Id: Ic0dc660f0211b7dd18ba8fec6d54aba5b1dfc301
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
For some sensors are designed to support poweroff when system suspend,
so we need reinit register when system resume.
Change-Id: I4d61dc318562336781aa1010d1fbad447cc76b83
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
If the expected number of FTS aren't received by RC when exiting from L0s,
the LTSSM will fall into recover state, which means it will need to send TS
for retraining which makes the latency of exiting from L0s a little longer
than expected. This issue is caused by an incorrect reset value of FTS
count on PLC1 register (offset 0x4). The expected value for Gen1/2 should
be more than 240 and we may leave a little margin here. Fix this before
starting Gen1 training which will make TS1 contain the correct FTS count.
Change-Id: I15543b385fdb7a007187faf51265c591c51433e6
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit ca19890840)
Per TRM, we need to deassert the four reset pins simultaneously.
Currently the reset framework doesn't support that so we did it
one by one. It seems no side effect found but it does impact the
state machine of controller, so sometimes the change speed bit is
not setted when sending training sequence from recover state.
After the silicon RTL review from Soc guys, we don't need to do
the sequence recommended by TRM, and could just move the deassert
of mgmt_sticky_rst to the first place.
Change-Id: I001f3707054af98b147cb1d56b1a03e5f7d44ceb
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 58c6990c5e)
Without supporting clock PM capable, if we want to disable
clkpm, we don't need this extra check as it already be zero for
the enable argument. And it's the same for enabling clkpm here.
So let's remove this check.
Change-Id: I0dc251e5dea940a2288fbb31a58336dea83f2515
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit a6c1c6f354)
This increases the likelihood of link state to automatically go to L1
and save some power.
The default credit update interval of 7.5 us results in the rootport
sending UpdateFC-P and UpdateFC-NP packets too often, thus resulting
in the link never going to L1, and always staying in L0/L0s. The
value 24 us was chosen after some experiments and peeking over the
PCIe bus to see that we do enter L1 substate when there is not enough
traffic on the PCIe bus.
Change-Id: I23eccba98f6fe731bcacec80349dc05bd7baf9c1
Signed-off-by: Rajat Jain <rajatja@google.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 277743ef61)
Bjorn did some cleanup for rockchip pcie driver after
mereging the drivers. So let's backport it entirely
to keep consisten with the upstream kernel.
[bhelgaas: fold in Brian's rockchip_pcie_client_irq_handler() OR fix, other
fixes and cleanups from Guenter Roeck <linux@roeck-us.net> and me,
uninitialized variable fix from Arnd Bergmann <arnd@arndb.de>]
Change-Id: If680b9c2264cd89561427180b146c34eb8549511
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
The pixel clock of 4K@60Hz is 594MHz, let's enable it for HDMI.
Change-Id: I6097c8a452ba8259c1d8d01fb793cd7cc55cafb3
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
The max output resolution of VOP Little is 2K, but VOP Big could support
4K output. For now we need support HDMI 4K display, so let force VOP Big
to HDMI, and VOP Little to eDP
Change-Id: Ic493fcb2ee29c3deda0fe5437aab46e271f3689b
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
If extcon cable state is EXTCON_USB_VBUS_EN, it also means
that otg host connected, don't need to do charge detection.
Change-Id: Ie7c97c4cd0cfd2688edbfb3bbff93d2f58e9ef9a
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Set extcon cable state to EXTCON_USB_VBUS_EN instead of
EXTCON_USB_HOST when enable vbus 5v. Because EXTCON_USB_HOST
state means that fusb302 has detected Type-C mode and the
orientation. However, enable vbus is prior to Type-C mode
and orientation detection. If we set EXTCON_USB_HOST state
when power on vbus, it may cause usb controller driver to
receive the state prematurely, and do tcphy orientation init
improperly.
Change-Id: Id65072dc8235693db44667ee5d2ceac74dc94920
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
In usb3 tcphy init, it will access usb3 module to set
usb3 working on USB3.0 mode or USB2.0 only mode, and
usb3 pd must be enabled before do this operation. So
we add pm runtime control for dwc3 parent in extcon
evt work. If plug in usb device, resume dwc3 parent
first to enable usb3 pd and then do phy init.
Change-Id: I90dd762d7f76e5f1722c95611e440eacd3afcdc9
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
If the buffer alloced from the ion, user can flush
it by ion apis, but if the buffer was alloced by
other apis like malloc, user space is not easy to
flush the data cache. So rga flush the data cache
for cache coherence.
Change-Id: I5fcfc3e00c6a8f6b12ed66043b37b0c7c840e7ee
Signed-off-by: Zikim,Wei <wzq@rock-chips.com>
This reverts commit ccc954ee9f.
In current code, the dwc3 controller will not process notify when it is
in suspend state and this forbid extcon remove hcd before xhci resume, so
we do not need to forbid remove hcd by the hcd runtime flag and it is
difficult to deal with different process when connected with some special
usb storage.
Change-Id: I987862cceb4ffbe8deefb503f6bc4009770e87bd
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
The max output resolution of vopl is 2K, but vopb could support
4K output. For now we need support HDMI 4K display, so let force
VOP Big to HDMI.
Change-Id: Id095d3659554988f7647fb27d415652fbf510b14
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
