npll is just for dclk_vop, others clk not allowed to set npll as parent.
Change-Id: I11e1770acab5486acaebafd56a0c57847f7f533c
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
add mmc hs200/ddr mode support and increase the max clock frequence.
Change-Id: I7e81dfaf364d88a3e8bf0278a8f771a8179c6627
Signed-off-by: Wenping Zhang <wenping.zhang@rock-chips.com>
It has been tested by i2s, we can hear noise when play
music by unalign buffer size.
Change-Id: Ie52d5ac79c71df8fcec841d8801e24280831420e
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
commit dbb236c1ce upstream.
Recently vDSO support for CLOCK_MONOTONIC_RAW was added in
49eea433b3 ("arm64: Add support for CLOCK_MONOTONIC_RAW in
clock_gettime() vDSO"). Noticing that the core timekeeping code
never set tkr_raw.xtime_nsec, the vDSO implementation didn't
bother exposing it via the data page and instead took the
unshifted tk->raw_time.tv_nsec value which was then immediately
shifted left in the vDSO code.
Unfortunately, by accellerating the MONOTONIC_RAW clockid, it
uncovered potential 1ns time inconsistencies caused by the
timekeeping core not handing sub-ns resolution.
Now that the core code has been fixed and is actually setting
tkr_raw.xtime_nsec, we need to take that into account in the
vDSO by adding it to the shifted raw_time value, in order to
fix the user-visible inconsistency. Rather than do that at each
use (and expand the data page in the process), instead perform
the shift/addition operation when populating the data page and
remove the shift from the vDSO code entirely.
[jstultz: minor whitespace tweak, tried to improve commit
message to make it more clear this fixes a regression]
Change-Id: Ib211fcb73106fd088bb3c43725df2b9264ab303d
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Daniel Mentz <danielmentz@google.com>
Acked-by: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Link: http://lkml.kernel.org/r/1496965462-20003-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from LTS linux-4.9.y
commit 99f66b5182)
commit 3d88d56c58 upstream.
Due to how the MONOTONIC_RAW accumulation logic was handled,
there is the potential for a 1ns discontinuity when we do
accumulations. This small discontinuity has for the most part
gone un-noticed, but since ARM64 enabled CLOCK_MONOTONIC_RAW
in their vDSO clock_gettime implementation, we've seen failures
with the inconsistency-check test in kselftest.
This patch addresses the issue by using the same sub-ns
accumulation handling that CLOCK_MONOTONIC uses, which avoids
the issue for in-kernel users.
Since the ARM64 vDSO implementation has its own clock_gettime
calculation logic, this patch reduces the frequency of errors,
but failures are still seen. The ARM64 vDSO will need to be
updated to include the sub-nanosecond xtime_nsec values in its
calculation for this issue to be completely fixed.
Change-Id: I84f455fc9adbb26c4130205d9ebe3683f638fc1d
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Daniel Mentz <danielmentz@google.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Link: http://lkml.kernel.org/r/1496965462-20003-3-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from LTS linux-4.9.y
commit a53bfdda06)
The rk312x soc's up and down pull setting is determined by the hardware.
So remove the wrong up and down pull setting, the pcfg_pull_none setting
is disabled the pull.
Change-Id: I2a2f33ab6b460806601ad5e1914a5e4eee013835
Signed-off-by: David Wu <david.wu@rock-chips.com>
Add constants and callback functions for the dwmac on rk3128 soc.
As can be seen, the base structure is the same, only registers
and the bits in them moved slightly.
Change-Id: I62617ad8d58ce3f19a1222e1494a89545d6ec45e
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It only supports rmii interface. Add constants and callback functions
for the dwmac on rv1108 socs. As can be seen, the base structure is
the same, only registers and the bits in them moved slightly.
Change-Id: I91e6c812b8e3dc640884d66b41490f5e588a3f28
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If ddr frequency can be changed according to vop bandwidth,
change auto-min-freq to 200MHz is okay and 200MHz is enough
for 1080P@30fs and 1080P@60fps.
Change-Id: I522fecb1f97430344b0b67c9ee72a447528c6b76
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
This change reserved 14M memory zone for OPTEE side on rk3229-evb board.
Change-Id: I4f25f556f3adb649a5ac248a46927a716a38b902
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
If the gpio base is started from 1000, The real pin
number is "gpio number - 1000".
Change-Id: If9b627ce9689105d0cdb7314869d598b4132f486
Signed-off-by: shengfei Xu <xsf@rock-chips.com>
The command defines for the ioctl will be installed
into userspace in a header file.
The arguments of the ioctl is the unique at a platform.
Change-Id: Ia86a12c91cc4243fea24fc21cc0a9f77ec9fb2d6
Signed-off-by: Randy Li <randy.li@rock-chips.com>
If ddr frequency can be changed according to vop bandwidth,
change auto-min-freq to 200MHz is okay and 200MHz is enough
for 1080P@30fs and 1080P@60fps.
Change-Id: I4fddb71ced34f4d217d7fc1b97ccf73e612683b0
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
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>
