The buffer have been accessed by CPU needs to be synced
for the device to see the most up-to-date.
So introduce a flag here to see if a buffer need flush cache.
Change-Id: I68457aa528d04acc6f92dfa2171d8c807ab657a6
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
rk3328 dwc3 has a problem that USB 2.0 MAC lineState not
reflect the expected line state (J) during transmission.
Add this quirk to add the ipgap between (tkn to tkn/data)
with 40 bit times of TXENDDELAY, and linestate is ignored
during this 40 bit times delay.
Change-Id: I76895476bff94c2198a5d8df7e73b9d54fbb96ed
Signed-off-by: William Wu <william.wu@rock-chips.com>
rk3399 dwc3 has a problem that USB 2.0 MAC lineState not
reflect the expected line state (J) during transmission.
Add this quirk to add the ipgap between (tkn to tkn/data)
with 40 bit times of TXENDDELAY, and linestate is ignored
during this 40 bit times delay.
Change-Id: Ife9d46dbf2a8d4a8faa2fc20bfad442d6bb88a05
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).
On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.
(am from https://patchwork.kernel.org/patch/9684951/)
Change-Id: I6298f59a5b89a76a90c628a58c932942ede2c3ef
Signed-off-by: William Wu <william.wu@rock-chips.com>
For the usb31 IP and from version 2.90a of the usb3 IP, the core
supports HW exit from L1 in HS. Enable it, otherwise the controller may
never exit from LPM to do a transfer.
Conflicts:
drivers/usb/dwc3/core.c
drivers/usb/dwc3/core.h
Change-Id: I074d3ab2e386b872800e2c9898398d3696228527
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <wulf@rock-chips.com>
(cherry picked from commit 0bb39ca1ad)
Bootloader or kernel sets CPU frequency to an initial value before cpufreq
starts on rockchip platform, if cpu's opp table is modified to a specified
value, it will cause an issue.
For example, the initial frequency is 816MHz and voltage set by hardware
is 900mV:
1. there is only one opp whose frequency is 816MHz and voltage is 850mV
in opp table list, as they frequency is equal, the voltage will not be
changed, it is still 900mV and a little too large relative to 850mV.
2. there is only one opp whose frequency is 1200MHz and voltage is 1100mV
in opp table list, as it doesn't set voltage to 1100mV before set frequency
to 1200MHz in the dev_pm_opp_set_rate function, the initial voltage 900mV
cann't supply for 1200MHz, the system crash.
Change-Id: Iba41536367ba5802dd8f7f37e245f0e5781eb643
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
The CPUFREQ_CREATE_POLICY and CPUFREQ_START had removed on 'master'
of git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git.
So the driver will be unused in the future.
Change-Id: I7e26a8050c4745d3390302babeafbbc40ff5e707
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
This path introduces a rockchip-cpufreq driver, which can determine
available OPPs and select a suitable voltage for available OPPs
according to SoC version and leakage valuses in eFuse at runtime.
If all cpus of a cluster are downed, opp table will be removed,
prop-name and supported_hw are noneffective. So add a hotcpu notifier
to set them again when a cpu of the closed cluster is upped.
Change-Id: I43ab3e2cad4a9fefd5be5b0596cd841c392d7a8b
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Add the device tree bindings document for ROCKCHIP CPUFreq driver.
The operating-points-v2 binding allows us to provide an opp-supported-hw
property for each OPP to define when it is available and an
opp-microvolt-<name> property to choose a suitable voltage for OPP.
This driver reads SoC version and leakage values from eFuse and
provides them as matching data to the opp framework.
Change-Id: I10f959edd46668bedf3be4835bb5ec63e089808d
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
The USB 2.0 PHY may lose tuning config after resume if the
PD turn off its power when suspend. So we need to tune USB
2.0 PHY again when resume.
Change-Id: Ib34de165ccd7d22598e77e5ac0fed1233e7adba0
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
There are many notes - Don't use vopb for HDMI, save it for eDP,
let's remove them for kinds of products.
Change-Id: Id8ef9ec8ac853e7b68527f59a9a8870b5a45d8f2
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
According to USB 2.0 Spec Table 7-7, the High-speed squelch
detection threshold Min 100mV and Max 150mV, and we set USB
2.0 PHY0 and PHY1 squelch detection threshold to 150mV by
default, so if the amplitude of differential voltage envelope
is < 150 mV, the USB 2.0 PHYs envelope detector will indicate
it as squelch.
On RK3399 box, if we connect usb device with a 4 meter cable,
we can see that the impedance of U2 cable is too big according
to the eye-diagram test report, and this cause serious signal
attenuation at the end of receiver, the amplitude of differential
voltage falls below 150mV.
This patch aims to reduce the PHY0 and PHY1 otg-ports squelch
detection threshold to 125mV (host-ports still use 150mV by
default), this is helpful to increase USB 2.0 PHY compatibility.
Change-Id: Iec8b4043a3440d6f2a5fb18ff59ac0f4988019e9
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
spelling mistake cause hdmi phy configure error, now correct it
Change-Id: I548d76dd44e8d39e35b95138ec3d25b358cf3376
Signed-off-by: xuhuicong <xhc@rock-chips.com>
U8_MAX payload length can meet most requirements
Change-Id: I77e5780bde72b4229ab36d961dc7498f7c78a468
Signed-off-by: WeiYong Bi <bivvy.bi@rock-chips.com>
add rockchip_rt5651_tc358749x machine driver to
support HDMIIn function
Change-Id: Ieb0e046bec60ea0a27ee49ce1204b032ad646724
Signed-off-by: LuoXiaoTan <lxt@rock-chips.com>
When rockchip,hw-tshut-mode is 0, means that tshut mode is CRU,
then the pinctrl should default to be GPIO.
If the tshut mode is GPIO, then the pinctrl should default to be
OTP_OUT.
Change-Id: Ic6e53a96823baf4671f9bad261ed34586512634f
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
On some rockchip platforms (e.g. rk3368), usb vbus 5v is controlled
by both gpio and pmic at the same time. So we need to set gpio and
pmic when enable/disable usb vbus power.
Change-Id: I327a87f16662026eaab1b6577d0b0116c4b2671f
Signed-off-by: William Wu <wulf@rock-chips.com>
enable CONFIG_SND_SOC_ROCKCHIP_RT5651_TC358749
for HDMIIn function
Change-Id: I5c77b3f03d75ea1c51a89a2396ff6472554025a5
Signed-off-by: LuoXiaoTan <lxt@rock-chips.com>
