Fix DP drivers can't get the HPD signal changed when DP mode is on.
Change-Id: I0e8eefadb677e956cca4f62a4befa9ee47e7e013
Signed-off-by: zain wang <wzz@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: Ied6ea7677ab38988c89100e3644d829cb5736356
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
drivers/devfreq/rockchip_dmc.c: In function 'rk3368_dmc_init':
drivers/devfreq/rockchip_dmc.c:649:7: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
drivers/devfreq/rockchip_dmc.c:639:6: note: 'ret' was declared here
Change-Id: I843b7a4a0804bcf02152ba3218dcefa26d047c95
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Only vop big support 4K resolution, and HDMI request it,
Beside resolution support, the other features are the same
on rk3288 vops.
Change-Id: I2446b5d6800e8da7388b71d87a7a3fd05c10f31f
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Allow zero size updates. This makes set_memory_xx() consistent with x86, s390 and arm64 and makes apply_to_page_range() not to BUG() when loading modules.
(cherry-pick from f474c8c857)
Change-Id: I96a846a30d34077a85f36289b7b935e02f725591
Signed-off-by: Mika Penttilä mika.penttila@nextfour.com
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The array won't be used again, it is quite safe to free
it there.
Change-Id: I3bc201fbdead819cc47a08848acd66797c82e0f5
Signed-off-by: Randy Li <randy.li@rock-chips.com>
This reverts commit 273daee0be.
Needs to be reverted since system_server no longer has CAP_SYS_RESOURCE.
Change-Id: I121ac09db2f4f55349d1596c14315b98d246b3d7
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
If it is 16, and DMATDLR is 15, it would cause tx fifo
overflow.
Change-Id: I14592492be2ebd65ee47e916e25a60f0905d3eca
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
The vcc_sd is used for IO voltage for sdmmc interface on rk3399
platform have a limitation that it can't be larger than 3.0v, otherwise
it has a potential risk for the chip. Correct all of them.
Change-Id: I8d4ee2202fb32d30734c98a3b514c315e62859b4
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
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>
