Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756116AbcCUOzu (ORCPT ); Mon, 21 Mar 2016 10:55:50 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:36305 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755468AbcCUOzr convert rfc822-to-8bit (ORCPT ); Mon, 21 Mar 2016 10:55:47 -0400 MIME-Version: 1.0 In-Reply-To: <56ECA841.40803@rock-chips.com> References: <1458300147-6472-1-git-send-email-tomeu.vizoso@collabora.com> <56ECA841.40803@rock-chips.com> From: Tomeu Vizoso Date: Mon, 21 Mar 2016 15:55:26 +0100 X-Google-Sender-Auth: Pj5OuuVuX9H6Gwbo-q4qofXyHkw Message-ID: Subject: Re: [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling To: Mark yao Cc: "linux-kernel@vger.kernel.org" , "open list:ARM/Rockchip SoC..." , "dri-devel@lists.freedesktop.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3508 Lines: 99 On 19 March 2016 at 02:15, Mark yao wrote: > On 2016年03月18日 19:22, Tomeu Vizoso wrote: >> >> When the VOP is re-enabled, it will start scanning right away the >> framebuffers that were configured from the last time, even if those have >> been destroyed already. To prevent the VOP from trying to access freed >> memory, reset the registers that hold pointers to framebuffers right >> after we can write to them, but before the VOP is awaken from standby. >> >> Signed-off-by: Tomeu Vizoso >> Link: >> http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw@mail.gmail.com >> --- >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >> index 5e57f5b2e4b0..0df91c28740b 100644 >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >> @@ -429,6 +429,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop >> *vop) >> static void vop_enable(struct drm_crtc *crtc) >> { >> struct vop *vop = to_vop(crtc); >> + int i; >> int ret; >> if (vop->is_enabled) >> @@ -476,6 +477,18 @@ static void vop_enable(struct drm_crtc *crtc) >> */ >> vop->is_enabled = true; >> + /* >> + * Before turning the VOP completely on, unset the registers >> + * containing FB addresses to avoid the HW start scanning old FBs. >> + */ >> + for (i = 0; i < vop->data->win_size; i++) { >> + struct vop_win *vop_win = &vop->win[i]; >> + const struct vop_win_data *win = vop_win->data; >> + >> + VOP_WIN_SET(vop, win, yrgb_mst, 0x0); >> + VOP_WIN_SET(vop, win, uv_mst, 0x0); >> + } >> + > > Hi Tomeu > > Thanks for your fix. > > Set yrgb_mst and uv_mst is not a good idea, because 0x0 also is a memory > buffer address, ddr will access the 0x0 buffer. > I think you may enable DRM_FBDEV_EMULATION, the 0x0 address is iommu mmaped > address for fbdev, so your test can works. > but if DRM_FBDEV_EMULATION is not define, may be 0x0 address is unmmaped, > would get the iommu crash. I have checked with DRM_FBDEV_EMULATION disabled and seems to work equally well. > I think we can use atomic disable function like this: > for_each_plane_in_state(old_state, plane, old_plane_state, i) { > const struct drm_plane_helper_funcs *funcs; > funcs = plane->helper_private; > funcs->atomic_disable(plane, old_plane_state); > } > > But I think we'd better find why we need do this hack here. > > Does the old FB address is ummaped when crtc disabling? why plane is not > disabled? Planes aren't being disabled because the CRTC is being disabled already, see http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_atomic_helper.c#L1306 Exynos is already disabling all planes when a crtc is disabled: http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_fimd.c#L782 I don't like it because there's state in the drm core and in the drivers that is left inconsistent. Regards, Tomeu > Thanks. > >> spin_lock(&vop->reg_lock); >> VOP_CTRL_SET(vop, standby, 0); > > > > -- > Ｍark Yao > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel