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 <mark.yao at rock-chips.com> 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 <mark.yao at rock-chips.com> >>>> --- >>>> 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. Mark