ARM64: dts: rk3399: add clock-latency-ns for each opp

We may miss clock-latency-ns when disable some opps, then cpufreq
will fallback to performance governor, so add clock-latency-ns for
each opp to make disable opp easy.

code as below:
drivers/cpufreq/cpufreq.c:2010
if (policy->governor->max_transition_latency &&
    policy->cpuinfo.transition_latency >
    policy->governor->max_transition_latency) {
if (!gov)
         return -EINVAL;
else {
       pr_warn("%s governor failed, too long transition latency of HW,
fallback to %s governor\n",
                 policy->governor->name, gov->name);
         policy->governor = gov;
}
}

Change-Id: I93cff667deb487baa0115b7af0206f0803010d37
Signed-off-by: Chen Liang <cl@rock-chips.com>

cpufreq: cpufreq_interactive: avoid NULL point access

Change-Id: Id21a45eff24575ade7786a88d076ddd50cba6520
Signed-off-by: Chen Liang <cl@rock-chips.com>

drm/rockchip: add rk3399 vop big csc support

Change-Id: I61df68291467edfd030166b3074b44c6fdca5ffb
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: support 10bit yuv format

Change-Id: I7c1f9c3b0a4b8e711d8ce198af9b94bd7639bf17
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm: add 10bit support for yuv format

drm_format_plane_cpp use byte size, not works for 10bit
format, use drm_format_plane_bpp instead.

Change-Id: If1a6ca1c286747fdc868184cebe75eb0af0a746d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

MALI: utgard: .gitignore: ignore the build generation config

Change-Id: I02a938a390f5f29afa11042b49125031ba303074
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: dts: rk3399-android-next: Enable rga device

Change-Id: Ib07fcaa199ba0742973ae874edcc5f1b835e99c9
Signed-off-by: Zikim,Wei <wzq@rock-chips.com>

arm64: dts: rockchip: rk3399: config vop0 as main screen for box disvr

Change-Id: I0a25424265273a6a8d010da7205f74dcab7c1e8d
Signed-off-by: Luo wei <lw@rock-chips.com>

arm64: rockchip_defconfig: enable PCIE

Change-Id: I29413cfa07ff1ec378bf3b3e892b0019cfd90bcb
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

UPSTREAM: PCI: rockchip: correct the use of FTS mask

We're trying to mask out bits[23:8] while retaining [32:24, 7:0], but
we're doing the inverse. That doesn't have too much effect, since we're
setting all the [23:8] bits to 1, and the other bits are only relevant
for modes we're currently not using. But we should get this right.

Change-Id: I98ec66f1fdc5f99cc2432d7a1cddb63f4b9f3c30
Fixes: ca1989084054 ("PCI: rockchip: Fix wrong transmitted FTS count")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit fd7c054e782d57509b2355ab71b786d83ab44194)

UPSTREAM: PCI: rockchip: Add quirk to disable RC's ASPM L0s

Rockchip's RC outputs 100MHz reference clock but there are
two methods for PHY to generate it.

(1)One of them is to use system PLL to generate 100MHz clock and
the PHY will relock it and filter signal noise then outputs the
reference clock.

(2)Another way is to share Soc's 24MHZ crystal oscillator with
PHY and force PHY's DLL to generate 100MHz internally.

When using case(2), the exit from L0s doesn't work fine occasionally
due to the broken design of RC receiver's logical circuit. So even if
we use extended-synch, it still fails for PHY to relock the bits from
FTS sometimes. This will hang the system.

Maybe we could argue that why not use case(1) to avoid it? The reason
is that as we could see the reference clock is derived from system PLL
and the path from it to PHY isn't so clean which means there are some
noise introduced by power-domain and other buses can't be filterd out
by PHY and we could see noise from the frequency spectrum by oscilloscope.
This makes the TX compatibility test a little difficult to pass the spec.
So case(1) and case(2) are both used indeed now. If using case(2), we
should disable RC's L0s support, and that is why we need this property to
indicate this quirk.

Also after checking quirk.c, I noticed there is already a quirk for
disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
shouldn't do that as mentioned above that case(1) could still works fine
with L0s.

Change-Id: Ia9506d55f34a24001c19d398a8ecb088558c0f7e
Reported-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Brian Norris <briannorris@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit c2af19ee1b5e0f0ef942d27b18f7e22e2ab43cba)

UPSTREAM: PCI: rockchip: cleanup bit definition for PCIE_RC_CONFIG_LCS

PCIE_RC_CONFIG_LCS contains control and status bits specific
to the PCIe link. The layout for this register looks the same
as the existed PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's
reuse them.

Change-Id: I3e2b88d9c12f2bf924a3d6b8f2254904f9b594b2
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 144ded1828f015f1a53d50bce730ed15f17ff38f)

UPSTREAM: arm64: dts: rockchip: add three new resets for rk3399 PCIe

pm_rst, aclk_rst and pclk_rst should be controlled by driver, so we
need to add these three resets for PCIe controller.

Change-Id: I364d8d0cb57d9d349153d76189f1e20e40e32704
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 4d3222f7071c01104b43300f1c10b55723df8f68)

UPSTREAM: PCI: rockchip: Add three new resets as required properties

pm_rst, aclk_rst, pclk_rst was controlled by rom code so the
software wasn't needed to control it again in theory. But it
didn't work properly, so we do need to do it again and add a
enough delay between the assert of pm_rst and the deassert of
pm_rst. The Soc intergrated with this controller, rk3399 is still
under MP test internally, so the backward compatibility won't be
a big deal.

Change-Id: I07e02c5dcd6985ce7d16dde18bf0390674a0adbf
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 31a3a7b5b26f75fbe82de10ca99f2b673f6c26b4)

UPSTREAM: PCI: rockchip: remove the pointer to L1 substate cap

Per the errata of TRM, the RC can't support L1 substate, so we
need to remove the L1 substate cap as well as operation for
PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2.

Change-Id: If3e1e7ac46720c9487724f15b22905a02bebb7ca
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 9d7598543b5fa2dacd7ccdffe9e03b578a9a03d1)

UPSTREAM: PCI: rockchip: Specify the link capability

rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice
500ms waiting for training that will never happen, let's use the helper
function, of_pci_get_max_link_speed, to get the max link speed from DT
and specify link capability.

Change-Id: I899df707f0555eea8ae4a370b171a4786162bb90
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 9d4052126b0deeb67552580ffe7f6383e0123c62)

UPSTREAM: of/pci: Add helper function to parse max-link-speed from dt

This new helper function could be used by host drivers to
get the limitaion of max link speed provided by dt. If the
property isn't assigned or is invalid, it will return -EINVAL
to the caller.

Change-Id: I430b05fa5fd25fe17cf1bd8b1226e460eb7dd14b
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 9a1dc3891255afd836f355b117fd6b975d0b1eb2)

UPSTREAM: Documentation/devicetree: Add new property to specify the max link speed

Some of the host drivers have the requirement of knowing whether the
EP would never train at some link speed at all. For instance, on some
boards, the link won't train at 5 GT/s but the host driver still sacrifice
some cycle to wait for the resule of training at 5 GT/s as the host could
actually support 5 GT/s. So we could parse this new property and make the
host drivers be aware of these cases.

Change-Id: I7f557282462a7146d8d15af560001c81ccc7e1a7
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 2fa39159b6a9931d6fd82ecbe65357e0ad77e1a4)

UPSTREAM: PCI: rockchip: fix wrong negotiated lanes calculation

The calculation of negotiated lanes is wrong since it should
be shifted by PCIE_CORE_PL_CONF_LANE_SHIFT, but it is shifted
by PCIE_CORE_PL_CONF_LANE_MASK. Let's fix it.

Change-Id: I164d07c86e944fdab7c1a3100c87fdd24ec0ee82
Fixes: commit e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 898a2301cf002e1d96c0d56e41131a0d57cacb65)

UPSTREAM: PCI: rockchip: Add Kconfig COMPILE_TEST

Allow selection of the Rockchip driver for compile testing, even if we
aren't building for ARCH_ROCKCHIP.

Change-Id: Ibc554863e067aaa1f785d5f26423a10d0962f68b
[bhelgaas: changelog]
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit cd075fd9742b1c4bc6e11121f688ef2ff74deb84)

UPSTREAM: PCI: rockchip: Mark RC as common clock architecture

The default value of common clock configuration is
zero indicating Rockchip's RC is using asynchronous
clock architecture but actually we are using common
clock. This will confuses some EP drivers if they
need some different settings referring to this value.
So let's fix it.

Change-Id: Idc3bf918db1a0b2366010819972d231cdbceca2d
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit f4acd83a6c303ef72a42e9ea2c8c12298d333a66)

UPSTREAM: PCI: rockchip: Provide captured slot power limit and scale

If vpcie3v3 is available, we could provide these information
via RC's configure register to make EP able to know the power
limit.

Change-Id: I73f3ea163a24a9a03078436e0a4b6303482c123c
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 7cfdc39fadfdf5728e79a43242ff6b13e298c086)

arm64: rockchip_defconfig: disable unused ethernet driver

Change-Id: I61a9e326368378674527ed2ee59ed4da8cdc680a
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

UPSTREAM: power_supply: fix return value of get_property

power_supply_get_property() should ideally return -EAGAIN if it is
called while the power_supply is being registered. There was no way
previously to determine if use_cnt == 0 meant that the power_supply
wasn't fully registered yet, or if it had already been unregistered.

Add a new boolean to the power_supply struct to simply show if
registration is completed. Lastly, modify the check in
power_supply_show_property() to also ignore -EAGAIN when so it
doesn't complain about not returning the property.

Change-Id: I8a710802534c033d64589d8d213eeaa36d9cc7d7
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit e380538529e83c5d3fd27e8cbfcc1f9799cb6bbb)

UPSTREAM: thermal: rockchip: improve the warning log

It is no necessary to print warning agian and again if we don't
add rockchip,grf for dt, otherwise I saw the following log when
doing suspend-2-resume. We only need to print it once when parsing
dt. It looks quite trivial but the log is apparently verbose.

[   26.615415] PM: early resume of devices complete after 1.539 msecs
[   26.622002] rk_tsadcv2_initialize: Missing rockchip,grf property
[   26.629359] rk_gmac-dwmac ff290000.ethernet: init for RGMII
[   26.639794] PM: resume of devices complete after 18.109 msecs
[   26.646925] Restarting tasks ... done.

Change-Id: Ia3124f557e2b4f47c691671d27ea6a0f136f3f6f
Reviewed-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from git.kernel.org evalenti/linux-soc-thermal.git next
 commit 947d62b53ff381d1ca4b3288b53a26c6d38957aa)

UPSTREAM: dt-bindings: rockchip-thermal: fix the misleading description

"rockchip,hw-tshut-temp", "rockchip,hw-tshut-mode" and
"rockchip,hw-tshut-polarity" are not a required properties
actually as the code could also work by loading the default
settings there. So it is apprently misleading, although we
prefer to get these from DT. And it seems we miss the 'rockchip,grf'
here which should also be an optional property.

Change-Id: I5ae62b7137f88da40475caec3b6d43a00219d85d
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from git.kernel.org evalenti/linux-soc-thermal.git next
 commit 38e133ee6ea54bdfbe64c0e57bea4bc1e616c19a)

arm64: dts: rk3399-vr: set headset_gpio GPIO_ACTIVE_LOW

Change-Id: I37f7eddd4aff08ba7fb4d2e3299485f58c8ac826
Signed-off-by: Wu Liangqing <wlq@rock-chips.com>

ARM: rockchip: clean mach-rockchip folder

 We don't need those files from 3.10, so remove it to make it tidy

Change-Id: Iba08ac60d94e5dd014674a4b2c017020993abe60
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: configs: synchronize with other 3399 config for 3399 linux

add more driver config and architecture config

Change-Id: I55900807579a2fdaa8a31baaa3ed087c115f88c3
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: dts: rockchip: Add rk3399 mid dts for drm

Change-Id: I7aa309ef7c4cd0ec34ab030f7798d7b778e897c6
Signed-off-by: Bin Yang <yangbin@rock-chips.com>

phy: phy-rockchip-typec: select phy select bit before TCPHY enter A2.

Set phy select bit in typec driver instead of setting it in dp driver,
which is used to fix dp phy power on failed error if only use typec1
as dp output.

Change-Id: I3949305724f5b3c12dc2f0ffefcbe4abf26d43dd
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>

video: rockchip: dp: remove dp phy select operation in dp driver.

Previous code select dp phy by dp->port->id, but this id can't
indicate the phy id, and it will introduce a phy power on bug if
we only use typec1 as dp output, so we move these code to typec
phy driver.

Change-Id: If809efe9138b186b060e6c7467473f2d3192bc7e
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>

arm64: dts: rockchip: add touscreen for excavator linux

Change-Id: I8fb62eea9667c6c1c646b70fd9d10671b07957a2
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

fbdev/fb_notify: fix blank_mode pointer crash

When fb event is not blank event, use *((int *)event->data) for
blank_mode is very dangerous, see follow code on
drivers/video/fbdev/core/fbmem.c:
struct fb_event event;
event.info = fb_info;
fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);

On FB_EVENT_FB_REGISTERED event, event->data is not initial,
so get value from *(int*)event->data would crash.

crash:
[    0.909647] Unable to handle kernel paging request at virtual address
12c000000000
[    0.915506] pgd = ffffff8009147000
[    0.915808] [12c000000000] *pgd=00000000f6ff9003, *pud=00000000f6ff9003, *pmd=0000000000000000
[    0.916577] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[    0.917067] Modules linked in:
[    0.917347] CPU: 4 PID: 51 Comm: kworker/u12:1 Not tainted 4.4.30
[    0.917919] Hardware name: Rockchip RK3399 Evaluation Board v1 (Android) (DT)
[    1.098438] [<ffffff8008729fb0>] rkvr_fb_event_notify+0x38/0x18c
[    1.098976] [<ffffff80080b8c7c>] notifier_call_chain+0x48/0x80
[    1.099499] [<ffffff80080b8fb8>] __blocking_notifier_call_chain+0x48/0x64
[    1.100104] [<ffffff80080b8fe8>] blocking_notifier_call_chain+0x14/0x1c
[    1.100699] [<ffffff80083e4abc>] fb_notifier_call_chain+0x44/0x50
[    1.101242] [<ffffff80083e6da8>] register_framebuffer+0x1bc/0x288
[    1.101790] [<ffffff8008431e00>] drm_fb_helper_initial_config+0x2c0/0x354
[    1.102395] [<ffffff80084630e4>] rockchip_drm_fbdev_init+0xc8/0x104
[    1.102957] [<ffffff8008459fec>] rockchip_drm_load+0x91c/0x9c4
[    1.103478] [<ffffff800843a4c0>] drm_dev_register+0x78/0xc0
[    1.103978] [<ffffff8008458c0c>] rockchip_drm_bind+0x64/0x90
[    1.104488] [<ffffff800849e93c>] try_to_bring_up_master.part.3+0xb0/0x118
[    1.105093] [<ffffff800849eb68>] component_master_add_with_match+0xcc/0x12c
[    1.105714] [<ffffff80084591e0>] rockchip_drm_platform_probe+0x198/0x1c8
[    1.106313] [<ffffff80084a55b0>] platform_drv_probe+0x58/0xa4
[    1.106827] [<ffffff80084a38a0>] driver_probe_device+0x114/0x280
[    1.107362] [<ffffff80084a3b5c>] __device_attach_driver+0x88/0x98
[    1.107905] [<ffffff80084a1d7c>] bus_for_each_drv+0x7c/0xac
[    1.108402] [<ffffff80084a36d8>] __device_attach+0xa8/0x128
[    1.108900] [<ffffff80084a3ca0>] device_initial_probe+0x10/0x18
[    1.109427] [<ffffff80084a2d1c>] bus_probe_device+0x2c/0x8c
[    1.109924] [<ffffff80084a3170>] deferred_probe_work_func+0x74/0xa0
[    1.110486] [<ffffff80080b2e34>] process_one_work+0x218/0x3e0
[    1.111001] [<ffffff80080b3530>] worker_thread+0x24c/0x374
[    1.111490] [<ffffff80080b7dbc>] kthread+0xe8/0xf0
[    1.111922] [<ffffff8008082690>] ret_from_fork+0x10/0x40

Change-Id: I11f667830d913430d9e0b4da2b391815d335ecb8
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

arm64: dts: rockchip: add efuse device node for rk3366

Add a efuse node in the device tree for the ARM64 rk3366 SoC.

Change-Id: I163003e7e181645579a2af53003892ba46646706
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

nvmem: rockchip-efuse: add rk3366-efuse support

This adds the necessary data for handling efuse on the rk3366.

Change-Id: Ia9b03776172c9a66faa7320f7e1890549538a32a
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

clk: rockchip: add clock ids for efuse on RK3366

Set the newly added id for efuse, so that they can be called
in other parts.

Change-Id: Id372ca207901aed689304f862412b2cf1e08fa80
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

input: sensors: fromdos and remove trailing whitespace

Change-Id: I6799f2538f95953d1565ac805497161ce6043855
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

UPSTREAM: clk: rockchip: rk3399: fix copy-paste error

Fix RK3368_* to RK3399_* for rk3399 clk_test clock.

Change-Id: I3be8f582ab9a0ee484bf47e2090f020bbd4a7c72
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9430735/)

clk: rockchip: remove more CLK_IGNORE_UNUSED for rk3399 clocktree

Optimize rk3399 clocktree by removing CLK_IGNORE_UNUSED of some clocks.

clocks will managered by usb:
- clk_usbphy0_480m_src
- clk_usbphy1_480m_src
- clk_usbphy_480m

clocks will be managered by pvtm:
- clk_pvtm_core_l
- clk_pvtm_core_b
- clk_pvtm_ddr

clocks will be managered by dfi:
- pclk_ddr_mon
- clk_dfimon0_timer
- clk_dfimon1_timer
- aclk_dcf
- pclk_dcf

Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9410123/)

Change-Id: I9c32423cafde00fc47673638633ca0c884253f36
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

CHROMIUM: devfreq: rockchip: remove wait dcf irq evnet

We have already wait dcf done in ATF, so don't need wait dcf irq
in kernel, besides, clear dcf irq in kernel will import competiton
between kernel and ATF, only handle dcf irq in ATF is a better way.

BUG=chrome-os-partner:54651
TEST=Boot from kevin

Change-Id: Ibfc460bebb86eb72a218fbf39176d30320da2c57
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

arm64: configs: add some devfreq gov for rk3399 linux

gpu dvfs need SIMPLE_ONDEMAND

Change-Id: I7f3247a7571e40cbfe929996d1c4db4b11ea63a5
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm: configs: add some devfreq gov for rk3288 linux

add more devfreq gov to let driver choose it.

Change-Id: Id47b519e1f41311283bf3f38b94cae3b8480aff4
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

video: rockchip: fb: fix inconsistent returns 'mutex:&dev_drv->front_lock'

Change-Id: If937a6cbc6d89ff0b4dbd2f540a87da1af3c4123
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

video: rockchip: fb: add api to enable mirror for VR

Change-Id: Ic9a6409f0243896021eb94df3600cdc2fc3db637
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

video: rockchip: fb: update for x and y mirror

Change-Id: Ieca4a74af4b4ca2f5d90e7387601e2f87b0ac883
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

arm: configs: enable devfreq thermal for rk3288 linux

to enable gpu

Change-Id: I818b27927847bb1c62f60eb4b0335d1818f30dff
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: confis: enable devfreq thermal for rk3399 linux

to enable gpu freq

Change-Id: I8db7106d34592eb9f90b31838f60aba20313bdb5
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: configs: enable thermal fair share for rk3399 linux

Change-Id: Ic69b404e075dfe2999b88eb5c808e01c10a97d0d
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: signals: avoid random wakeups in sigsuspend()

A random wakeup can get us out of sigsuspend() without TIF_SIGPENDING
being set.

Avoid that by making sure we were signaled, like sys_pause() does.

Change-Id: Ie647d2797416c6e53628174a07b62246e23081e7
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 823dd3224a07f618d652a7743c9603222d019de3)

net: rkwifi: auto recognize nvram file

Change-Id: Ia90c2657f9abf301882678e15ea18c2c17720be1
Signed-off-by: huweiguo <hwg@rock-chips.com>

MALI: midgard: RK: slowdown clk_gpu before poweroff cores

This is a workaround for the issue that
"400M, 500M and 600M of clk_gpu needs high vdd_gpu",
according to "6.2" of Mali Application Note
"Potential glitches on Power Domain interfaces".

Change-Id: I8b8eccd2079e21ac5e1db7b4552c8f998f676a9f
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

Revert "MALI: midgard: RK: not to power off all the pm cores"

This reverts commit 47a9fbf6c4de1dddaf82ed9159307f8ba039f85c.

Change-Id: I4cfc36a5dab7e6cb4a766995d456301c54728498
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

arm64: dts: rockchip: rk3399: modify gpu opp table for evb board

margin 25mV-50mV, stress test:
1. antutu-3d, use governor simpleondemand
2. webgl, fish number 50, sweep frequency
3. glmark2, run texture and shadow, sweep frequency

Change-Id: Ia2682610e948df7df2ad190ac3a28b2dad464cb3
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

pinctrl: rockchip: Fix smatch warning

This patch fix the following warning:
drivers/pinctrl/pinctrl-rockchip.c:1415 rockchip_set_drive_perpin() warn: inconsistent returns 'spin_lock:&bank->slock'.
  Locked on:   line 1377
               line 1384
               line 1393
  Unlocked on: line 1306
               line 1333
               line 1342
               line 1352
               line 1406
               line 1415
drivers/pinctrl/pinctrl-rockchip.c:1415 rockchip_set_drive_perpin() warn: inconsistent returns 'irqsave:flags'.
  Locked on:   line 1377
               line 1384
               line 1393
  Unlocked on: line 1306
               line 1333
               line 1342
               line 1352
               line 1406
               line 1415

Change-Id: I3f97010fbc283084f06b83afcc46ab684d2a11c3
Signed-off-by: David Wu <david.wu@rock-chips.com>

hid: rkvr: fix inconsistent returns in inv_hid_register_devcie()

Change-Id: Ida0a3dff53c9e47dc04b0111ea56500d1adcbb3c
Signed-off-by: lanshh <lsh@rock-chips.com>

CHROMIUM: usb: dwc3: rockchip: avoid removing hcd while system is frozen

Refer to the commit 85fbd722ad0f ("libata, freezer: avoid
block device removal while system is frozen"), when system
enter suspend, it may freeze kthreads and workqueues, and
do not restart them until complete PM resume all of devices.

If we remove XHCI hcd while system is frozen, it may call
usb_disconnect() to remove a usb block device which pluged
in before, but has gone missing. Unfortunately, remove the
block device can race with the rest of device resume. Since
freezable kthreads and workqueues are thawed after all of
devices resume are completed and block device removal depends
on freezable workqueues and kthreads (e.g. bdi_wq) to make
progress, this can lead to deadlock - block device removal
can't proceed because kthreads and workqueues are frozen and
can't be restarted because device resume is blocked behind
block device removal.

This patch must be used and tested with the commit bc68c26eff86
("CHROMIUM: usb: dwc3: rockchip: fix NULL pointer dereference
when resume"). This issue can be easily reproduced with USB-C
HUB and USB2/3 flash drive, result in the following backtrace.

[  360.201135] INFO: task kworker/u12:3:122 blocked for more than 120 seconds.
[  360.208094]       Not tainted 4.4.21 #185
[  360.212102] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  360.219923] kworker/u12:3   D ffffffc000204fd8     0   122      2 0x00000000
[  360.227007] Workqueue: events_unbound async_run_entry_fn
[  360.232326] Call trace:
[  360.234776] [<ffffffc000204fd8>] __switch_to+0x9c/0xa8
[  360.239918] [<ffffffc000915bf4>] __schedule+0x440/0x6d8
[  360.245139] [<ffffffc000915f20>] schedule+0x94/0xb4
[  360.250016] [<ffffffc00091909c>] schedule_timeout+0x44/0x27c
[  360.255670] [<ffffffc000916b78>] wait_for_common+0xf8/0x198
[  360.261237] [<ffffffc000916c40>] wait_for_completion+0x28/0x34
[  360.267067] [<ffffffc0005f3f4c>] dpm_wait+0x40/0x4c
[  360.271942] [<ffffffc0005f4770>] device_resume+0x60/0x1a4
[  360.277337] [<ffffffc0005f48e4>] async_resume+0x30/0x60
[  360.282558] [<ffffffc000242fc4>] async_run_entry_fn+0x50/0x104
[  360.288387] [<ffffffc0002397f0>] process_one_work+0x240/0x424
[  360.294128] [<ffffffc00023a28c>] worker_thread+0x2fc/0x424
[  360.299608] [<ffffffc00023f5fc>] kthread+0x10c/0x114
[  360.304570] [<ffffffc000203dd0>] ret_from_fork+0x10/0x40
[  360.309876]   task                        PC stack   pid father
[  360.315789] init            D ffffffc000204fd8     0     1      0 0x00400009
...
[  360.564124] [<ffffffc000204fd8>] __switch_to+0x9c/0xa8
[  360.569259] [<ffffffc000915bf4>] __schedule+0x440/0x6d8
[  360.574481] [<ffffffc000915f20>] schedule+0x94/0xb4
[  360.579355] [<ffffffc00091909c>] schedule_timeout+0x44/0x27c
[  360.585010] [<ffffffc000916b78>] wait_for_common+0xf8/0x198
[  360.590580] [<ffffffc000916c40>] wait_for_completion+0x28/0x34
[  360.596408] [<ffffffc000239270>] flush_work+0x168/0x1a4
[  360.601629] [<ffffffc0002395a4>] flush_delayed_work+0x44/0x50
[  360.607371] [<ffffffc000322f48>] bdi_unregister+0xa8/0xfc
[  360.612766] [<ffffffc00049afdc>] blk_cleanup_queue+0xf4/0x10c
[  360.618508] [<ffffffc000625d7c>] __scsi_remove_device+0x80/0xc8
[  360.624423] [<ffffffc000623dec>] scsi_forget_host+0x5c/0x74
[  360.629991] [<ffffffc000619a98>] scsi_remove_host+0x90/0x110
[  360.635646] [<ffffffc000692940>] usb_stor_disconnect+0x78/0xec
[  360.641474] [<ffffffc0006545e4>] usb_unbind_interface+0xa0/0x1f8
[  360.647477] [<ffffffc0005e70cc>] __device_release_driver+0xb4/0x114
[  360.653746] [<ffffffc0005e7158>] device_release_driver+0x2c/0x40
[  360.659748] [<ffffffc0005e61f8>] bus_remove_device+0x110/0x128
[  360.665575] [<ffffffc0005e3178>] device_del+0x164/0x1f4
[  360.670797] [<ffffffc000652094>] usb_disable_device+0x94/0x1c8
[  360.676625] [<ffffffc000649b74>] usb_disconnect+0x9c/0x1d0
[  360.682106] [<ffffffc000649b60>] usb_disconnect+0x88/0x1d0
[  360.687587] [<ffffffc00064e0e4>] usb_remove_hcd+0xc8/0x1e0
[  360.693068] [<ffffffc000664b4c>] dwc3_rockchip_otg_extcon_evt_work+0x14c/0x198
[  360.700284] [<ffffffc0002397f0>] process_one_work+0x240/0x424
[  360.706026] [<ffffffc00023a28c>] worker_thread+0x2fc/0x424
[  360.711506] [<ffffffc00023f5fc>] kthread+0x10c/0x114
[  360.716467] [<ffffffc000203dd0>] ret_from_fork+0x10/0x40

BUG=chrome-os-partner:58705, chrome-os-partner:59103
TEST=Plug in USB-C HUB and USB2/3 flash drive, then set
system to enter S3. After system suspend, plug out the
USB-C HUB first, and then press keyboard or power key to
check if system can wakeup successfully.

Change-Id: I6cb8ea1a4399b9b69b522ec0ed5f0f7810118850
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/408499
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: William Wu <wulf@rock-chips.com>

CHROMIUM: usb: dwc3: rockchip: fix NULL pointer dereference when resume

During system PM resume process, if remove XHCI hcd prior to
XHCI controller PM resume, it will result in a crash with
the following backtrace.

[   80.730581] Unable to handle kernel NULL pointer dereference at virtual address 00000138
...
[   80.731780] Call trace:
[   80.731784] [<ffffffc0005e43cc>] dev_driver_string+0x18/0x4c
[   80.731787] [<ffffffc0005e4918>] __dev_printk+0x34/0x88
[   80.731791] [<ffffffc0005e4da0>] dev_warn+0x7c/0xa0
[   80.731796] [<ffffffc000651ef8>] usb_root_hub_lost_power+0x28/0x40
[   80.731801] [<ffffffc0006866e8>] xhci_resume+0x250/0x444
[   80.731805] [<ffffffc00069612c>] xhci_plat_resume+0x44/0x64
[   80.731811] [<ffffffc0005ea878>] platform_pm_resume+0x50/0x64
[   80.731816] [<ffffffc0005f6354>] dpm_run_callback+0xb0/0x198
[   80.731819] [<ffffffc0005f68f4>] device_resume+0x160/0x19c
[   80.731822] [<ffffffc0005f6960>] async_resume+0x30/0x60
[   80.731827] [<ffffffc000242b88>] async_run_entry_fn+0x50/0xfc
[   80.731832] [<ffffffc000238e38>] process_one_work+0x230/0x3dc
[   80.731837] [<ffffffc000239db8>] worker_thread+0x248/0x370
[   80.731840] [<ffffffc00023f23c>] kthread+0x10c/0x114
[   80.731845] [<ffffffc000203d90>] ret_from_fork+0x10/0x40

It's because that when do PM resume, dwc3_rockchip_resume() will
be called before XHCI resume, and it will remove XHCI hcd and set
rhdev->dev to NULL, this cause rhdev->dev NULL pointer dereference
in XHCI resume.

So we need to check the flag dwc->xhci->dev.power.is_suspended to
ensure that XHCI has been resumed completely from pm suspended state
before remove XHCI hcd.

BUG=chrome-os-partner:58705
TEST=Plug in Type-C USB device, then set system to enter S3.
After system suspend, plug out the Type-C USB device first,
and then press keyboard or power key to check if system can
wakeup successfully.

Change-Id: I90fc48f5d3af8d08a290861ad7fcdaa5e4352320
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/408498
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: William Wu <wulf@rock-chips.com>

CHROMIUM: xhci: fix hung task timeout when rm xhci-hcd

On some special platforms (e.g. rk3399), they will call
usb_remove_hcd() to remove xhci hcd if no device connected,
and add xhci hcd again when detect usb device. But they
just simply remove xhci hcd, and the usb core hub_event
don't know it at all. The hub_event just find usb device
disconnect, and try to call usb_disconnect() -> usb_disable
_endpoint() -> usb_kill_urb() -> usb_hcd_unlink_urb() ->
xhci_urb_dequeue -> queue a stop endpoint command, and
then the usb_kill_urb will wait_event(usb_kill_urb_queue,
atomic_read(&urb->use_count) == 0).

But in this case, we have removed xhci hcd and stop xhci
controller, so xhci can't complete stop endpoint command
and fail to call usb_hcd_giveback_urb() which can wakeup
usb_kill_urb_queue, this cause stall in usb_kill_urb()
with the following backstrace.

[  240.202208] INFO: task kworker/0:2:130 blocked for more than 120 seconds.
[  240.208996]       Not tainted 4.4.21 #454
[  240.213008] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.220828] kworker/0:2     D ffffffc000204fd8     0   130      2 0x00000000
[  240.227919] Workqueue: usb_hub_wq hub_event
[  240.232117] Call trace:
[  240.234576] [<ffffffc000204fd8>] __switch_to+0x9c/0xa8
[  240.239713] [<ffffffc000919cb4>] __schedule+0x440/0x6d8
[  240.244938] [<ffffffc000919fe0>] schedule+0x94/0xb4
[  240.249814] [<ffffffc000654530>] usb_kill_urb+0xc4/0x110
[  240.255128] [<ffffffc000653538>] usb_hcd_flush_endpoint+0x128/0x148
[  240.261755] [<ffffffc0006560e4>] usb_disable_endpoint+0x70/0xa4
[  240.267679] [<ffffffc00065617c>] usb_disable_interface+0x64/0x7c
[  240.273680] [<ffffffc000658760>] usb_unbind_interface+0x88/0x1f8
[  240.279687] [<ffffffc0005eb260>] __device_release_driver+0xb4/0x114
[  240.285952] [<ffffffc0005eb2ec>] device_release_driver+0x2c/0x40
[  240.291956] [<ffffffc0005ea38c>] bus_remove_device+0x110/0x128
[  240.297783] [<ffffffc0005e730c>] device_del+0x164/0x1f4
[  240.303006] [<ffffffc000656228>] usb_disable_device+0x94/0x1c8
[  240.308834] [<ffffffc00064dd08>] usb_disconnect+0x9c/0x1d0
[  240.314317] [<ffffffc00064f51c>] hub_event+0x58c/0xde0
[  240.319451] [<ffffffc0002397f0>] process_one_work+0x240/0x424
[  240.325193] [<ffffffc00023a28c>] worker_thread+0x2fc/0x424
[  240.330725] [<ffffffc00023f5fc>] kthread+0x10c/0x114
[  240.335708] [<ffffffc000203dd0>] ret_from_fork+0x10/0x40
...
[  240.466674] kworker/4:2     D ffffffc000204fd8     0   153      2 0x00000000
[  240.473752] Workqueue: events dwc3_rockchip_otg_extcon_evt_work
[  240.479680] Call trace:
[  240.482131] [<ffffffc000204fd8>] __switch_to+0x9c/0xa8
[  240.487265] [<ffffffc000919cb4>] __schedule+0x440/0x6d8
[  240.492487] [<ffffffc000919fe0>] schedule+0x94/0xb4
[  240.497361] [<ffffffc00091a364>] schedule_preempt_disabled+0x28/0x44
[  240.503713] [<ffffffc00091be20>] __mutex_lock_slowpath+0x120/0x1ac
[  240.509885] [<ffffffc00091bef8>] mutex_lock+0x4c/0x68
[  240.514936] [<ffffffc00064dcc8>] usb_disconnect+0x5c/0x1d0
[  240.520415] [<ffffffc000652278>] usb_remove_hcd+0xc8/0x1e0
[  240.525899] [<ffffffc000668ce8>] dwc3_rockchip_otg_extcon_evt_work+0x154/0x198
[  240.533112] [<ffffffc0002397f0>] process_one_work+0x240/0x424
[  240.538856] [<ffffffc00023a28c>] worker_thread+0x2fc/0x424
[  240.544335] [<ffffffc00023f5fc>] kthread+0x10c/0x114
[  240.549296] [<ffffffc000203dd0>] ret_from_fork+0x10/0x40

This patch try to do the same thing as XHCI_STATE_HALTED in
xhci_urb_dequeue() if xhci->xhc_state is XHCI_STATE_REMOVING.
Because XHCI_STATE_REMOVING means that we are removing xhci
hcd, and need to call usb_hcd_giveback_urb() directly without
queueing any stop endpoint command.

In addition, this patch also forbid xhci to queue command or
slot control if it's in XHCI_STATE_REMOVING. It maybe helpful
to avoid the other unexpected problems, though I haven't met
them so far.

BUG=chrome-os-partner:59103
TEST=do plug/unplug USB-C HUB with an USB3 flash drive,
check if kernel blocked for more than 120 seconds.

Change-Id: I35ec94dcc742d29d52f73fa30f79cf005063ea55
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/408127
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Inno Park <ih.yoo.park@samsung.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: William Wu <wulf@rock-chips.com>

CHROMIUM: usb: dwc3: rockchip: Check for plug/unplug events on resume

Check on resume if the cable state has changed to detect devices
(un)plugged during suspend.

TEST=build and boot on rk3399 board. No USB device plugged. Set
system enter suspend. Wait for device to suspend. Plug USB device.
Wakeup system; Verify USB device is enumerated.

Change-Id: Iadbefe6737fa3ddfe2da1a66473f876411a4412a
Signed-off-by: William Wu <wulf@rock-chips.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395528
Reviewed-by: Guenter Roeck <groeck@chromium.org>

rockchip/vcodec: fix double lock and some warning

fix following problems:

vcodec_service.c:1613 try_set_reg()
error: double lock 'mutex:&pservice->shutdown_lock'
vcodec_service.c:1682 try_set_reg()
warn: inconsistent returns 'mutex:&pservice->shutdown_lock'.
  Locked on:   line 1614
  Unlocked on: line 1682

vcodec_service.c:599 vpu_get_clk()
warn: missing break? reassigning 'pservice->pd_video'
vcodec_service.c:901 vcodec_fd_to_iova()
warn: returning -1 instead of -ENOMEM is sloppy
vcodec_service.c:1100 vcodec_bufid_to_iova()
warn: returning -1 instead of -ENOMEM is sloppy
vcodec_service.c:1209 reg_init()
warn: passing __func__ while the format string already
contains the name of the function 'reg_init'
vcodec_service.c:1231 reg_init()
warn: passing __func__ while the format string already
contains the name of the function 'reg_init'
vcodec_service.c:1237 reg_init()
warn: passing __func__ while the format string already
contains the name of the function 'reg_init'
vcodec_service.c:1714 return_reg()
warn: passing __func__ while the format string already
contains the name of the function 'return_reg'

Change-Id: Ia2d3be7ad7a726d9af9e58c25079e6c11a7d302f
Signed-off-by: alpha lin <alpha.lin@rock-chips.com>

vidro/rockchip: Fix rga2 driver

1.If rga get the mmu error, we must unlock the lock
or it will lead the next frame timeout.
2.calculate the rga mmu buf back length size in the
rga time out handler or it will lead the next frame
get mmu lentch wrong.

Change-Id: If85751bd292774a1d0ef9693b7f8ad92a4727c07
Signed-off-by: Zikim,Wei <wzq@rock-chips.com>

vidro/rockchip: fix rga1 driver deadlock

If rga get the mmu error, we must unlock the lock
or it will lead the next frame timeout.

Change-Id: I377217ea417de8e4d3f4ff63e478db1370951e62
Signed-off-by: Zikim,Wei <wzq@rock-chips.com>
(cherry picked from commit f453db8699919760a2297a7d2512f3c03c3edf25)

input: sensor-dev: fix smatch warning

fix below warnings:
sensor-dev.c:1016 gyro_dev_ioctl() warn: inconsistent returns 'mutex:&sensor->operation_mutex'.
  Locked on:   line 973
               line 982
  Unlocked on: line 919
               line 1010
               line 1016
sensor-dev.c:1905 sensor_probe() error: potential null dereference 'sensor->input_dev'.  (input_allocate_device returns null)
sensor-dev.c:1905 sensor_probe() error: we previously assumed 'sensor->input_dev' could be null (see line 1902)
sensor-dev.c:2051 sensor_probe() error: don't call input_free_device() after input_unregister_device()
sensor-dev.c:2080 sensor_remove() error: don't call input_free_device() after input_unregister_device()

Change-Id: I7da8a337282df7f9b8e6474a68928fc53d4e6890
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 08fd14ea02692f43eaa8a166791cdaaa4b6c0738)

arm64: dts: rockchip: add pvtm node for rk3399

Change-Id: Ic7becefeb7e7a1000b259c21fedda76794b7115c
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

arm64: dts: rockchip: add pvtm node for rk3366

Change-Id: Ic90466538671e69aaea82b0b20afdcb39ecf7006
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

arm64: rockchip_defconfig: enable pvtm

Change-Id: I726bddec7625540ff3b3b58cf4c3c9ee842d50da
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

soc: rockchip: pvtm: add driver handling Rockchip pvtm

This patch supports acquiring pvtm values.

Change-Id: I20c0c5a5136371880da1c246b0d71c7a2bddc1d6
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

dt-bindings: add binding document for Rockchip pvtm

This patch documents the Rockchip pvtm device tree binding.

Change-Id: I7edcd1d57ff2852eb6e6897680566abb7f9e76a9
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

clk: rockchip: rk3399: delete the CLK_IGNORE_UNUSED for pvtm clks

These clks will be enabed and disabled in pvtm driver.

Change-Id: I742a8c4ef5877486fb21c014f1e4ab27f72e468d
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

arm64: dts: rockchip: rk3399: add aclk_gpu init freq

Make sure the aclk_gpu freq is safety.
After soft reset the vdd_gpu is maintain
the voltage value before reset.

Change-Id: I3509b211d74cf649067090d13ce20d5c62782fd7
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

arm64: dts: rockchip: add power button for rk3399 excavator linux

Change-Id: I5c69940b93dec8a04f72e7240fc732071d0187ed
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: dts: rockchip: add reset unit in saradc for rk3399

Change-Id: Iee831c8b4bc39cb324ee31ace9d98d235aaf7555
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

rockchip/rga: rga driver fix compat ptr from u64

Change-Id: I23cff21aab9af09989b8b2332e7a2ef3ffc8bfb8
Signed-off-by: Zikim,Wei <wzq@rock-chips.com>

soc: rockchip: pm_test: add driver handling Rockchip pm_test

Add /sys/pm_tests/ node, only for internal testing.

Change-Id: I1fe9f09e6d410c9ed939666255111d2a8865466c
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

video: rockchip: sysfs: fixup dump_buf node

Change-Id: Ie2e86d65b3db58f45c8c49894f506ab52b125c25
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

arm64: dts: rockchip: add dp defaule mode for rk3399 discrete vr

Change-Id: Icc25da3598d9a7475817aebdc101f5d77f58624c
Signed-off-by: wjh <wjh@rock-chips.com>

video: rockchip: dp: get edid for discrete vr

Change-Id: Id791e838e37e76f72202731e53afd2533e653069
Signed-off-by: wjh <wjh@rock-chips.com>

video: rockchip: rk322x: use htotal to adjust fps

Use dclk to adjust fps may effect many things, some display
controller also need to know dclk update, such as mipi.
So if we change fps by dclk, we need update mipi or other
display controller, it waste time and screen would flash

From the fps formula: fps = dclk / htotal * vtotal

Instead change dclk, we also can modify fps by htotal or vtotal.

On testing, vtotal would effect display, use htotal is more safe.

Change-Id: I67d58a815eae150b4e6390b6608557b87d43a27b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

video: rockchip: rk322x: keep vop standby before enable iommu

Vop may access illegal address and cause bus error with:
    1, vop iommu is disable
    2, vop is enable and its window use a iommu mapping address

The illegal memory access may cause bus abnormal.

Change-Id: I17d52ae12140b9bf85d37123765f7163422ec8f5
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

UPSTREAM: arm64: dts: rockchip: add powerdomain for typec on rk3399

The tcpc power domain will try to power up/down the power of Type-C PHY.
Hence, we need control it in Type-C PHY driver with the pm_runtime helper.

Change-Id: I7697c50bb8538c00bb0fa14c92cc1e55bcdd4025
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from git.kernel.org next/linux-next.git master
 commit 06ad4b2fad80713c50a31da6d1048cb1df728558)

FROMLIST: phy: rockchip-typec: add pm_runtime_disable in err case

Add pm_runtime_disable in err case to make the pm_runtime_enable/disable
is invoked balanced.

BUG=chrome-os-partner:52872
TEST=Check DP display and USB3

Change-Id: Ifc66a3e80d7b580963e609d2f14cea239104724c
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9321849/)
Reviewed-on: https://chromium-review.googlesource.com/382723
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: William Wu <wulf@rock-chips.com>

UPSTREAM: phy: rockchip-typec: add pm runtime support

Adds pm_runtime support for rockchip Type-C, so that power domain is
enabled only when there is a transaction going on to help save power.

BUG=chrome-os-partner:52872
TEST=Check DP display and USB3

Change-Id: I072fd06eaa4dfc4b4f598c4a6a3972ee458b833f
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
(cherry picked from git.kernel.org kishon/linux-phy.git next
 commit 15ab5499bd837b1d70287da747dc3d9762ab320a)
Reviewed-on: https://chromium-review.googlesource.com/382113
Reviewed-by: Brian Norris <briannorris@chromium.org>

arm64: configs: enable drm rga in linux config

Change-Id: I92985f4e1f8cf18d2f0f578e3d039b45e5f445fb
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: configs: enable extcon in linux config

Change-Id: I071fa1e075a5495be58315d47cc2a767ae09bd75
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: sched/preempt: Fix preempt_count manipulations

Vikram reported that his ARM64 compiler managed to 'optimize' away the
preempt_count manipulations in code like:

preempt_enable_no_resched();
put_user();
preempt_disable();

Irrespective of that fact that that is horrible code that should be
fixed for many reasons, it does highlight a deficiency in the generic
preempt_count manipulators. As it is never right to combine/elide
preempt_count manipulations like this.

Therefore sprinkle some volatile in the two generic accessors to
ensure the compiler is aware of the fact that the preempt_count is
observed outside of the regular program-order view and thus cannot be
optimized away like this.

x86; the only arch not using the generic code is not affected as we
do all this in asm in order to use the segment base per-cpu stuff.

Change-Id: I13da06ddb17c533b8150f008514a4c74723b1742
Reported-by: Vikram Mulukutla <markivx@codeaurora.org>
Tested-by: Vikram Mulukutla <markivx@codeaurora.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: a787870924db ("sched, arch: Create asm/preempt.h")
Link: http://lkml.kernel.org/r/20160516131751.GH3205@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 2e636d5e66c35dfcbaf617aa8fa963f6847478fe)

arm64: rockchip_defconfig: enable HARDENED_USERCOPY

e41543b2d15f ("ANDROID: android-base: CONFIG_HARDENED_USERCOPY=y")

Change-Id: I4d2805c318f2fb65ae3c780aac26672bfc41be34
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

arm64: rockchip_defconfig: enable CC_STACKPROTECTOR_STRONG

df9e01a6c5d4 ("android-recommended.cfg: enable fstack-protector-strong")

If compiler has stack protector support, set
CONFIG_CC_STACKPROTECTOR_STRONG.

Change-Id: Icd3535b88fb7d62c135da72ae0921f7f4949efe4
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

UPSTREAM: f2fs: avoid hungtask problem caused by losing wake_up

The D state of wait_on_all_pages_writeback should be waken by
function f2fs_write_end_io when all writeback pages have been
succesfully written to device. It's possible that wake_up comes
between get_pages and io_schedule. Maybe in this case it will
lost wake_up and still in D state even if all pages have been
write back to device, and finally, the whole system will be into
the hungtask state.

                if (!get_pages(sbi, F2FS_WRITEBACK))
                         break;
<---------  wake_up
                io_schedule();

Change-Id: I8a60393c91343d75b7d48df2ca19d1735d69cc51
Signed-off-by: Yunlei He <heyunlei@huawei.com>
Signed-off-by: Biao He <hebiao6@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 0ff21646f2a5c6ff77acc51eb3df4235af39be46)
Signed-off-by: Cliff Chen <cliff.chen@rock-chips.com>

arm64: configs: add missing usb config in rockchip linux

Change-Id: I39f908c4427799a2728f7bc5f39e20accd126901
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: configs: rockchip: enable configfs usb gadget and otg in rockchip_linux_defconfig

Change-Id: I3d260fe97fe3dad2101a4cc54a604f8eca7ed248
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

Revert "arm64: dts: rk3399-sapphire: add vbus-5v gpio control in fusb302 node."

This reverts commit cb3e42dc8cf5e1e0431535a2fbe2a39dfac91d39.

This will make usb port in my board can't work, no 5v voltage.
Is it no issues in android?

Change-Id: I95fbd957d0ddb5fddf215d3b00ef74aae8af08d3
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

drm: support ignore drm ioctl permission

Change-Id: I269766a9f3f844933bd294ce681466f5a97b1d43
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

UPSTREAM: arm64: dts: rockchip: add the tcpc for rk3399 power domain

The tcpc is the Type C Port Controller and Type C Port Delivery (tcpd)
is part of it, we haven't used them now, add it to save power consumption.

Change-Id: Ia1046fd3bb7382498811159d8280ee46b3753ebd
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 4a3a3d32c77f942a10c0319f589186a768821397)

UPSTREAM: soc: rockchip: power-domain: avoid infinite loop

In some cases, we have met the infinite loop in
rockchip_pmu_set_idle_request() or rockchip_do_pmu_set_power_domain().

As the crosbug.com/p/57351 reported, the boot hangs right after this
[1.629163] bootconsole [uart8250] disabled
[1.639286] [drm:drm_core_init] Initialized drm 1.1.0 20060810
[1.645926] [drm:drm_get_platform_dev] Initialized vgem 1.0.0 20120112..
[1.654558] iommu: Adding device ff8f0000.vop to group 0
[1.660569] iommu: Adding device ff900000.vop to group 1
<hang>

This patch adds the error message and timeout to avoid infinite loop if
it fails to get the ack.

Change-Id: Ia1e2edbdb48de3ec776f1304a941136d3e7a1854
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git.kernel.org mmind/linux-rockchip.git
 v4.10-armsoc/drivers commit e4c8cd82d5e1146590611c393001d846535bac5b)

ARM64: dts: rk3399: support cluster idle feature

Add cluster sleep in cpu idle_states for RK3399 SoCs.

Change-Id: I85ea62f9af0d0c61e866a1937f79921d854fd1dc
Signed-off-by: tony.xie <tony.xie@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

MALI: midgard: ARM: patch for fence timeout in monkey test

comes from mali support case [TAC674871].

Change-Id: I5e7c54190e24eea0306a9d64545482c6209a2c0d
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

rk: gcc-wrapper.py ignore memcontrol.c:5346

Change-Id: I19b5f58f395cce934fe2efbb01267576b7772c02
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

arm64: rockchip_defconfig: enable cpu avs

Change-Id: I626d1d238ea8efa38763fb6360936ce13c0c17fe
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs

This patch supports adjusting opp's voltage according to leakage

Change-Id: Ifbb6b6fec03abe0c7708a148affe4d7646ce38fa
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>