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>
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>
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>
Refer to the commit 85fbd722ad ("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>
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>
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>
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>
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>
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>
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)
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)
This patch documents the Rockchip pvtm device tree binding.
Change-Id: I7edcd1d57ff2852eb6e6897680566abb7f9e76a9
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
These clks will be enabed and disabled in pvtm driver.
Change-Id: I742a8c4ef5877486fb21c014f1e4ab27f72e468d
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
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>
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>
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>
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 06ad4b2fad)
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>
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: a787870924 ("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 2e636d5e66)
df9e01a6c5 ("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>
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 0ff21646f2)
Signed-off-by: Cliff Chen <cliff.chen@rock-chips.com>
This reverts commit cb3e42dc8c.
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>
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 4a3a3d32c7)
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 e4c8cd82d5)
