camera: camsys_drv: v0.0x21.6 support drm

Change-Id: If0305388c5b445adbcf693504849a6be000e64a9
Signed-off-by: dalong.zhang <dalon.zhang@rock-chips.com>

ARM64: dts: rk3399-evb-rev1-android: enable isp0&isp1

Change-Id: I88dda6f8e90f549ff1bbe791acec94eae30fdd45
Signed-off-by: dalong.zhang <dalon.zhang@rock-chips.com>

UPSTREAM: iommu/rockchip: Don't feed NULL res pointers to devres

If we do, devres prints a "invalid resource" string in the error
loglevel.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 8d7f2d84ed2d44b05e1ce88fa4b74886af46a139)

Change-Id: I3849bcaa4ceaea3247a8169b2a123a834011fbc5
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>

Revert "iommu/rockchip: fix bool operation error and probe warning"

This reverts commit e0492807e6b91becccbcab6eca1df27da55d726b.

Same issue fixed by upstream(e04928 "iommu/rockchip: fix bool operation
error and probe warning) which picked as (2e7026 "UPSTREAM: iommu/rockchip:
Fix "is stall active" check).

Conflicts:
drivers/iommu/rockchip-iommu.c

Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Change-Id: I56e61894b1da14bce78ae1b3d08158dfb5b027bb

CHROMIUM: iommu/rockchip: Fix TLB flush of secondary IOMMUs

Due to the bug in current code, only first IOMMU has the TLB lines
flushed in rk_iommu_zap_lines. This patch fixes the inner loop to
execute for all IOMMUs and properly flush the TLB.

BUG=chrome-os-partner:55135
TEST=compile

Change-Id: Ica2d4b0cc3d3cbc88c70ad541dc00883f1b4e90c
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/371098
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Randy Li <randy.li@rock-chips.com>

drm/rockchip: vop: fix scale abnormal after window power on/off

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

camera: rockchip: porting ov8858&ov4689&ov2710 driver

Change-Id: Ia9a0a39d347a9fd506f493c6639785267233e0ac
Signed-off-by: dalong.zhang <dalon.zhang@rock-chips.com>

ARM64: dts: rk3399: move opp tables to rk3399-opp.dtsi

Add a new dtsi file - rk3399-opp.dtsi, to configure opp-tables
for cpu, gpu and dmc.

Add rk3399-early-opp.dtsi for board with ES1, which need limit
frequency for cpu, gpu and dmc.

Change-Id: Ib57761fd5f405b0e79039d7a01e6e023d6f5dc2c
Reviewed-by: Finley Xiao <finley.xiao@rock-chips.com>
Reviewed-by: Huang, Tao <huangtao@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

ARM: dts: rockchip: add vpu service for RK3288

It is not harm to keep both vpu service and vpu v4l2 at the same time,
that the board file choose a driver implementation and interace to
be used.

Change-Id: If79deac5bf19395cfdca821f20486985e3034389
Signed-off-by: Randy Li <randy.li@rock-chips.com>

ARM: dts: enable SD and GMAC at rk3288-evb

There is a bug in GMAC IP, it supports RGMII clock but not a speed
mode for it.

Change-Id: I8e5cca355c30920db37400901d3411eebca711ae
Signed-off-by: Randy Li <randy.li@rock-chips.com>

isp10: rockchip: v0.1.6

Change-Id: I1b702fb51d1baabd47f190fdafd79ecd22e18be0
Signed-off-by: dalong.zhang <dalon.zhang@rock-chips.com>

ARM64: dts: rk3399-evb-rev3-android: enable isp0&isp1

Change-Id: Ib2d4f304e2fc4589d55e60d452571ed46e5dae4d
Signed-off-by: dalong.zhang <dalon.zhang@rock-chips.com>

ARM64: dts: rk3399-evb-rev2-android: enable isp0&isp1

Change-Id: Ibd5244985eb707ca9119191cf019b56ae9055eb4
Signed-off-by: dalong.zhang <dalon.zhang@rock-chips.com>

ARM64: dts: rk3399-android: add isp0 node for isp10

Change-Id: I1324bd021ec87f10ad4b5fd200bdf83efd1dab66
Signed-off-by: dalong.zhang <dalon.zhang@rock-chips.com>

devfreq: rockchip: dmc: support sharing regulator with other devices

If the regulator is shared between several devices then the lowest
request voltage that meets the system constraints will be used.

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

MALI: midgard: support sharing regulator with other devices

If the regulator is shared between several devices then the lowest
request voltage that meets the system constraints will be used.

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

devfreq: rockchip: avoid DDR voltage domain keeping the initial voltage

If there is only one opp whose frequency is equal to the initial value
in opp table list, the DDR voltage domain will keep the initial voltage,
it may be too large.

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

MALI: midgard: avoid GPU voltage domain keeping the initial voltage

If there is only one opp whose frequency is equal to the initial value
in opp table list, the GPU voltage domain will keep the initial voltage,
it may be too large.

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

PM / AVS: rockchip-cpu-avs: support adjusting initial frequency and voltage

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

cpufreq: dt: delete flag CPUFREQ_NEED_INITIAL_FREQ_CHECK

As there are still some limitations, we prefer to implement it ourselves.

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

PM / OPP: Add dev_pm_opp_check_initial_rate()

Bootloader or kernel sets CPU frequency to an initial value before cpufreq
starts on rockchip platform, if cpu's opp table is modified to a specified
value, it will cause an issue.

For example, the initial frequency is 816MHz and voltage set by hardware
is 900mV:
1. there is only one opp whose frequency is 816MHz and voltage is 850mV
in opp table list, as they frequency is equal, the voltage will not be
changed, it is still 900mV and a little too large relative to 850mV.
2. there is only one opp whose frequency is 1200MHz and voltage is 1100mV
in opp table list, as it doesn't set voltage to 1100mV before set frequency
to 1200MHz in the dev_pm_opp_set_rate function, the initial voltage 900mV
cann't supply for 1200MHz, the system crash.

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

UPSTREAM: iommu/rockchip: Prepare to support generic DMA mapping

Set geometry for allocated domains and fix .domain_alloc() callback to
work with IOMMU_DOMAIN_DMA domain type, which is used for implicit
domains on ARM64.

Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit a93db2f22b6b48369acb72f66a0ae47ec17a0b05)

Change-Id: Ib04827afadbfb32ca52c6842cd056952269cbe93
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>

UPSTREAM: iommu/rockchip: Use DMA API to manage coherency

Use DMA API instead of architecture internal functions like
__cpuc_flush_dcache_area() etc.

The biggest difficulty here is that dma_map and _sync calls require some
struct device, while there is no real 1:1 relation between an IOMMU
domain and some device. To overcome this, a simple platform device is
registered for each allocated IOMMU domain.

With this patch, this driver can be used on both ARM and ARM64
platforms, such as RK3288 and RK3399 respectively.

Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 4f0aba676735c653b4e739b760c1e66cd520d3e3)

Conflicts:
drivers/iommu/rockchip-iommu.c

Change-Id: I0424318ed0cea947e7c8f8d3b52f716f6cc98ce0
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>

UPSTREAM: iommu/rockchip: Fix allocation of bases array in driver probe

In .probe(), devm_kzalloc() is called with size == 0 and works only
by luck, due to internal behavior of the allocator and the fact
that the proper allocation size is small. Let's use proper value for
calculating the size.

Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 3d08f434bd58656ae630376d0b5afd6ca1ffb013)

Change-Id: I78db8fbf3cb781745a05f8bee492dd7e8ac784c5
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>

UPSTREAM: iommu/rockchip: Fix zap cache during device attach

rk_iommu_command() takes a struct rk_iommu and iterates over the slave
MMUs, so this is doubly wrong in that we're passing in the wrong pointer
and talking to MMUs that we shouldn't be.

Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")
Cc: stable@vger.kernel.org
Signed-off-by: John Keeping <john@metanate.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit ae8a7910fb0568531033bd6ebe65590f7a4fa6e2)

Change-Id: I5d6f5dd49ad0f79facee8d345c5058af80226f83
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>

UPSTREAM: iommu/rockchip: Fix "is stall active" check

Since commit cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi
slaves") rk_iommu_is_stall_active() always returns false because the
bitwise AND operates on the boolean flag promoted to an integer and a
value that is either zero or BIT(2).

Explicitly convert the right-hand value to a boolean so that both sides
are guaranteed to be either zero or one.

rk_iommu_is_paging_enabled() does not suffer from the same problem since
RK_MMU_STATUS_PAGING_ENABLED is BIT(0), but let's apply the same change
for consistency and to make it clear that it's correct without needing
to lookup the value.

Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit fbedd9b9905c1643b9f7244d88999e39632bbd87)

Conflicts:
drivers/iommu/rockchip-iommu.c

Change-Id: I5a43eb19d515eba7daf1dc4b1592ac692c115df0
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>

UPSTREAM: arm64: dts: rockchip: add gmac needed pclk for rk3399 pd

This patch fixes that sometimes hang at start-up time of the system.
As the below log:
...
[   11.136543] calling  pm_genpd_debug_init+0x0/0x60 @ 1
[   11.141602] initcall pm_genpd_debug_init+0x0/0x60 returned 0 after 11 usecs
[   11.148558] calling  genpd_poweroff_unused+0x0/0x84 @ 1
<hang>

In some cases, the rk3399 should turn off the gmac power domain to save
power if some boards didn't register the gmac device node for rk3399.
Then, rk3399 need to make sure the gmac's pclk enabled if we need
operate the gmac power domain. (Due to the NOC had enabled always)

Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(am from git/mmind/linux-rockchip.git branch for-next
 commit 2afc1db0c5bad5da75556889ebc3e75661be9028)

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

drm/rockchip: vop: fix display flash when switch to iommu mapping

Do iommu mapping with looping vop vblank register have a problem, when
iommu attach take too long time or vblank time is too short, the display
would flash.

This patch use another method to fix this problem:
  Use standby and dsp_hold interrupt to enter vblank time, when iommu
  mapping is finish, exit vop standby, then vop would start scanout
  immediately,
      vop enter standby    -> |
      dsp_hold irq         -> |--------- vblank start
      do iommu mapping     -> | vblank time
      exit standby         -> |--------- vblank end

We try add 20ms delay to iommu attach, display also looks good, that
means this method have higher compatibility.

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

drm: rockchip: sync rga driver from 3.14

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

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>