The order of the write registers is as follows:
0x17->0x18(lsb)->0x19->0x18(msb)->0x19
Change-Id: I3164a46ed49be611db5bd62d2ae7810613bdbfe0
Signed-off-by: Jerry Xu <xbl@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>
Afbc only check the new state, If new atomic state has no plane state,
But old plane state has afbdc, the afbc check would be wrong, and cause
display abnormal.
Change-Id: I078241149c302ca137bec69f310555c7c37c6992
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
enable the following peripherals:hdmi/wifi/
hdmi_sound/spdif/sdio/sdmmc/hym8563(rtc);
enable the integrated phy for gmac by default.
Change-Id: I92f10e02c5c783c044ab4a080f6f553458d5a971
Signed-off-by: Xinhuang Li <buluess.li@rock-chips.com>
At this point in time, dsi->slave is always NULL, so fix it.
Change-Id: I4f5a75d2547b1083751fcbbb0c7e0c568dc19028
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Fixes: d6dfcd07b7 ("drm/rockchip: dw-mipi-dsi: analyze the platform parameters in the probe function")
Change-Id: Iecf9532f52a1b27ea063556701f840329881a2e2
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Fix issue like, rx_running is set 1 after first start rx.
But rx_running is still 1 after stop rx, which causes
dma can not be started when second start rx.
Change-Id: Id2f3a535da1b3609e8af287edbcc2e25fb7ae922
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
In the most common use case, the Synopsys DW UART driver does not
set the set_termios callback function. This prevents UPSTAT_AUTOCTS
from being set when the UART flag CRTSCTS is set. As a result, the
driver will use software flow control as opposed to hardware flow
control.
To fix the problem, the set_termios callback function is set to the
DW specific function. The logic to set UPSTAT_AUTOCTS is moved so
that any clock error will not affect setting the hardware flow
control.
Change-Id: Iea1e99512f0818eaa1642d25eb1ad02da049e8c6
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
To fix issue like this:
dma-pl330 ff6d0000.dma-controller: pl330_update:1733 Unexpected!
dma-pl330 ff6d0000.dma-controller: DMAC halted!
The root cause is DMA clk is closed when DMA interrupt is
in service. This may happen, as follow:
1. When pl330_terminate_all is called, and set pch->active false,
power_down is true, call pm_runtime_put_autosuspend.
2. Then pl330_tasklet is called, if power_down is also true, call
pm_runtime_put_autosuspend again.
3. DMA is opened again, because the autosuspend is asyn, it may close
the DMA clk. If DMA interrupt is coming, it causes the issue.
Change-Id: Ib1feb508c16afb4bc9ced0c3660f2b6b4a19c068
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
The scaling list buffer handle under the pps unit
will be translated into the DMA address for the device,
but the processing is done under the kernel, so the
iommu of the device won't be invoked. We don't need to
cache it.
Using the standard kernel method is enough to access
the memory under the kernel space, so all the map to
kernel methods of the memory management are removed.
A few steps for memory mapping are also merged in
this patch.
Change-Id: Ia3f6f38568aed8021baff757720453c4eea03b90
Signed-off-by: ayaka <ayaka@soulik.info>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
if power-invert exist the panel power need to disable ldo when
power on and enable ldo when power off otherwise it's opposite.
example:
panel {
...
power-invert;
...
};
Change-Id: Ida5718d01044873cdd7c753c4e8b872dc1e52099
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
because currently mclk is handled by codec side, so the
associated pinctrl should be handled by codec too.
Change-Id: I0611b7a291351a20f72b5124c501dc79d92787d6
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
because currently mclk is handled by codec side, so the
associated pinctrl should be handled by codec too.
Change-Id: I55db6e9a0181cae0cb414b9dcacae7ff0214b50c
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Initialize default format for current stream and set stream state
to 'READY' in case of streaming on by user without passing format
to driver. Default format will be overridden by VIDIOC_S_FMT.
Implement VIDIOC_G_FMT and application can get the format info
of current stream now. This will become necessary when enable
'--set-fmt-video' option of v4l2-ctl test suite,
Set bytesused of each plane to its real size to prevent confusing.
The IO mode of vb2 queue 'VB2_DMABUF' is now supported.
Change-Id: Id52da502df8aea796b3405ebf472541a394afd80
Signed-off-by: Jacob Chen <cc@rock-chips.com>
When import dma_buf to rga driver, dma_map_sg will always do
cpu cache sync, it cause low performance.
Actually we don't want to do cpu cache sync on this context,
So set rga device with dma-coherent to skip cpu cache sync.
Change-Id: Ie256db6a072481953befafb5b8003b9c1e713436
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
When import dma_buf to rga driver, dma_map_sg will always do
cpu cache sync, it cause low performance.
Actually we don't want to do cpu cache sync on this context,
So set rga device with dma-coherent to skip cpu cache sync.
Change-Id: Idfeb0de2e1d92873dcbd560cec40a4f9f8807013
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
If the gpio base is started from 1000, the "gpio = 0" will
be invalid, that can avoid something unforeseen. The real
pin number is "gpio number - 1000".
If you cat the gpio log, you will see the log like this:
rk3399:/ # cat d/gpio
GPIOs 1000-1031, platform/pinctrl, gpio0:
gpio-1004 ( |bt_default_wake_host) in lo
gpio-1005 ( |power ) in hi
gpio-1009 ( |bt_default_reset ) out lo
gpio-1010 ( |reset ) out lo
gpio-1011 ( |? ) out hi
GPIOs 1032-1063, platform/pinctrl, gpio1:
gpio-1034 ( |int-n ) in hi
gpio-1035 ( |vbus-5v ) out lo
gpio-1036 ( |vbus-5v ) out lo
gpio-1045 ( |enable ) out hi
gpio-1046 ( |vsel ) out lo
gpio-1049 ( |vsel ) out lo
gpio-1056 ( |int-n ) in hi
GPIOs 1064-1095, platform/pinctrl, gpio2:
gpio-1083 ( |bt_default_rts ) in hi
gpio-1090 ( |bt_default_wake ) in hi
GPIOs 1096-1127, platform/pinctrl, gpio3:
gpio-1111 ( |mdio-reset ) out hi
GPIOs 1128-1159, platform/pinctrl, gpio4:
gpio-1150 ( |? ) out hi
gpio-1153 ( |vcc5v0_host ) out hi
gpio-1156 ( |hp det ) in hi
Change-Id: I744ddc1df6075b0a044d65c65622e2a59f3a332e
Signed-off-by: David Wu <david.wu@rock-chips.com>
This flag was in place to prevent important clocks from getting gated
while they had no users. Now that the driver supports clocks
properly, we can drop this.
Change-Id: I91d0a5c000ed7215bf55dbc871e175ac79a1cd2a
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
