From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754127AbaILJ1v (ORCPT ); Fri, 12 Sep 2014 05:27:51 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:29439 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754088AbaILJ1r (ORCPT ); Fri, 12 Sep 2014 05:27:47 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfec7f4-b7f156d0000063c7-87-5412bc90be6c Content-transfer-encoding: 8BIT Message-id: <5412BC8D.2030007@samsung.com> Date: Fri, 12 Sep 2014 11:27:41 +0200 From: Andrzej Hajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 To: Inki Dae , "moderated list:ARM/S5P EXYNOS AR..." , Seung-Woo Kim , open list , dri-devel@lists.freedesktop.org, Kyungmin Park , Marek Szyprowski Subject: Re: [PATCH 5/9] drm/exynos/crtc: fix framebuffer reference sequence References: <1410268573-2297-1-git-send-email-a.hajda@samsung.com> <1410268573-2297-6-git-send-email-a.hajda@samsung.com> <5412B02A.6040609@samsung.com> <20140912085710.GD4740@phenom.ffwll.local> In-reply-to: <20140912085710.GD4740@phenom.ffwll.local> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsVy+t/xa7oT9giFGJw8om1x5et7NotJ9yew WJxtesNucXnXHDaLGef3MVmsPXKX3WLG5JdsDuwe97uPM3n0bVnF6PF5k1wAcxSXTUpqTmZZ apG+XQJXxq8v1xgL+tQqpn8MbmCcqNDFyMkhIWAiMbF7DROELSZx4d56ti5GLg4hgaWMEut3 NLKCJHgFBCV+TL7H0sXIwcEsIC9x5FI2hKkuMWVKLkT5J0aJuV0TWCDKtSQWnj7CCGKzCKhK fP67B8xmE9CU+Lv5JhuILSoQJvHs10EmkGYRgcNMErevHWIHSQgL+EgcuLqTHWLqcUaJ5vut rCDbOAXMJW6tj5nAyD8LyUmzEE6ahXDSAkbmVYyiqaXJBcVJ6bmGesWJucWleel6yfm5mxgh IftlB+PiY1aHGAU4GJV4eDnOCYYIsSaWFVfmHmKU4GBWEuH9uU0oRIg3JbGyKrUoP76oNCe1 +BAjEwenVAOjsHTHPdcT57ljDhyKXRmZICs5Teft7+/8d6eXyfFzaV7Wnmi7W+v4XCdhE0ZX H72v7ZcUHeqymje5rn7VVDRfZUXAw2Nyt1R5Mk40yp6W4Uu+Mvnb2skajnPq1Q5pienv+eRx 9gBjjXSRwc6+5vTtytnH2sRcrmgvefFSRNPh38Mms5M8wneVWIozEg21mIuKEwEcKKLsNwIA AA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/12/2014 10:57 AM, Daniel Vetter wrote: > On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote: >> Hi Andrzej, >> >> On 2014년 09월 09일 22:16, Andrzej Hajda wrote: >>> Adding reference to framebuffer should be accompanied with removing >>> reference to old framebuffer assigned to the plane. >>> This patch removes following warning: >>> >>> [ 95.038017] WARNING: CPU: 1 PID: 3067 at drivers/gpu/drm/drm_crtc.c:5115 drm_mode_config_cleanup+0x258/0x268() >>> [ 95.048086] Modules linked in: >>> [ 95.051430] CPU: 1 PID: 3067 Comm: bash Tainted: G W 3.16.0-11355-g7a6eca5-dirty #3015 >>> [ 95.060058] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) >>> [ 95.067766] [] (show_stack) from [] (dump_stack+0x70/0xbc) >>> [ 95.074953] [] (dump_stack) from [] (warn_slowpath_common+0x64/0x88) >>> [ 95.083005] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) >>> [ 95.091780] [] (warn_slowpath_null) from [] (drm_mode_config_cleanup+0x258/0x268) >>> [ 95.100983] [] (drm_mode_config_cleanup) from [] (exynos_drm_unload+0x38/0x50) >>> [ 95.109915] [] (exynos_drm_unload) from [] (drm_dev_unregister+0x24/0x98) >>> [ 95.118414] [] (drm_dev_unregister) from [] (drm_put_dev+0x28/0x64) >>> [ 95.126412] [] (drm_put_dev) from [] (take_down_master+0x24/0x44) >>> [ 95.134218] [] (take_down_master) from [] (component_del+0x8c/0xc8) >>> [ 95.142201] [] (component_del) from [] (exynos_dsi_remove+0x18/0x2c) >>> [ 95.150294] [] (exynos_dsi_remove) from [] (platform_drv_remove+0x18/0x1c) >>> [ 95.158872] [] (platform_drv_remove) from [] (__device_release_driver+0x70/0xc4) >>> [ 95.167981] [] (__device_release_driver) from [] (device_release_driver+0x20/0x2c) >>> [ 95.177268] [] (device_release_driver) from [] (unbind_store+0x5c/0x94) >>> [ 95.185597] [] (unbind_store) from [] (drv_attr_store+0x20/0x2c) >>> [ 95.193323] [] (drv_attr_store) from [] (sysfs_kf_write+0x4c/0x50) >>> [ 95.201224] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xc4/0x184) >>> [ 95.209393] [] (kernfs_fop_write) from [] (vfs_write+0xa0/0x1a8) >>> [ 95.217111] [] (vfs_write) from [] (SyS_write+0x40/0x8c) >>> [ 95.224146] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x48) >>> >>> Signed-off-by: Andrzej Hajda >>> --- >>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> index b68e58f..bde19f4 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> @@ -145,10 +145,16 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode, >>> if (ret) >>> return ret; >>> >>> + /* we need to unreference current fb after replacing it with new one */ >>> + old_fb = plane->fb; >>> + >>> plane->crtc = crtc; >>> plane->fb = crtc->primary->fb; >>> drm_framebuffer_reference(plane->fb); >>> >>> + if (old_fb) >>> + drm_framebuffer_unreference(old_fb); >> This time would be a good chance that we can consider drm flip queue to >> make sure that whole memory region to old_fb is scanned out completely >> before dropping a reference of old_fb. the reference of old_fb should be >> dropped at irq handler of each crtc devices, fimd and mixer. > Generally it's not a good idea to drop fb references from irq context, > since if you actually drop the last reference it'll blow up: fb cleanup > needs a bunch of mutexes. I agree with that. > > Also the drm core really should be taking care of this for you, you only > need to grab references yourself for async flips if you want the buffer to > survive a bit. crtc_mode_set has not need for this. I expect that the > refcounting bug is somewhere else, at least from my experience chasing > such issues in i915 ;-) Hmm, maybe I miss something but I do not see the core grabbing fb reference on plane->fb update. On the other side drm_framebuffer_remove calls drm_plane_force_disable which drops plane->fb reference. I am not yet familiar with this code so maybe there is better solution. If not I guess it would be better to move this code to exynos_plane_mode_set. At least it is done this way in omap and msm, in fact it seems better place for such things. What do you think? Regards Andrzej > -Daniel