shinys000114/linux
1
0
Fork 0
mirror of https://github.com/hardkernel/linux.git synced 2026-06-06 02:50:49 +09:00
Code Issues Packages Projects Releases Wiki Activity

drm/rockchip: vop2: Fix incorrect ref_count for rk3576 cluster_pd

Browse Source 
1. The 4 ESMART win share one PD_ESMART and 2 CLUSTER win share one
   PD_CLUSTER
2. The 4 ESMART win and 2 CLUSTER win maybe used by different VP
3. Different VP have different vsync, this maybe lead to PD up and
   down at unexpected time.

Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: Iaa3d72df880180a9d73476551f31b7adaa76e967
This commit is contained in:
Sandy Huang
2025-02-14 17:33:48 +08:00
committed by Tao Huang
parent d3bff0d9f8
commit 3fe3f9cdbd
1 changed files with 28 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
View File

@@ -2071,6 +2071,32 @@ static void vop2_power_domain_off_work(struct work_struct *work)
spin_unlock(&pd->lock);
}
/*
* Don't dynamic turn on/off PD_ESMART at RK3588.
* (1) There is a design issue for PD_EMSART when attached
* on VP1/2/3, we found it will trigger POST_BUF_EMPTY irq at vp0
* in splice mode.
* (2) PD_ESMART will be closed at esmart layers attathed on VPs
* config done + FS, but different VP FS time is different, this
* maybe lead to PD_ESMART closed at wrong time and display error.
* (3) PD_ESMART power up maybe have 4 us delay, this will lead to POST_BUF_EMPTY.
*
* Don't dynamic turn on/off RK3576 PD_ESMART and PD_CLUSTER.
* (1) The 4 ESMART win share one PD_ESMART and 2 CLUSTER win share one PD_CLUSTER
* (2) The 4 ESMART win and 2 CLUSTER win maybe used by different VP
* (3) But different VP FS time is different, this maybe lead to PD up and down at
unexpected time.
*/
static bool vop2_ignore_dynamic_control_sub_pd(struct vop2 *vop2, struct vop2_power_domain *pd)
{
if (vop2->version == VOP_VERSION_RK3588 && pd->data->id == VOP2_PD_ESMART)
return true;
else if (vop2->version == VOP_VERSION_RK3576)
return true;
else
return false;
}
static void vop2_win_enable(struct vop2_win *win)
{
/*
@@ -2090,8 +2116,7 @@ static void vop2_win_enable(struct vop2_win *win)
*/
if (!VOP_WIN_GET_REG_BAK(win->vop2, win, enable)) {
if (win->pd) {
if ((win->pd->data->id == VOP2_PD_ESMART && win->vop2->version == VOP_VERSION_RK3588) ||
win->vop2->version == VOP_VERSION_RK3576)
if (vop2_ignore_dynamic_control_sub_pd(win->vop2, win->pd))
return;
vop2_power_domain_get(win->pd);
@@ -2167,18 +2192,7 @@ static void vop2_win_disable(struct vop2_win *win, bool skip_splice_win)
VOP_CLUSTER_SET(vop2, win, dci_en, 0);
if (win->pd) {
/*
* Don't dynamic turn on/off PD_ESMART at RK3588/RK3576.
* (1) There is a design issue for PD_EMSART when attached
* on VP1/2/3, we found it will trigger POST_BUF_EMPTY irq at vp0
* in splice mode.
* (2) PD_ESMART will be closed at esmart layers attathed on VPs
* config done + FS, but different VP FS time is different, this
* maybe lead to PD_ESMART closed at wrong time and display error.
* (3) PD_ESMART power up maybe have 4 us delay, this will lead to POST_BUF_EMPTY.
*/
if (win->pd->data->id != VOP2_PD_ESMART) {
if (!vop2_ignore_dynamic_control_sub_pd(vop2, win->pd)) {
vop2_power_domain_put(win->pd);
win->pd->vp_mask &= ~win->vp_mask;
}