linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: Leonard Crestez <leonard.crestez@nxp.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
	Marek Vasut <marex@denx.de>, Shawn Guo <shawnguo@kernel.org>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Robert Chiras <robert.chiras@nxp.com>,
	Mirela Rabulea <mirela.rabulea@nxp.com>,
	Anson Huang <Anson.Huang@nxp.com>,
	dri-devel@lists.freedesktop.org,
	Dong Aisheng <aisheng.dong@nxp.com>,
	linux-imx@nxp.com, kernel@pengutronix.de,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/4] drm/mxsfb: Fix initial corrupt frame when activating display
Date: Tue, 07 Aug 2018 20:29:43 +0200	[thread overview]
Message-ID: <e3f8a2e1a7947a3745a699ce5a3450dc@agner.ch> (raw)
In-Reply-To: <a1551bbbb018ebe9526f7367aef536ae26bdc256.1533583611.git.leonard.crestez@nxp.com>

On 06.08.2018 21:31, Leonard Crestez wrote:
> LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
> NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
> display will show an initial corrupt frame.
> 
> Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
> activating the CRTC.

Really like how this patch set evolves! Only some minor thing below...

> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 +++++++++++++++++++++---------
>  1 file changed, 29 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 0abe77675b76..db3ff5bde122 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -194,15 +194,31 @@ static int mxsfb_reset_block(void __iomem *reset_addr)
>  		return ret;
>  
>  	return clear_poll_bit(reset_addr, MODULE_CLKGATE);
>  }
>  
> +static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
> +{
> +	struct drm_framebuffer *fb = mxsfb->pipe.plane.state->fb;
> +	struct drm_gem_cma_object *gem;
> +
> +	if (!fb)
> +		return 0;
> +
> +	gem = drm_fb_cma_get_gem_obj(fb, 0);
> +	if (!gem)
> +		return 0;
> +
> +	return gem->paddr;
> +}
> +
>  static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
>  {
>  	struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
>  	const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
>  	u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
> +	dma_addr_t paddr;
>  	int err;
>  
>  	/*
>  	 * It seems, you can't re-program the controller if it is still
>  	 * running. This may lead to shifted pictures (FIFO issue?), so
> @@ -268,10 +284,16 @@ static void mxsfb_crtc_mode_set_nofb(struct
> mxsfb_drm_private *mxsfb)
>  	       mxsfb->base + LCDC_VDCTRL3);
>  
>  	writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
>  	       mxsfb->base + LCDC_VDCTRL4);
>  
> +	/* Update cur_buf as well to avoid an initial corrupt frame */
> +	paddr = mxsfb_get_fb_paddr(mxsfb);
> +	if (paddr) {
> +		writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
> +		writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
> +	}

Traditionally mxsfb_crtc_mode_set_nofb() was used as a callback to
mode_set_nofb. And that callback should not fiddle with the fb (as the
name says).

So I rather prefer to move the new bits to mxsfb_crtc_enable(), between
mxsfb_crtc_mode_set_nofb() and mxsfb_enable_controller(). It is only
cosmetics, but I'd rather prefer to have it in the right place.

Currently the AXI clock is disabled between those functions... I suggest
to enable the AXI clock once in mxsfb_crtc_enable(). This puts an end to
the unnecessary enable/disable/enable sequence in mxsfb_crtc_enable().

So I suggest to create a patch "drm/mxsfb: simplify AXI clock handling"

--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -129,7 +129,6 @@ static void mxsfb_enable_controller(struct
mxsfb_drm_private *mxsfb)
        if (mxsfb->clk_disp_axi)
                clk_prepare_enable(mxsfb->clk_disp_axi);
        clk_prepare_enable(mxsfb->clk);
-       mxsfb_enable_axi_clk(mxsfb);
 
        /* If it was disabled, re-enable the mode again */
        writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
@@ -159,8 +158,6 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
        reg &= ~VDCTRL4_SYNC_SIGNALS_ON;
        writel(reg, mxsfb->base + LCDC_VDCTRL4);
 
-       mxsfb_disable_axi_clk(mxsfb);
-
        clk_disable_unprepare(mxsfb->clk);
        if (mxsfb->clk_disp_axi)
                clk_disable_unprepare(mxsfb->clk_disp_axi);
@@ -208,7 +205,6 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
         * running. This may lead to shifted pictures (FIFO issue?), so
         * first stop the controller and drain its FIFOs.
         */
-       mxsfb_enable_axi_clk(mxsfb);
 
        /* Mandatory eLCDIF reset as per the Reference Manual */
        err = mxsfb_reset_block(mxsfb->base);
@@ -269,12 +265,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
 
        writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
               mxsfb->base + LCDC_VDCTRL4);
-
-       mxsfb_disable_axi_clk(mxsfb);
 }
 
 void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
 {
+       mxsfb_enable_axi_clk(mxsfb);
        mxsfb_crtc_mode_set_nofb(mxsfb);
        mxsfb_enable_controller(mxsfb);
 }
@@ -282,6 +277,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private
*mxsfb)
 void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
 {
        mxsfb_disable_controller(mxsfb);
+       mxsfb_disable_axi_clk(mxsfb);
 }
 

Then move the above section between mxsfb_crtc_mode_set_nofb() and
mxsfb_enable_controller().

--
Stefan

>  	mxsfb_disable_axi_clk(mxsfb);
>  }
>  
>  void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
>  {
> @@ -287,16 +309,12 @@ void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
>  void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
>  			       struct drm_plane_state *state)
>  {
>  	struct drm_simple_display_pipe *pipe = &mxsfb->pipe;
>  	struct drm_crtc *crtc = &pipe->crtc;
> -	struct drm_framebuffer *fb = pipe->plane.state->fb;
>  	struct drm_pending_vblank_event *event;
> -	struct drm_gem_cma_object *gem;
> -
> -	if (!crtc)
> -		return;
> +	dma_addr_t paddr;
>  
>  	spin_lock_irq(&crtc->dev->event_lock);
>  	event = crtc->state->event;
>  	if (event) {
>  		crtc->state->event = NULL;
> @@ -307,14 +325,12 @@ void mxsfb_plane_atomic_update(struct
> mxsfb_drm_private *mxsfb,
>  			drm_crtc_send_vblank_event(crtc, event);
>  		}
>  	}
>  	spin_unlock_irq(&crtc->dev->event_lock);
>  
> -	if (!fb)
> -		return;
> -
> -	gem = drm_fb_cma_get_gem_obj(fb, 0);
> -
> -	mxsfb_enable_axi_clk(mxsfb);
> -	writel(gem->paddr, mxsfb->base + mxsfb->devdata->next_buf);
> -	mxsfb_disable_axi_clk(mxsfb);
> +	paddr = mxsfb_get_fb_paddr(mxsfb);
> +	if (paddr) {
> +		mxsfb_enable_axi_clk(mxsfb);
> +		writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
> +		mxsfb_disable_axi_clk(mxsfb);
> +	}
>  }

  parent reply	other threads:[~2018-08-07 18:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-06 19:31 [PATCH v3 0/4] drm/mxsfb: Fix runtime PM for unpowering lcdif block Leonard Crestez
2018-08-06 19:31 ` [PATCH v3 1/4] drm/mxsfb: Fix initial corrupt frame when activating display Leonard Crestez
2018-08-07 10:53   ` Philipp Zabel
2018-08-07 18:29   ` Stefan Agner [this message]
2018-08-06 19:31 ` [PATCH v3 2/4] drm/mxsfb: Add pm_runtime calls to pipe_enable/disable Leonard Crestez
2018-08-07 18:32   ` Stefan Agner
2018-08-06 19:31 ` [PATCH v3 3/4] drm/mxsfb: Add PM_SLEEP support Leonard Crestez
2018-08-07 18:41   ` Stefan Agner
2018-08-06 19:31 ` [PATCH v3 4/4] drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm Leonard Crestez
2018-08-07 19:01   ` Stefan Agner
2018-08-08  8:00     ` Leonard Crestez
2018-08-08 12:30       ` Stefan Agner

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=e3f8a2e1a7947a3745a699ce5a3450dc@agner.ch \
    --to=stefan@agner.ch \
    --cc=Anson.Huang@nxp.com \
    --cc=aisheng.dong@nxp.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fabio.estevam@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=leonard.crestez@nxp.com \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=mirela.rabulea@nxp.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robert.chiras@nxp.com \
    --cc=shawnguo@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 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).