Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754797AbbBDD4f (ORCPT ); Tue, 3 Feb 2015 22:56:35 -0500 Received: from regular1.263xmail.com ([211.150.99.138]:60338 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349AbbBDD4e (ORCPT ); Tue, 3 Feb 2015 22:56:34 -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: djkurtz@chromium.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: mark.yao@rock-chips.com X-UNIQUE-TAG: <1144afd3bc913c840dd970b8a21de2b0> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <54D19868.8000906@rock-chips.com> Date: Wed, 04 Feb 2015 11:56:24 +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: Daniel Kurtz CC: "linux-kernel@vger.kernel.org" , dri-devel , Philipp Zabel , David Airlie , Rob Clark , "open list:ARM/Rockchip SoC..." 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> <54CEE131.1020600@rock-chips.com> <20150202075337.GN14009@phenom.ffwll.local> <54D19426.4080105@rock-chips.com> In-Reply-To: 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: 3897 Lines: 105 On 2015年02月04日 11:48, Daniel Kurtz wrote: > On Feb 4, 2015 11:38 AM, "Mark yao" wrote: >> On 2015年02月02日 15:53, Daniel Vetter wrote: >>> On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote: >>>> On 2015年02月02日 10:07, Daniel Kurtz wrote: >>>>> Hi Mark, Heiko, >>>>> >>>>> On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao wrote: >>>>>> 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); >>>>> Re: Heiko "use a WARN_ON": >>>>> >>>>> If the VOP clock is off, then the system will just hang when trying to >>>>> write the VOP register so in this case, BUG_ON gives a more reliable >>>>> crash dump than the hang. >>>> In this way, you are right, if vop clocks is disabled, write vop register >>>> will hang system, and the WARN_ON >>> if (WARN_ON(cond)) >>> return; >>> >>> is what we commonly use in i915. Because it's really not any good to use >>> BUG_ON in drm drivers, at least if you expect anyone to use fbcon on top >>> of it (i.e. anything even remotely resembling a normal distro): Then the >>> intial modeset is all done under console_lock, which means that _none_ of >>> your BUG_ON will ever get out over serial console. >>> >>> The problem is fbcon locking, but no fool yet signed up to fix it (it's >>> horrible, I looked ...). >>> -Daniel >> I know this problem, if fbcon locking, and BUG_ON, we can't get any log from serial console, Trouble >> me many times. So know, if no drm log output, the first thing I do is remove the fbcon lock, and then >> we can see the crash dump. >> >> But here, I expect to use BUG_ON, because if BUG happen, vop register will hang system, and WARN_ON >> may be have no chance to output. > Yeah, but danvet is suggesting we just return immediately on the > WARN_ON condition, to avoid accessing the vop registers and hanging. > > Thus, the WARN_ON will have a chance to put out (unless the early > return path goes off and finds some other unprotected path goes to > access unlocked registers). > > -Dan All right, I got it. >> Mark >> > > -- Ｍark Yao 姚智情 Rockchip 福州瑞芯微电子有限公司 Fuzhou Headquarters Addr:No.21 Building, A District, Fuzhou Software Park, 89 Soft Avenue, Tongpan Road, Gulou District, Fuzhou (350003) 地址:福建省福州市铜盘路软件大道89号软件园A区21号楼 (350003) Tel:（86-0591）83991906 - 8296 E-mail:mark.yao@rock-chips.com -- 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/