Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753027AbbBBApS (ORCPT ); Sun, 1 Feb 2015 19:45:18 -0500 Received: from regular1.263xmail.com ([211.150.99.138]:39833 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751805AbbBBApL (ORCPT ); Sun, 1 Feb 2015 19:45:11 -0500 X-263anti-spam: KSV:0;BIG:0;ABS:1;DNS:0;ATT:0;SPF:S; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 1 X-SKE-CHECKED: 1 X-ADDR-CHECKED: 0 X-RL-SENDER: mark.yao@rock-chips.com X-FST-TO: heiko@sntech.de X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: mark.yao@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <54CEC890.8040701@rock-chips.com> Date: Mon, 02 Feb 2015 08:45:04 +0800 From: Mark yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?SGVpa28gU3TDvGJuZXI=?= , dri-devel@lists.freedesktop.org CC: David Airlie , Daniel Vetter , Rob Clark , Philipp Zabel , Daniel Kurtz , linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org Subject: Re: [PATCH] drm/rockchip: vop: power off until vop standby take effect References: <1422693698-21944-1-git-send-email-mark.yao@rock-chips.com> <26349423.KqVQYq280G@diego> In-Reply-To: <26349423.KqVQYq280G@diego> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2751 Lines: 94 On 2015年01月31日 20:49, Heiko Stübner wrote: > Hi Mark, > > Am Samstag, 31. Januar 2015, 16:41:38 schrieb Mark Yao: >> Vop standby will take effect end of current frame, >> 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 >> --- >> 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); > BUG_ON is generally not well liked in general error handling - i.e. in the > !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. Right, got it. > >> + >> + 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); > 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(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 > > [but take it with a grain of salt, as I'm still new to drm-land :-) ] Good, I saw your drm patches, I'm interested in those, very good. Mark > > Heiko > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/