Hi Mark,Right, got it.
Am Samstag, 31. Januar 2015, 16:41:38 schrieb Mark Yao:
Vop standby will take effect end of current frame,BUG_ON is generally not well liked in general error handling - i.e. in the
if dsp_hold_valid_irq happen, it means vop standby complete.
we must wait standby complete when we want to disable aclk,
if not, memory bus maybe dead.
Signed-off-by: Mark Yao <mark.yao@xxxxxxxxxxxxxx>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 76
++++++++++++++++++++++----- 1 file changed, 63 insertions(+), 13
deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index fb25836..47ea61f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -89,6 +89,7 @@ struct vop {
/* mutex vsync_ work */
struct mutex vsync_mutex;
bool vsync_work_pending;
+ struct completion dsp_hold_completion;
const struct vop_data *data;
@@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format)
}
}
+static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
+{
+ unsigned long flags;
+
+ BUG_ON(!vop->is_enabled);
!vop->is_enabled
bad things may happen, but this may not always be the case. And BUG_ON
effectively kills the machine.
You could simply use a WARN_ON, so people see that something really strange is
going on but can still try to recover things.
Good, I saw your drm patches, I'm interested in those, very good.
+same here
+ spin_lock_irqsave(&vop->irq_lock, flags);
+
+ vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
+ DSP_HOLD_VALID_INTR_EN(1));
+
+ spin_unlock_irqrestore(&vop->irq_lock, flags);
+}
+
+static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
+{
+ unsigned long flags;
+
+ BUG_ON(!vop->is_enabled);
+
+ spin_lock_irqsave(&vop->irq_lock, flags);
+
+ vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
+ DSP_HOLD_VALID_INTR_EN(0));
+
+ spin_unlock_irqrestore(&vop->irq_lock, flags);
+}
+
static void vop_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
except the above
Reviewed-by: Heiko Stuebner <heiko@xxxxxxxxx>
[but take it with a grain of salt, as I'm still new to drm-land :-) ]
Heiko