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 e77f847df5 ("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)
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)
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)
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)
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 e380538529)
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)
"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)
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>
add more driver config and architecture config
Change-Id: I55900807579a2fdaa8a31baaa3ed087c115f88c3
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
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>
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>
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>
This adds the necessary data for handling efuse on the rk3366.
Change-Id: Ia9b03776172c9a66faa7320f7e1890549538a32a
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
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>
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>
add more devfreq gov to let driver choose it.
Change-Id: Id47b519e1f41311283bf3f38b94cae3b8480aff4
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
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)
