Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751407AbdGRMIt (ORCPT ); Tue, 18 Jul 2017 08:08:49 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:33522 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751336AbdGRMIr (ORCPT ); Tue, 18 Jul 2017 08:08:47 -0400 Date: Tue, 18 Jul 2017 14:08:39 +0200 From: Daniel Vetter To: Laurent Pinchart Cc: Maxime Ripard , linux-renesas-soc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, dri-devel@lists.freedesktop.org, Seung-Woo Kim , Chen-Yu Tsai , linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Kyungmin Park , Kukjin Kim , Krzysztof Kozlowski , Daniel Vetter , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users Message-ID: <20170718120839.k7zsey67qgrtnfwe@phenom.ffwll.local> Mail-Followup-To: Laurent Pinchart , Maxime Ripard , linux-renesas-soc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, dri-devel@lists.freedesktop.org, Seung-Woo Kim , Chen-Yu Tsai , linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Kyungmin Park , Kukjin Kim , Krzysztof Kozlowski , Daniel Vetter , linux-arm-kernel@lists.infradead.org References: <1823154.LT2zYSFJ4j@avalon> <20170718070522.6uu7s6o3ivpemslf@flea> <10955632.YI7NJnTkKU@avalon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10955632.YI7NJnTkKU@avalon> X-Operating-System: Linux phenom 4.11.0-1-amd64 User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4434 Lines: 92 On Tue, Jul 18, 2017 at 01:14:12PM +0300, Laurent Pinchart wrote: > Hi Maxime, > > On Tuesday 18 Jul 2017 09:05:22 Maxime Ripard wrote: > > On Fri, Jul 14, 2017 at 02:43:12AM +0300, Laurent Pinchart wrote: > > > On Thursday 13 Jul 2017 16:41:13 Maxime Ripard wrote: > > >> The current drm_atomic_helper_commit_tail helper works only if the CRTC > > >> is accessible, and documents an alternative implementation that is > > >> supposed to be used if that happens. > > >> > > >> That implementation is then duplicated by some drivers. Instead of > > >> documenting it, let's implement an helper that all the relevant users > > >> can use directly. > > >> > > >> Signed-off-by: Maxime Ripard > > >> --- > > >> > > >> drivers/gpu/drm/drm_atomic_helper.c | 47 +++++++++++++++-------- > > >> drivers/gpu/drm/exynos/exynos_drm_fb.c | 27 +------------- > > >> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 18 +--------- > > > > > > I've submitted "[PATCH] drm: rcar-du: Setup planes before enabling CRTC to > > > avoid flicker" that changes the rcar-du implementation to the standard > > > disable/update planes/enable order, so I'd appreciate if you could drop > > > the rcar-du part of this patch to avoid conflicts. > > > > I will. > > > > > This being said, the reason why I switched back from the "runtime PM" to > > > the "standard" order is probably of interest to you. Quoting the commit > > > message, > > > > > >> Commit 52055bafa1ff ("drm: rcar-du: Move plane commit code from CRTC > > >> start to CRTC resume") changed the order of the plane commit and CRTC > > >> enable operations to accommodate the runtime PM requirements. However, > > >> this introduced corruption in the first displayed frame, as the CRTC is > > >> now enabled without any plane configured. On Gen2 hardware the first > > >> frame will be black and likely unnoticed, but on Gen3 hardware we end up > > >> starting the display before the VSP compositor, which is more > > >> noticeable. > > >> > > >> To fix this, revert the order of the commit operations back, and handle > > >> runtime PM requirements in the CRTC .atomic_begin() and .atomic_enable() > > >> helper operation handlers. > > > > > > I believe that the "runtime PM" order is problematic in most drivers. The > > > problem usually goes unnoticed as most monitors will not even display the > > > first frame, and I assume many devices will just output it black, but it's > > > an issue nonetheless. > > > > > > Note that my driver hasn't lost the "runtime PM" requirements, so I had to > > > support them with the "standard" order. The best way I've found was to > > > runtime resume in the one of .atomic_begin() and .enable() that is run > > > first. Not very neat, as similar code would be needed in most drivers. I > > > wonder whether it wouldn't be useful to add resume/suspend helper > > > callbacks for the CRTC. > > > > I'm not sure it would apply. Our driver doesn't use runtime_pm at all, > > but in order for the commits to happen, we need to have the CRTC > > active, but it will remain powered up the whole time. I'm not sure if > > we'll ever see such a frame. > > > > But since this seems to be a pretty generic, maybe we should address > > it in the helper itself? > > I think that would make sense. > > There are a few options that result in too many combinations for separate > commit tail helpers to be provided in my opinion: > > - disable/enable/planes vs. disable/planes/enable > - DRM_PLANE_COMMIT_ACTIVE_ONLY vs. all CRTCs > - drm_atomic_helper_wait_for_vblanks vs drm_atomic_helper_wait_for_flip_done > > Maybe we could add a few CRTC commit helper flags along the line of > DRM_PLANE_COMMIT_ACTIVE_ONLY, add a field to the drm_crtc structure to store > them, and have drm_atomic_helper_commit_tail() use those flags to control the > sequence of operations. Why not write your own? Yes it's a bit of copypaste, but imo that's really not horrible. I'm already not happy with the flags for commit_planes because the docs for them are not great and it's hard to know when to use them and when not to. ->commit_tail was specifically done to allow drivers to overwrite the hw commit stage without having to reinvent all the other commit tracking. I expect most non-simple drivers to have their own commit_tail function. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch