Quickly plug and unplug the Type-C device with DP function test, there
is a low probability of unplugging the Type-C dongle, DP work cannot
acquire the mutex(port->lock), and it will always be stuck in the
tcpm_unregister_altmodes() function during the rest port process, causing
the Type-C device to be inserted again to fail to be detected or the reboot
system to be stuck. The exception process is as follows:
(1) Thread#1: unplug the Type-C device to trigger cc status changes interrupt, in the
tcpm_pd_event_handler() function, first acquire the mutex(port->lock),
then start state_machine work, and finally release the mutex(port->lock);
tcpm_cc_change()
-->tcpm_pd_event_handler()
-->mutex_lock(&port->lock) /* step 1 */
-->_tcpm_cc_change(port, cc1, cc2) /* step 2 */
-->tcpm_set_state(port, SRC_UNATTACHED, 0)
-->kthread_queue_work(port->wq, &port->state_machine) /* step 3 */
--> mutex_unlock(&port->lock) /* step 4 */
(2) Thread#2: before the execution of "step 2" is completed, DP work calls
the callback function registered by the tcpm framework to initiate a VDM
Message, such as Enter Mode Message, in the tcpm_queue_vdm_unlocked()
acquires the mutex(port->lock) fails and goes to sleep;
dp_altmode_work()
--> typec_altmode_enter(dp->alt)
--> tcpm_altmode_enter()
--> tcpm_queue_vdm_unlocked()
--> mutex_lock(&port->lock) /* dp work enter sleep */
(3) After step 4, tcpm_queue_vdm_unlocked() did not acquire for the mutex
(port->lock), but was preempted by the state_machine work to enter the reset
port process. In the reset port process, call the tcpm_unregister_altmodes()
function to release altmode and cancel dp work. Because tcpm_queue_vdm_unlocked()
did not acquire the mutex(port->lock), causing it to be stuck in cancel dp work.
tcpm_state_machine_work()
-->mutex_lock(&port->lock)
-->tcpm_reset_port(port)
-->tcpm_unregister_altmodes(port)
......
--> dp_altmode_remove()
--> cancel_work_sync(&dp->work) /* always stuck in cancel dp work */
......
Therefore, after adding a new mutex to wait for the tcpm_pd_event_handler() function
to complete the processing, if the port is in the disconnect state, there is no need
to acquire the mutex(port->lock) in the tcpm_queue_vdm_unlocked() function.
Change-Id: I364a035568ddc35ef7242b42f6d6d0ee3f5586fd
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
The internal PD of VOP2 on rk3588 take effect immediately
for power up and take effect by vsync for power down.
And the PD_CLUSTER0 is a parent PD of PD_CLUSTER1/2/3,
we may have this use case:
Cluster0 is attached to VP0 for HDMI output,
Cluster1 is attached to VP1 for MIPI DSI,
When we enable Cluster1 on VP1, we should enable PD_CLUSTER0 as
it is the parent PD, event though HDMI is plugout, VP1 is disabled,
the PD of Cluster0 should keep power on.
When system go to suspend:
(1) Power down PD of Cluster1 before VP1 standby(the power down is take
effect by vsync)
(2) Power down PD of Cluster0
But we have problem at step (2), Cluster0 is attached to VP0. bus VP0
is in standby mode, as it is never used or hdmi plugout. So there is
no vsync, the power down will never take effect.
According to IC designer: We must power down all internal PD of VOP
before we power down the global PD_VOP.
So we get this workaround:
We we found a VP is in standby mode when we want power down a PD is
attached to it, we release the VP from standby mode, than it will
run a default timing and generate vsync. Than we can power down the
PD by this vsync. After all this is done, we standby the VP at last.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Change-Id: Ib9be8628f07d783c6bc3b7678c5eebfc63aabe1c
PD_ESMART is shared between Esmart1/2/3, Esmart0 has
no PD
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Change-Id: I5d11ec065f6226e130c93469b1757e4c4fe82067
mainpath is bytes per line for Y_LLENGTH but
selfpath is pixels per line.
Change-Id: I3321f01ee3466bae99e65a6ac10ffbe0acdeed71
Signed-off-by: Cai YiWei <cyw@rock-chips.com>
For ov5695 has been stop production, so replace
ov5695 module config with gc8034
Signed-off-by: Wang Panzhenzhuan <randy.wang@rock-chips.com>
Change-Id: I06aa7d18a82f11a98e6c8bee40a1dd9d5ae60e66
Rockchip platforms supported outband msi routine via GIC ITS.
If msi irq is set, that means we start to support inband msi on
some specific platforms.
For inband msi support, we need SoC to provide msi specified interrupt
and MSI message can be interpreted by PCIe controller to manage MSI
routine.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Change-Id: I5ea019dd2889cd9cfc630d8a618ebd739c984f7d
I don't know why rk_vmap_contig_pfn is not work on ARM32 platform.
May need more debug on this issue. Refactor dma_buf_vmap to use vmap
directly just let things go on.
Change-Id: I9aded08ddb75a6fb8745111a897ab5566d82a71d
Signed-off-by: Simon Xue <xxm@rock-chips.com>
On encoder slice output mode the timing of each slice can be recorded.
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: Iceac5b8488dbfa85068e1460709f278cc2d3ebe4
even multiples of 128 (act w/h) require a scaling factor -1
Signed-off-by: Li Huang <putin.li@rock-chips.com>
Change-Id: I8dc3faeb3863fbf4f285ca8423ac8633fdc36de4
This adds the necessary data for handling otp on the rv1106.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Change-Id: I7a608546148faaeaa5a31506e90825f5295c5b97
Fixes: 37d5c1a6fd ("opp: Add a summary tree in debugfs")
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Change-Id: I70c97957b48abe2417857f8aff5d4175d418b1e6
