In order to support the ap6212 module with rockchip wlan driver,
the kylin dts has to change the below for working.
1) We should add the 'supports-sdio' property for mmc tuning,
that's the rockchip private property, not on the upstream.
2) We should add the wifi power control pin and wifi/bt data for dts,
Maybe the history issue, they like the old driver for power
contronlling, the upstream didn't need these for working. we should
remove it in the future.
Change-Id: Id49de7ad77b8658a551a07659a8a2ddc9691874c
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
As the inno-hdmi driver introduced this clock, add it for dts supporting.
Change-Id: I43328a25f0ac72d5a5b7631cc8ff6ce98b78669a
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
The aclk_vio is the vio noc, the HDMI accessed the register need this clock
enabled first.
Change-Id: Ib3073b73020e46c7d31b09225dd2bd39a289a4cc
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
FUSB302 default cc status is UFP. If we reset the UFP system,
the UFP PD status would be reset, but the DPF can't detecte
the disconnection since cc status did not changed. Reset UFP
would send hardreset to DPF due to wait power caps timeout.
And that would cause the power reset.
So, let's use softreset instead of hardreset in this case.
Change-Id: Ic896597569adb125bea3bf145c5c93712fa77539
Signed-off-by: zain wang <wzz@rock-chips.com>
If the gmac-m1 optimization(bit10) is selected, the gpio function
of gmac pins is not valid. We may use the rmii mode for gmac interface,
the pins such as rx_d2, rx_d3, which the rgmii mode used, but rmii not
used could be taken as gpio function. So gmac_rxd0m1 selects the bit2,
and gmac_rxd0m3 select bit10 is more correct.
Change-Id: I781bd29f2ce64ba0e8c1b139ac117fe124410d87
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The offset of gpio0 and gpio1 bank drive strength is 0x8, not 0x4.
But the mux is 0x4, we couldn't use the IOMUX_WIDTH_4BIT flag, so
we give them actual offset.
Change-Id: I8371c6432330bd73422c2e5c7a0719f4636eabae
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
