gslxxxx wrong irq number with the same vopb, may cause vopb abnormal.
ts->irq is gpio number, gslxxxx irq number is ts->client->irq
ts->client->irq = gpio_to_irq(ts->irq)
Change-Id: Ic1f6a46437a2a185f3218d3f0406deeddd9d670a
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
The newly added OTG support has an obvious uninitialized variable
access that gcc warns about:
drivers/phy/phy-rockchip-inno-usb2.c: In function 'rockchip_chg_detect_work':
drivers/phy/phy-rockchip-inno-usb2.c:717:7: error: 'tmout' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This replaces the use of the uninitialized variable with what
the value was in the previous USB_CHG_STATE_WAIT_FOR_DCD
state.
Change-Id: Ibeed4872e1168e135a332a0978d85a4e48083267
Fixes: 0c42fe48fd23 ("phy: rockchip-inno-usb2: support otg-port for rk3399")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: William Wu <wulf@rock-chips.com>
(cherry picked from git.kernel.org kishon/linux-phy next
commit dd796e921e)
The linestate change interrupt may occur during suspend if port is
not connected. This patch pull down dp/dm when suspend.
Change-Id: I31e992727ea63efbda4ecec7ad3af02626eceb44
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).
We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.
We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset. The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).
It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.
Change-Id: I3120a38a7f646a9d244f04bd2dcfef7474a4a6d1
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(am from https://mail-archive.com/linux-kernel@vger.kernel.org/msg1254059.html)
The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup. We'll use the reset that's in the CRU to reset the
port when it's in a bad state.
Note that we add the reset to both dwc2 controllers even though only one
has the errata in case we find some other use for this reset that's
unrelated to the current hardware errata. Only the host port gets the
quirk property, though.
Change-Id: I472d33fb1db8b1a6b0c4fcea9ab31fd85b61af40
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9324169/)
The opp who contains a opp-suspend property will be configured
during suspend or reboot.
Change-Id: I6b2eede43216435f568db6959127a6e84c8cd4c8
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Sometimes all cpus of big cluster are closed and its frequency
keep a high value, in order to reduce power and reset normally,
set frequency to a specific value after close all the cpus.
Change-Id: I88bce25812d1b0ff3f78a898cb161642a65cc523
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
We need to put the power status of HEVC IP into IDLE unless
we can't reset that IP or the SoC would crash down.
rockchip_pmu_idle_request(dev, true)---> enter idle
rockchip_pmu_idle_request(dev, false)---> exit idle
Change-Id: I76733efd2de4f7ee183c1b6bd1545d60038ee31b
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
When mapping buffers through the PRIME DMA-buf mmap path we might be
given an offset which has to be respected. The DRM GEM mmap path already
takes care of zeroing out the fake mmap offset, so we can just make the
IOMMU mmap implementation always respect the offset.
BUG=chrome-os-partner:56615
TEST=graphics_GLBench
Change-Id: Iec83e720b24ddd35a92f3df8312015bc5af798f0
Signed-off-by: rjan Eide <orjan.eide@arm.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/386477
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma->vm_pgoff,
which breaks the former.
This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.
BUG=chrome-os-partner:56615
TEST=graphics_GLBench
Change-Id: Iec6e996707b0fe7e95a019423a944d98c80beaab
Signed-off-by: rjan Eide <orjan.eide@arm.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381332
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
When converting the driver to use shmem-backed GEMs for IOMMU-enabled
systems, we forgot to add calls to drm_gem_object_release(), which gave
us a quite nice memory leak. This patch adds the missing calls.
Fixes: f11d5f0 ("FROMLIST: drm/rockchip: Do not use DMA mapping API if
attached to IOMMU domain")
BUG=chrome-os-partner:57158
TEST=while true; do backlight_dbus_tool --set --percent=0 && sleep 8 &&
backlight_dbus_tool --set --percent=100 && sleep 3 ; done
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/385456
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_gem.c
Change-Id: I3c7b21ed22cfb38f512150f76fced3b0cc2b296d
Signed-off-by: Randy Li <randy.li@rock-chips.com>
When freeing the buffer we don't have any means of determining if the
buffer was read or written, so we must assume both and pass true for
both arguments of drm_gem_put_pages(). Let's fix the code which
currently passes false.
BUG=chrome-os-partner:56378
TEST=while true; do backlight_dbus_tool --set --percent=0 && sleep 8 &&
backlight_dbus_tool --set --percent=100 && sleep 3 ; done
Change-Id: I7da2fd81e7e728e0ef242837b70819c4a3aee7bf
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382934
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.
Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API anymore and this patch wires
things to use the new method.
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
(am from https://patchwork.kernel.org/patch/9196389/)
BUG=chrome-os-partner:53565
TEST=boot to ui on Gru
Reviewed-on: https://chromium-review.googlesource.com/349521
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c
Change-Id: Ide4ce9f74fd431f0b7cd480e38b683f833733b40
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Some rockchip vop not support iommu, need use non-iommu
buffer for it. And if we get iommu issues, we can compare
the issues with non-iommu path, that would help the debug.
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c
Change-Id: I843f087281300359b07faac1de156cd648325b45
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(cherry picked from commit 2d90d47743)
arm_iommu_attach_device() takes its own reference to the mapping we give
it. Since we do not keep a reference to the mapping ourselves, we must
release it before returning.
Also fix the error path, which fails to release the mapping if it has
called arm_iommu_detach_device() since that clears archdata.mapping.
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c
Change-Id: Ia20334afbce08ece5a3238a7b0786547ec0cafb2
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 69b007968e)
The call to arm_iommu_detach_device() on the previous line sets
dev->archdata.mapping to NULL so this call is always a no-op.
Change-Id: I09b41c284c61885fb4b989a64839e96bcc316aa6
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit aa1ac27f48)
The prime fd to handle ioctl was not used with rockchip before. Support
was added in order to pass graphics_Gbm and to support potential uses
within Chrome OS (e.g. zero-copy video decode, camera).
Difference from kernel 3.14 implementation:
- prime_import_sg_table passes dma-buf as argument instead of size
- need to handle import sg_table for both DMA and IOMMU paths
TEST=test_that graphics_Gbm on kevin
BUG=chrome-os-partner:56526
Reviewed-on: https://chromium-review.googlesource.com/381991
Tested-by: Haixia Shi <hshi@chromium.org>
Commit-Queue: Haixia Shi <hshi@chromium.org>
Trybot-Ready: Haixia Shi <hshi@chromium.org>
Reviewed-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_gem.c
Change-Id: I7aae5b0e227de61ac17adf98996152da8db097d2
Signed-off-by: Randy Li <randy.li@rock-chips.com>
The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.
This patch should not introduce any functional changes until the driver
is made to attach subdevices into an IOMMU domain with the generic IOMMU
API, which will happen in following patch. Based heavily on GEM
implementation of Tegra DRM driver.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9196387/)
BUG=chrome-os-partner:53565
TEST=boot to ui on Gru
Reviewed-on: https://chromium-review.googlesource.com/353591
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_drv.h
drivers/gpu/drm/rockchip/rockchip_drm_gem.c
drivers/gpu/drm/rockchip/rockchip_drm_gem.h
Change-Id: I599b2551e8e8000024894426e4e19d7543af3b0a
Signed-off-by: Randy Li <randy.li@rock-chips.com>
This reverts commit b435f1a281.
Conflicts:
drivers/gpu/drm/rockchip/Kconfig
drivers/gpu/drm/rockchip/rockchip_drm_drv.h
Change-Id: I15d2d598514c2878a574219fe2268ee8d530d6e2
Signed-off-by: Randy Li <randy.li@rock-chips.com>
There is not need to force the video driver dependency in parent
tree.
Also there would be too many entries in a menu, I create a submenu
for them.
Change-Id: Id3bd54fa6274b1311ff6b20f95ffeb0d1851d9f9
Signed-off-by: Randy Li <randy.li@rock-chips.com>
We decide to offer the video support in old way.
Change-Id: I0b30f7b2b559596ee124b8558cd54e0ff090ab79
Signed-off-by: Randy Li <randy.li@rock-chips.com>
If you meet a performance issue, I would suggest you to set
500MHZ for ACLK_HEVC at rk3288. It could solve the decoding quite
slow for some video resources.
Change-Id: Iedc2bc90fb13ae89d204dc6b5f5d897acae6812d
Signed-off-by: Randy Li <randy.li@rock-chips.com>
* linux-linaro-lsk-v4.4-android: (61 commits)
Linux 4.4.36
scsi: mpt3sas: Unblock device after controller reset
flow_dissect: call init_default_flow_dissectors() earlier
mei: fix return value on disconnection
mei: me: fix place for kaby point device ids.
mei: me: disable driver on SPT SPS firmware
drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on
mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]
parisc: Also flush data TLB in flush_icache_page_asm
parisc: Fix race in pci-dma.c
parisc: Fix races in parisc_setup_cache_timing()
NFSv4.x: hide array-bounds warning
apparmor: fix change_hat not finding hat after policy replacement
cfg80211: limit scan results cache size
tile: avoid using clocksource_cyc2ns with absolute cycle count
scsi: mpt3sas: Fix secure erase premature termination
Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y
USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad
USB: serial: cp210x: add ID for the Zone DPMX
usb: chipidea: move the lock initialization to core file
...
Stop wasting IOVA space by over-aligning scatterlist segments for a
theoretical worst-case segment boundary mask, and instead take the real
limits into account to merge consecutive segments wherever appropriate,
so our callers can benefit from getting back nicely simplified lists.
This also represents the last piece of functionality wanted by users of
the current arch/arm implementation, thus brings us a small step closer
to converting that over to the common code.
Change-Id: Ie583142efece02dfa6678d5e8607b5bc7266f50c
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 809eac54cd)
when pd power on/off, the qos regs need to save and restore.
Change-Id: Idd6854022fb25538e82238f25a650a687e918a56
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Use standy with dsp_hold intr would effect display timing,
Some display controller can't not allow this, such as edp,
edp panel would flash with it.
Use line flag instead it seems good.
Change-Id: Iecf818c0dbd5a7833e6cec0da60fe3e693b3dc9d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The enable register only masks the raw status bits to signal CPU
interrupt only for enabled interrupts. The status bits are activated
regardless of the enable register. This means that we might have an old
interrupt event queued, which we are not interested in. To avoid getting
a spurious interrupt signalled, we have to clear the old bit before we
update the enable register.
BUG=chrome-os-partner:56378
BUG=chrome-os-partner:56580
TEST=while true; do backlight_dbus_tool --set --percent=0 && sleep 8 && backlight_dbus_tool --set --percent=100 && sleep 3 ; done
Change-Id: I1b8286097f3ba102663ee3a7566fd96492e12d26
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382973
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
VOP have integrated a hardware counter which indicate the exact display
line that vop is scanning. And if we're interested in a specific line,
we can set the line number to vop line_flag register, and then vop would
generate a line_flag interrupt for it.
For example eDP PSR function is interested in the vertical blanking
period, then driver could set the line number to zero.
This patch have exported a symbol that allow other driver to listen the
line flag event with given timeout limit:
- rockchip_drm_wait_line_flag()
BUG=chrome-os-partner:54785
TEST=Success to call rockchip_drm_wait_line_flag()
Change-Id: Id7605bada87c8ead0e549d4ff113ee49d29ad126
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9231675/)
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/349084
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Sean Paul <seanpaul@google.com>
