From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>,
kieran.bingham+renesas@ideasonboard.com, geert@linux-m68k.org,
horms@verge.net.au, uli+renesas@fpond.eu,
VenkataRajesh.Kalakodima@in.bosch.com, airlied@linux.ie,
daniel@ffwll.ch, muroya@ksk.co.jp, koji.matsuoka.xm@renesas.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
Harsha.ManjulaMallikarjun@in.bosch.com,
Doug Anderson <dianders@google.com>,
Heiko Stuebner <heiko@sntech.de>
Subject: Re: [PATCH v4 8/9] drm: rcar-du: kms: Update CMM in atomic commit tail
Date: Tue, 1 Oct 2019 22:20:15 +0300 [thread overview]
Message-ID: <20191001192015.GB21064@pendragon.ideasonboard.com> (raw)
In-Reply-To: <8063b9555d5bce6f2c002e49da3b7afaca9ae0b4.camel@collabora.com>
Hi Ezequiel,
On Mon, Sep 30, 2019 at 05:53:00PM -0300, Ezequiel Garcia wrote:
> +Doug, Heiko:
>
> On Fri, 2019-09-06 at 15:54 +0200, Jacopo Mondi wrote:
> > Update CMM settings at in the atomic commit tail helper method.
> > The CMM is updated with new gamma values provided to the driver
> > in the GAMMA_LUT blob property.
> >
> > When resuming from system suspend, the DU driver is responsible for
> > reprogramming and enabling the CMM unit if it was in use at the time the
> > system entered the suspend state. Force the color_mgmt_changed flag to
> > true if the DRM gamma lut color transformation property was set in the
> > CRTC state duplicated at suspend time, as the CMM gets reprogrammed only
> > if said flag is active in the rcar_du_atomic_commit_update_cmm() method.
> >
> > Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> >
> > Daniel could you have a look if resume bits are worth being moved to the
> > DRM core? The color_mgmt_changed flag is set to false when the state is
> > duplicated if I read the code correctly, but when this happens in a
> > suspend/resume sequence its value should probably be restored to true if
> > any color management property was set in the crtc state when system entered
> > suspend.
>
> Perhaps we can use the for_each_new_crtc_in_state() helper here,
> and move it to the core like this:
>
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3234,8 +3234,20 @@ int drm_atomic_helper_resume(struct
> drm_device *dev,
> struct drm_atomic_state *state)
> {
> struct drm_modeset_acquire_ctx ctx;
> + struct drm_crtc_state
> *crtc_state;
> + struct drm_crtc *crtc;
> + unsigned int i;
> int err;
>
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> +
> /*
> + * Force re-enablement of CMM after system resume if any
> + * of the DRM color transformation properties
> was set in
> + * the state saved at system suspend time.
> + */
> + if (crtc_state->gamma_lut)
> +
> crtc_state->color_mgmt_changed = true;
> + }
>
> This probably is wrong, and should be instead constrained to some
> condition of some sort.
>
> FWIW, the Rockchip DRM is going to need this as well.
>
> Any ideas?
That's more or less what I had in mind, yes. The question is if
something like this would make sense. If there's a consensus it would, I
think it can be done as part of this series.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2019-10-01 19:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 13:54 [PATCH v4 0/9 drm: rcar-du: Add Color Management Module (CMM) Jacopo Mondi
2019-09-06 13:54 ` [PATCH v4 1/9] dt-bindings: display: renesas,cmm: Add R-Car CMM documentation Jacopo Mondi
2019-09-11 19:04 ` Kieran Bingham
2019-09-17 17:55 ` Rob Herring
2019-09-18 22:08 ` Laurent Pinchart
2019-09-06 13:54 ` [PATCH v4 2/9] dt-bindings: display, renesas,du: Document cmms property Jacopo Mondi
2019-09-11 16:06 ` Kieran Bingham
2019-09-17 17:58 ` Rob Herring
2019-09-06 13:54 ` [PATCH v4 3/9] drm: rcar-du: Add support for CMM Jacopo Mondi
2019-09-11 15:54 ` Kieran Bingham
2019-09-12 7:59 ` Jacopo Mondi
2019-09-12 9:49 ` Kieran Bingham
2019-09-18 22:55 ` Laurent Pinchart
2019-09-19 8:59 ` Kieran Bingham
2019-09-20 22:43 ` Laurent Pinchart
2019-10-10 17:46 ` Jacopo Mondi
2019-10-14 23:54 ` Laurent Pinchart
2019-09-06 13:54 ` [PATCH v4 4/9] drm: rcar-du: Claim CMM support for Gen3 SoCs Jacopo Mondi
2019-09-11 18:45 ` Kieran Bingham
2019-09-06 13:54 ` [PATCH v4 5/9] drm: rcar-du: kms: Initialize CMM instances Jacopo Mondi
2019-09-12 9:27 ` Kieran Bingham
2019-09-06 13:54 ` [PATCH v4 6/9] drm: rcar-du: crtc: Enable and disable CMMs Jacopo Mondi
2019-09-11 18:40 ` Kieran Bingham
2019-09-12 8:07 ` Jacopo Mondi
2019-09-12 9:19 ` Kieran Bingham
2019-09-18 23:23 ` Laurent Pinchart
2019-09-19 8:08 ` Kieran Bingham
2019-09-20 22:44 ` Laurent Pinchart
2019-09-06 13:54 ` [PATCH v4 7/9] drm: rcar-du: crtc: Register GAMMA_LUT properties Jacopo Mondi
2019-09-11 18:47 ` Kieran Bingham
2019-09-06 13:54 ` [PATCH v4 8/9] drm: rcar-du: kms: Update CMM in atomic commit tail Jacopo Mondi
2019-09-12 9:51 ` Kieran Bingham
2019-09-20 22:49 ` Laurent Pinchart
2019-09-30 20:53 ` Ezequiel Garcia
2019-10-01 19:20 ` Laurent Pinchart [this message]
2019-09-06 13:54 ` [PATCH v4 9/9] arm64: dts: renesas: Add CMM units to Gen3 SoCs Jacopo Mondi
2019-09-11 18:16 ` Kieran Bingham
2019-09-11 19:35 ` Geert Uytterhoeven
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=20191001192015.GB21064@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=Harsha.ManjulaMallikarjun@in.bosch.com \
--cc=VenkataRajesh.Kalakodima@in.bosch.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dianders@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ezequiel@collabora.com \
--cc=geert@linux-m68k.org \
--cc=heiko@sntech.de \
--cc=horms@verge.net.au \
--cc=jacopo+renesas@jmondi.org \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=koji.matsuoka.xm@renesas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=muroya@ksk.co.jp \
--cc=uli+renesas@fpond.eu \
/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).