From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: jacopo mondi <jacopo@jmondi.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
dri-devel@lists.freedesktop.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH 06/16] drm: rcar-du: Perform the initial CRTC setup from rcar_du_crtc_get()
Date: Sun, 09 Sep 2018 19:44:27 +0300 [thread overview]
Message-ID: <12914706.DMgRscQiTK@avalon> (raw)
In-Reply-To: <20180907181938.GM20333@w540>
Hi Jacopo,
On Friday, 7 September 2018 21:19:38 EEST jacopo mondi wrote:
> On Tue, Sep 04, 2018 at 03:10:17PM +0300, Laurent Pinchart wrote:
> > The rcar_du_crtc_get() function is always immediately followed by a call
> > to rcar_du_crtc_setup(). Call the later from the former to simplify the
> > code, and add a comment to explain how the get and put calls are
> > balanced.
> >
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 107 +++++++++++++++-------------
> > 1 file changed, 56 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 4c9572d7ea89..1d81eb244441
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -66,39 +66,6 @@ static void rcar_du_crtc_clr_set(struct rcar_du_crtc
> > *rcrtc, u32 reg,
> > rcar_du_write(rcdu, rcrtc->mmio_offset + reg, (value & ~clr) | set);
> > }
> >
> > -static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> > -{
> > - int ret;
> > -
> > - ret = clk_prepare_enable(rcrtc->clock);
> > - if (ret < 0)
> > - return ret;
> > -
> > - ret = clk_prepare_enable(rcrtc->extclock);
> > - if (ret < 0)
> > - goto error_clock;
> > -
> > - ret = rcar_du_group_get(rcrtc->group);
> > - if (ret < 0)
> > - goto error_group;
> > -
> > - return 0;
> > -
> > -error_group:
> > - clk_disable_unprepare(rcrtc->extclock);
> > -error_clock:
> > - clk_disable_unprepare(rcrtc->clock);
> > - return ret;
> > -}
> > -
> > -static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
>
> For what I see, rcar_du_crtc_stop() is also called once just before
> _put(). Have you considered doing with them what you've done with
> _get() and _setup() ?
I have, but given that we have an explicit get(); start(); sequence in
rcar_du_crtc_atomic_enable(), I'd rather keep the stop(); put(); sequence in
rcar_du_crtc_atomic_disable().
> > -{
> > - rcar_du_group_put(rcrtc->group);
> > -
> > - clk_disable_unprepare(rcrtc->extclock);
> > - clk_disable_unprepare(rcrtc->clock);
> > -}
> > -
> >
> > /*
> > ------------------------------------------------------------------------
> > ----->
> > * Hardware Setup
> > */
> >
> > @@ -546,6 +513,51 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc
> > *rcrtc)>
> > drm_crtc_vblank_on(&rcrtc->crtc);
> >
> > }
> >
> > +static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> > +{
> > + int ret;
> > +
> > + /*
> > + * Guard against double-get, as the function is called from both the
> > + * .atomic_enable() and .atomic_begin() handlers.
> > + */
> > + if (rcrtc->initialized)
> > + return 0;
> > +
> > + ret = clk_prepare_enable(rcrtc->clock);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = clk_prepare_enable(rcrtc->extclock);
> > + if (ret < 0)
> > + goto error_clock;
> > +
> > + ret = rcar_du_group_get(rcrtc->group);
> > + if (ret < 0)
> > + goto error_group;
> > +
> > + rcar_du_crtc_setup(rcrtc);
> > + rcrtc->initialized = true;
> > +
> > + return 0;
> > +
> > +error_group:
> > + clk_disable_unprepare(rcrtc->extclock);
> > +error_clock:
> > + clk_disable_unprepare(rcrtc->clock);
> > + return ret;
> > +}
> > +
> > +static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
> > +{
> > + rcar_du_group_put(rcrtc->group);
> > +
> > + clk_disable_unprepare(rcrtc->extclock);
> > + clk_disable_unprepare(rcrtc->clock);
> > +
> > + rcrtc->initialized = false;
> > +}
> > +
> >
> > static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
> > {
> >
> > bool interlaced;
> >
> > @@ -639,16 +651,7 @@ static void rcar_du_crtc_atomic_enable(struct
> > drm_crtc *crtc,>
> > {
> >
> > struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> >
> > - /*
> > - * If the CRTC has already been setup by the .atomic_begin() handler we
> > - * can skip the setup stage.
> > - */
> > - if (!rcrtc->initialized) {
> > - rcar_du_crtc_get(rcrtc);
> > - rcar_du_crtc_setup(rcrtc);
> > - rcrtc->initialized = true;
> > - }
> > -
> > + rcar_du_crtc_get(rcrtc);
> >
> > rcar_du_crtc_start(rcrtc);
> >
> > }
> >
> > @@ -667,7 +670,6 @@ static void rcar_du_crtc_atomic_disable(struct
> > drm_crtc *crtc,>
> > }
> > spin_unlock_irq(&crtc->dev->event_lock);
> >
> > - rcrtc->initialized = false;
> >
> > rcrtc->outputs = 0;
> >
> > }
> >
> > @@ -680,14 +682,17 @@ static void rcar_du_crtc_atomic_begin(struct
> > drm_crtc *crtc,>
> > /*
> >
> > * If a mode set is in progress we can be called with the CRTC
disabled.
> >
> > - * We then need to first setup the CRTC in order to configure planes.
> > - * The .atomic_enable() handler will notice and skip the CRTC setup.
> > + * We thus need to first get and setup the CRTC in order to configure
> > + * planes. We must *not* put the CRTC in .atomic_flush(), as it must be
> > + * kept awake until the .atomic_enable() call that will follow. The get
> > + * operation in .atomic_enable() will in that case be a no-op, and the
> > + * CRTC will be put later in .atomic_disable().
> > + *
> > + * If a mode set is not in progress the CRTC is enabled, and the
> > + * following get call will be a no-op. There is thus no need to belance
> > + * it in .atomic_flush() either.
> >
> > */
> >
> > - if (!rcrtc->initialized) {
> > - rcar_du_crtc_get(rcrtc);
> > - rcar_du_crtc_setup(rcrtc);
> > - rcrtc->initialized = true;
> > - }
> > + rcar_du_crtc_get(rcrtc);
> >
> > if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> >
> > rcar_du_vsp_atomic_begin(rcrtc);
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: jacopo mondi <jacopo@jmondi.org>
Cc: linux-renesas-soc@vger.kernel.org,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 06/16] drm: rcar-du: Perform the initial CRTC setup from rcar_du_crtc_get()
Date: Sun, 09 Sep 2018 19:44:27 +0300 [thread overview]
Message-ID: <12914706.DMgRscQiTK@avalon> (raw)
In-Reply-To: <20180907181938.GM20333@w540>
Hi Jacopo,
On Friday, 7 September 2018 21:19:38 EEST jacopo mondi wrote:
> On Tue, Sep 04, 2018 at 03:10:17PM +0300, Laurent Pinchart wrote:
> > The rcar_du_crtc_get() function is always immediately followed by a call
> > to rcar_du_crtc_setup(). Call the later from the former to simplify the
> > code, and add a comment to explain how the get and put calls are
> > balanced.
> >
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 107 +++++++++++++++-------------
> > 1 file changed, 56 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 4c9572d7ea89..1d81eb244441
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -66,39 +66,6 @@ static void rcar_du_crtc_clr_set(struct rcar_du_crtc
> > *rcrtc, u32 reg,
> > rcar_du_write(rcdu, rcrtc->mmio_offset + reg, (value & ~clr) | set);
> > }
> >
> > -static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> > -{
> > - int ret;
> > -
> > - ret = clk_prepare_enable(rcrtc->clock);
> > - if (ret < 0)
> > - return ret;
> > -
> > - ret = clk_prepare_enable(rcrtc->extclock);
> > - if (ret < 0)
> > - goto error_clock;
> > -
> > - ret = rcar_du_group_get(rcrtc->group);
> > - if (ret < 0)
> > - goto error_group;
> > -
> > - return 0;
> > -
> > -error_group:
> > - clk_disable_unprepare(rcrtc->extclock);
> > -error_clock:
> > - clk_disable_unprepare(rcrtc->clock);
> > - return ret;
> > -}
> > -
> > -static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
>
> For what I see, rcar_du_crtc_stop() is also called once just before
> _put(). Have you considered doing with them what you've done with
> _get() and _setup() ?
I have, but given that we have an explicit get(); start(); sequence in
rcar_du_crtc_atomic_enable(), I'd rather keep the stop(); put(); sequence in
rcar_du_crtc_atomic_disable().
> > -{
> > - rcar_du_group_put(rcrtc->group);
> > -
> > - clk_disable_unprepare(rcrtc->extclock);
> > - clk_disable_unprepare(rcrtc->clock);
> > -}
> > -
> >
> > /*
> > ------------------------------------------------------------------------
> > ----->
> > * Hardware Setup
> > */
> >
> > @@ -546,6 +513,51 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc
> > *rcrtc)>
> > drm_crtc_vblank_on(&rcrtc->crtc);
> >
> > }
> >
> > +static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> > +{
> > + int ret;
> > +
> > + /*
> > + * Guard against double-get, as the function is called from both the
> > + * .atomic_enable() and .atomic_begin() handlers.
> > + */
> > + if (rcrtc->initialized)
> > + return 0;
> > +
> > + ret = clk_prepare_enable(rcrtc->clock);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = clk_prepare_enable(rcrtc->extclock);
> > + if (ret < 0)
> > + goto error_clock;
> > +
> > + ret = rcar_du_group_get(rcrtc->group);
> > + if (ret < 0)
> > + goto error_group;
> > +
> > + rcar_du_crtc_setup(rcrtc);
> > + rcrtc->initialized = true;
> > +
> > + return 0;
> > +
> > +error_group:
> > + clk_disable_unprepare(rcrtc->extclock);
> > +error_clock:
> > + clk_disable_unprepare(rcrtc->clock);
> > + return ret;
> > +}
> > +
> > +static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
> > +{
> > + rcar_du_group_put(rcrtc->group);
> > +
> > + clk_disable_unprepare(rcrtc->extclock);
> > + clk_disable_unprepare(rcrtc->clock);
> > +
> > + rcrtc->initialized = false;
> > +}
> > +
> >
> > static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
> > {
> >
> > bool interlaced;
> >
> > @@ -639,16 +651,7 @@ static void rcar_du_crtc_atomic_enable(struct
> > drm_crtc *crtc,>
> > {
> >
> > struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> >
> > - /*
> > - * If the CRTC has already been setup by the .atomic_begin() handler we
> > - * can skip the setup stage.
> > - */
> > - if (!rcrtc->initialized) {
> > - rcar_du_crtc_get(rcrtc);
> > - rcar_du_crtc_setup(rcrtc);
> > - rcrtc->initialized = true;
> > - }
> > -
> > + rcar_du_crtc_get(rcrtc);
> >
> > rcar_du_crtc_start(rcrtc);
> >
> > }
> >
> > @@ -667,7 +670,6 @@ static void rcar_du_crtc_atomic_disable(struct
> > drm_crtc *crtc,>
> > }
> > spin_unlock_irq(&crtc->dev->event_lock);
> >
> > - rcrtc->initialized = false;
> >
> > rcrtc->outputs = 0;
> >
> > }
> >
> > @@ -680,14 +682,17 @@ static void rcar_du_crtc_atomic_begin(struct
> > drm_crtc *crtc,>
> > /*
> >
> > * If a mode set is in progress we can be called with the CRTC
disabled.
> >
> > - * We then need to first setup the CRTC in order to configure planes.
> > - * The .atomic_enable() handler will notice and skip the CRTC setup.
> > + * We thus need to first get and setup the CRTC in order to configure
> > + * planes. We must *not* put the CRTC in .atomic_flush(), as it must be
> > + * kept awake until the .atomic_enable() call that will follow. The get
> > + * operation in .atomic_enable() will in that case be a no-op, and the
> > + * CRTC will be put later in .atomic_disable().
> > + *
> > + * If a mode set is not in progress the CRTC is enabled, and the
> > + * following get call will be a no-op. There is thus no need to belance
> > + * it in .atomic_flush() either.
> >
> > */
> >
> > - if (!rcrtc->initialized) {
> > - rcar_du_crtc_get(rcrtc);
> > - rcar_du_crtc_setup(rcrtc);
> > - rcrtc->initialized = true;
> > - }
> > + rcar_du_crtc_get(rcrtc);
> >
> > if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> >
> > rcar_du_vsp_atomic_begin(rcrtc);
--
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:[~2018-09-09 21:34 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-04 12:10 [PATCH 00/16] R-Car D3/E3 display support (with LVDS PLL) Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 01/16] dt-bindings: display: renesas: du: Document r8a77990 bindings Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-14 7:56 ` jacopo mondi
2018-09-14 7:56 ` jacopo mondi
2018-09-17 5:44 ` Rob Herring
2018-09-04 12:10 ` [PATCH 02/16] dt-bindings: display: renesas: lvds: " Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-14 7:57 ` jacopo mondi
2018-09-14 7:57 ` jacopo mondi
2018-09-17 5:44 ` Rob Herring
2018-09-04 12:10 ` [PATCH 03/16] dt-bindings: display: renesas: lvds: Add EXTAL and DU_DOTCLKIN clocks Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-14 8:00 ` jacopo mondi
2018-09-14 8:00 ` jacopo mondi
2018-09-14 8:24 ` Laurent Pinchart
2018-09-14 8:24 ` Laurent Pinchart
2018-09-14 8:35 ` jacopo mondi
2018-09-14 8:35 ` jacopo mondi
2018-09-04 12:10 ` [PATCH 04/16] drm: bridge: thc63: Restrict modes based on hardware operating frequency Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-11 13:31 ` jacopo mondi
2018-09-11 13:31 ` jacopo mondi
2018-09-13 21:08 ` Laurent Pinchart
2018-09-13 21:08 ` Laurent Pinchart
2018-09-13 12:36 ` Andrzej Hajda
2018-09-13 12:36 ` Andrzej Hajda
2018-09-04 12:10 ` [PATCH 05/16] drm: rcar-du: lvds: D3/E3 support Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 14:29 ` Geert Uytterhoeven
2018-09-04 14:29 ` Geert Uytterhoeven
2018-09-05 14:01 ` Laurent Pinchart
2018-09-05 14:01 ` Laurent Pinchart
2018-09-11 13:23 ` jacopo mondi
2018-09-11 13:23 ` jacopo mondi
2018-09-13 21:14 ` Laurent Pinchart
2018-09-13 21:14 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 06/16] drm: rcar-du: Perform the initial CRTC setup from rcar_du_crtc_get() Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-07 18:19 ` jacopo mondi
2018-09-07 18:19 ` jacopo mondi
2018-09-09 16:44 ` Laurent Pinchart [this message]
2018-09-09 16:44 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 07/16] drm: rcar-du: Use LVDS PLL clock as dot clock when possible Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-11 14:59 ` jacopo mondi
2018-09-11 14:59 ` jacopo mondi
2018-09-13 21:17 ` Laurent Pinchart
2018-09-13 21:17 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 08/16] drm: rcar-du: Enable configurable DPAD0 routing on Gen3 Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-11 15:46 ` jacopo mondi
2018-09-11 15:46 ` jacopo mondi
2018-09-13 21:25 ` Laurent Pinchart
2018-09-13 21:25 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 09/16] drm: rcar-du: Cache DSYSR value to ensure known initial value Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 10/16] drm: rcar-du: Don't use TV sync mode when not supported by the hardware Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 11/16] drm: rcar-du: Add r8a77990 and r8a77995 device support Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 12/16] arm64: dts: renesas: r8a77990: Add I2C device nodes Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 14:32 ` Geert Uytterhoeven
2018-09-04 14:32 ` Geert Uytterhoeven
2018-09-04 14:49 ` jacopo mondi
2018-09-04 14:49 ` jacopo mondi
2018-09-05 13:53 ` Laurent Pinchart
2018-09-05 13:53 ` Laurent Pinchart
2018-09-06 9:26 ` Simon Horman
2018-09-06 9:26 ` Simon Horman
2018-09-06 9:48 ` Laurent Pinchart
2018-09-06 9:48 ` Laurent Pinchart
2018-09-05 13:52 ` Laurent Pinchart
2018-09-05 13:52 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 13/16] arm64: dts: renesas: r8a77990: Add display output support Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 14/16] arm64: dts: renesas: r8a77995: Add LVDS support Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 15/16] arm64: dts: renesas: r8a77990: ebisu: Enable VGA and HDMI outputs Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-04 12:10 ` [PATCH 16/16] arm64: dts: renesas: r8a77995: draak: Enable HDMI display output Laurent Pinchart
2018-09-04 12:10 ` Laurent Pinchart
2018-09-05 16:22 ` [PATCH 00/16] R-Car D3/E3 display support (with LVDS PLL) jacopo mondi
2018-09-05 16:22 ` jacopo mondi
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=12914706.DMgRscQiTK@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacopo@jmondi.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-renesas-soc@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.