From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: linux-renesas-soc@vger.kernel.org,
linux-samsung-soc@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Seung-Woo Kim <sw0312.kim@samsung.com>,
Chen-Yu Tsai <wens@csie.org>,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
Kyungmin Park <kyungmin.park@samsung.com>,
Kukjin Kim <kgene@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Daniel Vetter <daniel.vetter@intel.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
Date: Fri, 14 Jul 2017 02:43:12 +0300 [thread overview]
Message-ID: <1823154.LT2zYSFJ4j@avalon> (raw)
In-Reply-To: <aeeb8f778dae8f170294b6da92819973b742feb2.1499956639.git-series.maxime.ripard@free-electrons.com>
Hi Maxime,
Thank you for the patch.
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 <maxime.ripard@free-electrons.com>
> ---
> 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.
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.
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 21 +----------
> include/drm/drm_atomic_helper.h | 1 +-
> 5 files changed, 36 insertions(+), 78 deletions(-)
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-07-13 23:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-13 14:41 [PATCH 0/4] drm/sun4i: Fix a register access bug Maxime Ripard
2017-07-13 14:41 ` [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users Maxime Ripard
2017-07-13 19:39 ` Daniel Vetter
2017-07-13 23:43 ` Laurent Pinchart [this message]
2017-07-14 5:37 ` Daniel Vetter
2017-07-18 7:05 ` Maxime Ripard
2017-07-18 10:14 ` Laurent Pinchart
2017-07-18 12:08 ` Daniel Vetter
2017-07-18 12:47 ` Laurent Pinchart
2017-07-18 13:04 ` Daniel Vetter
2017-07-13 14:41 ` [PATCH 2/4] drm/sun4i: Use the runtime_pm commit_tail variant Maxime Ripard
2017-07-13 14:41 ` [PATCH 3/4] drm/sun4i: engine: Add commit_poll function Maxime Ripard
2017-07-13 14:41 ` [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending Maxime Ripard
2017-07-14 8:56 ` Chen-Yu Tsai
2017-07-17 6:55 ` Maxime Ripard
2017-07-17 6:57 ` Chen-Yu Tsai
2017-07-18 7:07 ` Maxime Ripard
2017-07-18 7:35 ` Daniel Vetter
2017-07-20 9:53 ` Maxime Ripard
2017-07-20 10:39 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1823154.LT2zYSFJ4j@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=sw0312.kim@samsung.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).