The phy flag shift offset is defined in dts file, there is
no need to or the shift in the phy driver.
Change-Id: I13a33a536dabea68adf07a73cc2d13439719c589
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
On 32bit platform, vco may be out of range. The variable type
of vco needs to be set to u64.
Change-Id: I2f6b967278986bb77bf74c7a11794fc4d73645db
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
On some chip, HDMI post PLL is not stable when it's vco is 1080M,
but it work ok when vco is 270M. We use a efuse bit to distinguish
these chip.
Change-Id: I143363d67e60747ee52d405edace3ec611de3e6e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Inno hdmi phy post pll is enabled by default on rk3228, it's need to
manual power down post pll if uboot logo is not shown.
Change-Id: I7ed4de2eae2d723f390dae44281281b9e81f4e1d
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
we can power off the bandgap to reduce power consumption.
Change-Id: I7959e6f1d38a6abca70d6d904264668a19ace920
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
This change adds usb-phy support for rk3308 SoC and amend related
phy Documentation.
Change-Id: I953af94fb4d55d79ae1cba624a04fb4b84e019f6
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
for rk322x power down post-PLL must to both set rege0[5]=0 and set
pre pll pre-PLL unlock. So power down pre-PLL before post-PLL power
down
Change-Id: If0eb325b10bb6eb117b0a61d5852e9aae9d92ba6
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
Turn off differential receiver in suspend mode for RK3328 and
PX30 to save power.
The effect of turn off differential receiver on electricity:
USB20_AVDD_1V8: 0.73mA (turn on)
USB20_AVDD_1V8: 0.03mA (tunn off)
Change-Id: I0650d6d4b712a3692eed2564dda36d41b7956bb9
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
we can power off the da_pwrok to reduce power consumption.
Change-Id: Ie08af149e74408e57750a186cf16d5adf4b3cfb7
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The RK3328 HDMI PHY adds a method to detect the TMDS Data sync
enable status. The counter length is defined as:
Fref * 495 * 4 / Ftmdsclk
If sync enable counter match the counter length, the sync status
defined in reg0xdd will be set to true.
Change-Id: Ib6a58cb50127e84399011cb398e7fa36f72b3a45
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Rename pinctrl_utils_dt_free_map to pinctrl_utils_free_map, since
it does not depend on device tree despite the current name. This
will enforce a consistent naming in pinctr-utils.c and will make
it clear it can be called from outside device tree (e.g. from
ACPI handling code).
Change-Id: I442cea04967997ed29d6e7a3cfe35f2ec2e9c95f
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit d32f7fd3bb)
This patch uses a fixed-regulator instead of GPIO pin for
usb vbus power. It doesn't fix any issue, but it makes more
sense to convert the GPIO code into a fixed-regulator.
Change-Id: I76fb8dc5c8cfdba24ccb3fc24f14850defb83b2e
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch uses a fixed-regulator instead of GPIO pin for
usb vbus power. It doesn't fix any issue, but it makes more
sense to convert the GPIO code into a fixed-regulator.
Change-Id: I7196a9cd592dbb3fab3ef8b9e99babc613a42869
Signed-off-by: William Wu <william.wu@rock-chips.com>
For 3328, inno hdmi phy post pll is enabled by default, it's need to
manual power down post pll if uboot logo is not shown.
Change-Id: Ia175ff0aad006be950b8bc13e1cf2ecb4f00e04c
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
If we power off the SoC LOGIC rail in S3, we can find that the
Type-C PHY can't initialize correctly after system resume with
error log 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
It's because that the field of usb3tousb2 in GRF_USB3PHY0/1_CON0
is reset to 1 after power off the SoC LOGIC, which means that the
pipe interface is blocked between Tpye-C PHY and usb3 controller.
And after system resume, the rockchip_usb3_phy_power_on() will call
the tcphy_cfg_usb3_to_usb2_only() to clear the usb3tousb2 bit and
enable the usb3 host again. If we clear the usb3tousb2 bit before
pipe ready, it may cause waiting for pipe ready timeout.
Note that the RK3399 TRM suggests that we should keep the whole usb3
controller in reset for the duration of the Type-C PHY initialization.
However, it's hard to assert the reset in the current framework of
reset. And according to the TRM, it doesn't require that we should
clear the usb3tousb2 bit before pipe ready. So let's enable the usb3
host after pipe ready to avoid the Type-C PHY initialization failure.
BUG=b:62644399, chromium:783464
TEST=run suspend_stess_test on Scarlet, usb device can work after resume
Change-Id: Ie597cbe35568c390460aa2fdbad0e66c6104c8d2
Reviewed-on: https://chromium-review.googlesource.com/896908
Commit-Ready: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
If hdmi phy had been set in uboot, it's need to set power_count
to 1 to match actutal phy status.
This patch use regc8 bit[7:6] to detect phy is set in uboot or not.
After phy power up, value will be zero which is different to its
default value(2'b11).
Change-Id: I6e5deea1d5a0973788c39a200d5c5a0f6a14bdd2
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
LSK 18.02 v4.4-android
* tag 'lsk-v4.4-18.02-android': (131 commits)
Linux 4.4.114
nfsd: auth: Fix gid sorting when rootsquash enabled
net: tcp: close sock if net namespace is exiting
flow_dissector: properly cap thoff field
ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY
net: Allow neigh contructor functions ability to modify the primary_key
vmxnet3: repair memory leak
sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf
sctp: do not allow the v4 socket to bind a v4mapped v6 address
r8169: fix memory corruption on retrieval of hardware statistics.
pppoe: take ->needed_headroom of lower device into account on xmit
net: qdisc_pkt_len_init() should be more robust
tcp: __tcp_hdrlen() helper
net: igmp: fix source address check for IGMPv3 reports
lan78xx: Fix failure in USB Full Speed
ipv6: ip6_make_skb() needs to clear cork.base.dst
ipv6: fix udpv6 sendmsg crash caused by too small MTU
ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL
dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state
hrtimer: Reset hrtimer cpu base proper on CPU hotplug
...
In current code, the pre-emphasize in eop state and chirp state are
disabled only if we add “rockchip,u2phy-tuning” property in RK3399 dts,
But we find that if we enable the pre-emphasize of sop/eop/chirp state
for rk3399 by default, it will cause usb2 compliance test item - EL_8
and EL_9 failure, so disable the pre-emphasize of sop/eop/chirp state
by default. And this can also help to avoid mis-trigger the disconnect
detection or high-speed handshake failure.
Change-Id: I5ceac9c88de4cdae5af904e973124c194f7718f6
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
avoid out of value range calculate catmdsclk when 4k10bit and set
scdc high tmds clock ratio when mtmdsclock is more than 340000000
Change-Id: I8aed4c99813e43c69526f3918d5e7024879d3288
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
commit b7563e2796 upstream.
Stefan Wahren reports a problem with a warning fix that was merged
for v4.15: we had lots of device nodes with a 'phys' property pointing
to a device node that is not compliant with the binding documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt
This generally works because USB HCD drivers that support both the generic
phy subsystem and the older usb-phy subsystem ignore most errors from
phy_get() and related calls and then use the usb-phy driver instead.
However, it turns out that making the usb-nop-xceiv device compatible with
the generic-phy binding changes the phy_get() return code from -EINVAL to
-EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
-EPROBE_DEFER from its probe function rather than ignoring the failure,
breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
function, so a reasonable assumption would be that many other platforms
are affected as well.
I have reviewed all the related patches and concluded that "usb-nop-xceiv"
is the only USB phy that is affected by the change, and since it is by far
the most commonly referenced phy, all the other USB phy drivers appear
to be used in ways that are are either safe in DT (they don't use the
'phys' property), or in the driver (they already ignore -EPROBE_DEFER
from generic-phy when usb-phy is available).
To work around the problem, this adds a special case to _of_phy_get()
so we ignore any PHY node that is compatible with "usb-nop-xceiv",
as we know that this can never load no matter how much we defer. In the
future, we might implement a generic-phy driver for "usb-nop-xceiv"
and then remove this workaround.
Since we generally want older kernels to also want to work with the
fixed devicetree files, it would be good to backport the patch into
stable kernels as well (3.13+ are possibly affected), even though they
don't contain any of the patches that may have caused regressions.
Fixes: 014d6da6cb ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
Fixes: c5bbf358b7 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
Fixes: 44e5dced2e arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
Fixes: f568f6f554 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
Fixes: d745d5f277 ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
Fixes: 915fbe59cb ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
Link: https://patchwork.kernel.org/patch/10158145/
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
when wake up only power on hdmi phy, it may result in tmds pll unlock
because when in deep suspend, the power maybe no in a normal state.
now reinstall all register when wark up.
Change-Id: Ie882fa9b99bc6f4bfb3b2a6ea88a043b2f89ed58
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
reinstall hdmi TMDS clock when set color depth between 8bit and 10bit
to fix tmds clock frequency mismatch
Change-Id: I5ac951cd6cc0ac04b595009be7ae250e42290854
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
It turns out that 5us of caldone isn't enough for all cases, so
let's retry some more times to wait for caldone. And use the API
instead of open-coding for polling dllrdy, but no functional change
intended.
Change-Id: I91e776871a223fc76f76c71ffa0d32c689fcca4e
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
On some sink, e.g. Philips 24PFL3545/T3, Y data which is transmitted
in the D1 channel was recognized error, and picture will show noise.
It's fixed after enable the 150ohm differential resistance.
Change-Id: Ie1197dc78260bf7931786ebbccf98e9599b66ccd
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
We found that the system was blocked in EHCI when perform suspend or
reboot on RK3288 platform, the root cause is that EHCI (auto) suspend
causes the corresponding usb-phy into suspend mode which would power
down the inner PLL blocks in usb-phy if the COMMONONN is set to 1'b1.
The PLL output clocks contained CLK480M, CLK12MOHCI, CLK48MOHCI, PHYCLOCK0
and so on, these clocks are not only supplied for EHCI and OHCI, but also
supplied for GPU and other external modules, so setting COMMONONN to 1'b0
to keep the inner PLL blocks in usb-phy always powered.
Change-Id: Ifb7f3d233cf72155aa54d20b15a62b683944a526
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
In current code, the id irq will be disabled in suspend, if the otg
cable is connected during suspend, the id interrupt will be missing.
This patch checkout the voltage of id pin, power on phy and turn
on vbus if the otg cable is connected.
Change-Id: I988ecdf12e40fdfbc5360896cfb983879ebe23eb
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
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/)
The usb2 phy driver will power off phy if it detects
usb connecting with usb charger. And then it schedule
a delayed work to check the connection state until the
usb disconnect from usb charger.
On rockchip platform, the usb2 controller utmi clk and
480MHz clk come from usb2 phy, so if we power off the
usb2 phy, the usb2 controller should not be accessed.
However, it's difficult to synchronize the phy state
between the usb2 phy driver and usb2 controller. We
find one synchronization problem in the following
case:
1. Test on rk312x platform;
2. Connect otg port with usb charger, then do suspend/
resume stress test.
3. We will find the following error log, and then the
usb controller work abnormally.
dwc2 10180000.usb: resuming usb gadget configfs-gadget
dwc2 10180000.usb: dwc2_core_reset() HANG! Soft Reset GRSTCTL=80000001
This because in dwc2 driver, it will do dwc2 core reset
during resume, although it also power on usb2 phy before
do core reset, but the otg_sm_work in the usb2 phy driver
may power off the usb2 phy again asynchronously, this will
cause dwc2 core reset failure.
So we should not power off the usb2 phy if connect to
usb charger, this patch will increase the usb2 phy power
consumption in runtime, but it don't affect the power
consumption in system standby mode, because the usb
controller can power off phy by itself during suspend.
Change-Id: I3b05c06988b7939ebf949ced34b9a6bb37ffa42a
Signed-off-by: William Wu <william.wu@rock-chips.com>
Turn off differential receiver in suspend mode to save power
Change-Id: Idd9b4c2d7d9d78915c94946ced99737683a2ce91
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
When detect the usb peripheral disconnect from PC usb
host port or usb charger, we need to reinit the charge
state immediately, then it can do usb battery charge
detect work to get correct charge type if usb re-plug
in again in a short time.
Change-Id: I187f1d23a11b00f57e0a3699b6174cd7a59be3f1
Signed-off-by: William Wu <william.wu@rock-chips.com>
We found the usb-phy lost devices detected ability after continuously
disconnect/connect, this patch add usb2-phy reset/deassert as one part
of previous workaround (commit c1ebf31) to fix it.
Change-Id: Ib7112047eb0f5030406389aa9c8ebd599f8118be
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Calculate the calibration code as per the docs. The docs talk about
reading and averaging the pullup and pulldown calibration codes. They
also talk about adding in some adjustment codes. Let's do what the
docs say.
In practice this doesn't seem to matter a whole lot. On a device I
tested the pullup and pulldown codes were nearly the same (0x23 and
0x24) and the adjustment codes were 0.
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
(cherry picked from commit e023b1fb52)
Change-Id: I7c8304db69f8c6aacdd889a58d4bb7f185507f9d
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
NOTE: nothing is known to be fixed by this change, but it does enforce
some delays that are documented to be necessary. Possibly this could
fix some corner cases.
The function tcphy_dp_aux_calibration(), like most of the functions in
the type C PHY, is mostly undocumented and filled with mysterious,
hardcoded numbers.
Let's attempt to try to document some of these numbers and clean the
function up a little bit. Here's the actual cleanup that happened
here:
1. All magic numbers were replaced with bit definitions.
2. For registers that we modify multiple times I now keep track of the
value of the register rather than randomly doing a
read/modify/write or just hardcoding a new number based on knowing
what the old number was.
3. Delay 10 ms (vs 1 ms) after writing the calibration code. No idea
if this is important but it matches the example in the docs.
4. Whenever setting a "delayed" version of a signal always put an
explicit delay in the code. No known problems were seen without
this delay but it seems wise to have it. Whenever a delay of "at
least 100 ns" was specified I used a delay of 1 us.
5. Added comments to some of the bits of code.
6. Removed duplicate setting of TX_ANA_CTRL_REG_5 (to 0)
7. Moved setting of TX_ANA_CTRL_REG_3 to the same place it was in the
sample code. Note that TX_ANA_CTRL_REG_3 ought to be initted to 0
(and elsewhere we assume that we just got a reset), but it seems
fine to be explicit.
8. Treats the calibration code as a 7-bit two's complement number.
This isn't strictly required, but seems slightly cleaner. The docs
say "treat this as a two's complement number, but it should never
be negative". If we ever read the "adjustment" codes as documented
then perhaps the two's complement bit will matter more.
There are still a few weird / mysterious things around aux init and
this doesn't attempt to fix all of them. Mostly it's aimed at doing
changes that should be _very_ safe and add a lot of clarity. Things
specifically not done:
A) Resolve the fact that some registers are read/modify/write and
others are explicitly initted to a value. We always call
tcphy_dp_aux_calibration() right after resetting the PHY so it's
probably not critical, but it's a little weird that the code is
inconsistent.
B) Fully resolve the documented init sequence with the current one.
We still have a few mystery steps and we also leave out turning on
TXDA_DRV_LDO_BG_FB_EN and TXDA_DRV_LDO_BG_REF_EN, which is in the
sample code.
C) Clean things up to read all the bits of the calibration code. This
will hopefully come in a followup change.
This also doesn't attempt to document any of the other parts of the
PHY--just the aux init which is all I got docs for.
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
(cherry picked from commit f85fd4c909)
Change-Id: I8581976b31978d7a3fa39d9679c40537572d5342
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
The function tcphy_phy_init() could return an error but the callers
weren't checking the return value. They should. In at least one case
while testing I saw the message "wait pma ready timeout" which
indicates that tcphy_phy_init() really could return an error and we
should account for it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
(cherry picked from commit 2fb850092f)
Change-Id: Ic95e962f67845fb5fda0495f9ea20036b7069b3c
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
The vbus may need control by u2phy when force. This patch
control vbus when set phy mode.
Change-Id: I237e9e3688b257689c79040f19642cea5365d409
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
Most of rockchip SoCs USB 2.0 DP/DM can be bypassed to UART,
it's useful for those platforms without UART interface to
print log via USB interface.
For the time being, we just support for rk312x and rk3399 in
this driver. And we will support for more SoCs in the feature.
With this patch, the user still can't use this bypass function.
It needs to add the property "rockchip,bypass-uart" in the DT
as following:
u2phy0_otg: otg-port {
...
rockchip,bypass-uart;
...
};
And it also needs a special USB cable integrated with an USB
to UART chip.
Note: this function can only be used in debug stage.
Change-Id: Icdab516ff7b327f4a98c3b24bbaf953a605f5278
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
On rk3399-gru-kevin there are some cases where we're seeing AUX CH
failures when trying to do DisplayPort over type C. Problems are
intermittent and don't reproduce all the time. Problems are often
bursty and failures persist for several seconds before going away.
The failure case I focused on is:
* A particular type C to HDMI adapter.
* One orientation (flip mode) of that adapter.
* Easier to see failures when something is plugged into the _other
type C port at the same time.
* Problems reproduce on both type C ports (left and right side).
Ironically problems also stop reproducing when I solder wires onto the
AUX CH signals on a port (even if no scope is connected to the
signals). In this case, problems only stop reproducing on the port
with the wires connected.
From the above it appears that something about the signaling on the
aux channel is marginal and any slight differences can bring us over
the edge to failure.
It turns out that we can fix our problems by just increasing the
voltage swing of the AUX CH, giving us a bunch of extra margin. In DP
up to version 1.2 the voltage swing on the aux channel was specced as
.29 V to 1.38 V. In DP version 1.3 the aux channel voltage was
tightened to be between .29 V and .40 V, but it clarifies that it
really only needs the lower voltage when operating at the highest
speed (HBR3 mode). So right now we are trying to use a voltage that
technically should be valid for all versions of the spec (including
version 1.3 when transmitting at HBR3). That would be great to do if
it worked reliably. ...but it doesn't seem to.
It turns out that if you continue to read through the DP part of the
rk3399 TRM and other parts of the type C PHY spec you'll find out that
while the rk3399 does support DP 1.3, it doesn't support HBR3. The
docs specifically say "RBR, HBR and HBR2 data rates only". Thus there
is actually no requirement to support an AUX CH swing of .4 V.
Even if there is no actual requirement to support the tighter voltage
swing, one could possibly argue that we should support it anyway. The
DP spec clarifies that the lower voltage on the AUX CH will reduce
cross talk in some cases and that seems like it could be beneficial
even at the lower bit rates. At the moment, though, we are seeing
problems with the AUX CH and not on the other lines. Also, checking
another known working and similar laptop shows that the other laptop
runs the AUX channel at a higher voltage.
Other notes:
* Looking at measurements done on the AUX CH we weren't actually
compliant with the DP 1.3 spec anyway. AUX CH peek-to-peek voltage
was measured on rk3399-gru-kevin as .466 V which is > .4 V.
* With this new patch the AUX channel isn't actually 1.0 V, but it has
been confirmed that the signal is better and has more margin. Eye
diagram passes.
* If someone were truly an expert in the Type C PHY and in DisplayPort
signaling they might be able to make things work and keep the
voltage at < .4 V. The Type C PHY seems to have a plethora of
tuning knobs that could almost certainly improve the signal
integrity. Some of these things (like enabling tx_fcm_full_margin)
even seem to fix my problems. However, lacking expertise I can't
say whether this is a better or worse solution. Tightening signals
to give cleaner waveforms can often have adverse affects, like
increasing EMI or adding noise to other signals. I'd rather not
tune things like this without a healthy application of expertise
that I don't have.
Change-Id: Ifa4fbb8844edd731debc4a469b762afdcdd449c2
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
On some DP monitors we found that setting the wrong flip state on the
AUX channel could cause the monitor to stop asserting HotPlug Detect
(HPD). Setting the right flip state caused these monitors to start
asserting HotPlug Detect again.
Here's what we believe was happening:
* We'd plug in the monitor and we'd see HPD assert
* We'd quickly see HPD deassert
* The kernel would try to init the type C PHY but would init it in USB
mode (because there was a peripheral there but no HPD)
* Because the kernel never set the flip mode properly we'd never see
the HPD come back.
With this change, we'll still see HPD disappear (we don't think
there's anything we can do about that), but then it will come back.
Overall we can say that it's sane to set the AUX channel flip state
even when HPD is not asserted.
NOTE: to make this change possible, I needed to do a bit of cleanup to
the tcphy_dp_aux_calibration() function so that it doesn't ever
clobber the FLIP state. This made it very obvious that a line of code
documented as "setting bit 12" also did a bunch of other magic,
undocumented stuff. For now I'll just break out the bits and add a
comment that this is black magic and we'll try to document
tcphy_dp_aux_calibration() better in a future CL.
ALSO NOTE: the old function used to write a bunch of hardcoded
values in _some_ cases instead of doing a read-modify-write. One
could possibly assert that these could have had (beneficial) side
effects and thus with this new code (which always does
read-modify-write) we could have a bug. We shouldn't need to worry,
though, since in the old code tcphy_dp_aux_calibration() was always
called following the de-assertion of "reset" the the type C PHY.
...so the type C PHY was always in default state. TX_ANA_CTRL_REG_1
is documented to be 0x0 after reset. This was also confirmed by
printk.
Change-Id: Ie17b71f525dd39fc777f5072c16bb9cc9e6ff2ab
Suggested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
In order to silent the 'W=1' compile warning:
drivers/phy/rockchip/phy-rockchip-typec.c: In function 'tcphy_get_mode':
drivers/phy/rockchip/phy-rockchip-typec.c:625:7: warning: variable 'dfp'
set but not used [-Wunused-but-set-variable]
Change-Id: I9aee0963db1fa23768550ae01c07190d5b8b2697
Cc: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Rockchip Inno usb2-phy uses extcon_* methods and because of
that, it must select EXTCON as a dependency. This patch fixes it.
Change-Id: Ia2b712154e4fee567b843f38f50fbcc00c49bf1e
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
The rk312x use different config data which incluce control
register address and value. The patch add config data of
rk312x and match table to support rk3128.
Change-Id: Idd9a5c885cf5e291517e56232e77066eb5d97138
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
Commit 4f519feed0 ("phy: rockchip-inno-usb2: delay suspending
phy if plug out device"), introduced the following issue:
BUG: sleeping function called from invalid context at kernel/workqueue.c:2717
in_atomic(): 1, irqs_disabled(): 128, pid: 4, name: kworker/0:0
INFO: lockdep is turned off.
irq event stamp: 19674
hardirqs last enabled at (19673): [<ffffff8008cd8818>] _raw_spin_unlock_irqrestore+0x40/0x70
hardirqs last disabled at (19674): [<ffffff8008cd8690>] _raw_spin_lock_irq+0x1c/0x60
softirqs last enabled at (19664): [<ffffff80088dd1c0>] dw_mci_request+0xe0/0xf0
softirqs last disabled at (19660): [<ffffff80088dd140>] dw_mci_request+0x60/0xf0
CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.4.83 #69
Hardware name: Rockchip RK3399 Evaluation Board v3 (Android) (DT)
Workqueue: fusb302_wq fusb302_work_func
Call trace:
[<ffffff8008089f78>] dump_backtrace+0x0/0x1cc
[<ffffff800808a158>] show_stack+0x14/0x1c
[<ffffff80083ca33c>] dump_stack+0xb8/0xf4
[<ffffff80080cec40>] ___might_sleep+0x1b8/0x1c8
[<ffffff80080cecc0>] __might_sleep+0x70/0x80
[<ffffff80080becbc>] flush_work+0x74/0x270
[<ffffff80080bf09c>] __cancel_work_timer+0x12c/0x1bc
[<ffffff80080bf154>] cancel_delayed_work_sync+0x10/0x18
[<ffffff80083f9de8>] rockchip_otg_event+0x18/0x3c
[<ffffff80080c6380>] notifier_call_chain+0x54/0x88
[<ffffff80080c63dc>] raw_notifier_call_chain+0x14/0x1c
[<ffffff80089a5354>] extcon_sync+0x74/0x1c4
[<ffffff80085ab980>] platform_fusb_notify+0x184/0x204
[<ffffff80085ac4ac>] set_state_unattached+0x5c/0x90
[<ffffff80085ac85c>] fusb302_work_func+0x288/0x1904
[<ffffff80080bdfa4>] process_one_work+0x354/0x6d0
[<ffffff80080bf4a4>] worker_thread+0x2f8/0x414
[<ffffff80080c4e58>] kthread+0xf0/0xf8
[<ffffff80080828d0>] ret_from_fork+0x10/0x40
Actually, we don't need to cancel the otg_sm_work in the
event EXTCON_USB_HOST notifier_call. So just remove the
cancel_delayed_work_sync() in the rockchip_otg_event().
With this patch, we may get USB BC1.2 detection error
if plug in USB peripheral/host cable alternately and
quickly. So we need to reinit chg_state and chg_type
if OTG host cable plug in.
Change-Id: I349d59de3188d39707c527acb858a7be20a999ac
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
