linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Dave Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics <intel-gfx@lists.freedesktop.org>,
	DRI <dri-devel@lists.freedesktop.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Eric Anholt <eric@anholt.net>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Subject: Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
Date: Fri, 21 Jul 2017 10:03:23 +1000	[thread overview]
Message-ID: <20170721100323.799d683a@canb.auug.org.au> (raw)
In-Reply-To: <20170718113946.47f64522@canb.auug.org.au>

Hi Dave,

The conflict below now exists between the drm-misc-fixes tree and the
drm tree.

On Tue, 18 Jul 2017 11:39:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/vc4/vc4_crtc.c
> 
> between commit:
> 
>   1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path")
> 
> from the drm-misc-fixes tree and commit:
> 
>   0b20a0f8c3cb ("drm: Add old state pointer to CRTC .enable() helper function")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/vc4/vc4_crtc.c
> index a12cc7ea99b6,9e0c1500375c..000000000000
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@@ -518,37 -519,23 +519,51 @@@ static void vc4_crtc_atomic_disable(str
>   	WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
>   		      (SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
>   		     SCALER_DISPSTATX_EMPTY);
> + 
> + 	/*
> + 	 * Make sure we issue a vblank event after disabling the CRTC if
> + 	 * someone was waiting it.
> + 	 */
> + 	if (crtc->state->event) {
> + 		unsigned long flags;
> + 
> + 		spin_lock_irqsave(&dev->event_lock, flags);
> + 		drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + 		crtc->state->event = NULL;
> + 		spin_unlock_irqrestore(&dev->event_lock, flags);
> + 	}
>   }
>   
>  +static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
>  +{
>  +	struct drm_device *dev = crtc->dev;
>  +	struct vc4_dev *vc4 = to_vc4_dev(dev);
>  +	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>  +	struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
>  +
>  +	if (crtc->state->event) {
>  +		unsigned long flags;
>  +
>  +		crtc->state->event->pipe = drm_crtc_index(crtc);
>  +
>  +		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>  +
>  +		spin_lock_irqsave(&dev->event_lock, flags);
>  +		vc4_crtc->event = crtc->state->event;
>  +		crtc->state->event = NULL;
>  +
>  +		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  +			  vc4_state->mm.start);
>  +
>  +		spin_unlock_irqrestore(&dev->event_lock, flags);
>  +	} else {
>  +		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  +			  vc4_state->mm.start);
>  +	}
>  +}
>  +
> - static void vc4_crtc_enable(struct drm_crtc *crtc)
> + static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
> + 				   struct drm_crtc_state *old_state)
>   {
>   	struct drm_device *dev = crtc->dev;
>   	struct vc4_dev *vc4 = to_vc4_dev(dev);
> @@@ -575,20 -556,22 +590,19 @@@
>   	/* Turn on the pixel valve, which will emit the vstart signal. */
>   	CRTC_WRITE(PV_V_CONTROL,
>   		   CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
>  -
>  -	/* Enable vblank irq handling after crtc is started. */
>  -	drm_crtc_vblank_on(crtc);
>   }
>   
> - static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
> - 				const struct drm_display_mode *mode,
> - 				struct drm_display_mode *adjusted_mode)
> + static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
> + 						const struct drm_display_mode *mode)
>   {
>   	/* Do not allow doublescan modes from user space */
> - 	if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) {
> + 	if (mode->flags & DRM_MODE_FLAG_DBLSCAN) {
>   		DRM_DEBUG_KMS("[CRTC:%d] Doublescan mode rejected.\n",
>   			      crtc->base.id);
> - 		return false;
> + 		return MODE_NO_DBLESCAN;
>   	}
>   
> - 	return true;
> + 	return MODE_OK;
>   }
>   
>   static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
> @@@ -650,15 -634,25 +664,15 @@@ static void vc4_crtc_atomic_flush(struc
>   
>   	WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
>   
>  -	if (crtc->state->event) {
>  -		unsigned long flags;
>  -
>  -		crtc->state->event->pipe = drm_crtc_index(crtc);
>  -
>  -		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>  -
>  -		spin_lock_irqsave(&dev->event_lock, flags);
>  -		vc4_crtc->event = crtc->state->event;
>  -		crtc->state->event = NULL;
>  -
>  -		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  -			  vc4_state->mm.start);
>  -
>  -		spin_unlock_irqrestore(&dev->event_lock, flags);
>  -	} else {
>  -		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  -			  vc4_state->mm.start);
>  -	}
>  +	/* Only update DISPLIST if the CRTC was already running and is not
>  +	 * being disabled.
> - 	 * vc4_crtc_enable() takes care of updating the dlist just after
> ++	 * vc4_crtc_atomic_enable() takes care of updating the dlist just after
>  +	 * re-enabling VBLANK interrupts and before enabling the engine.
>  +	 * If the CRTC is being disabled, there's no point in updating this
>  +	 * information.
>  +	 */
>  +	if (crtc->state->active && old_state->active)
>  +		vc4_crtc_update_dlist(crtc);
>   
>   	if (debug_dump_regs) {
>   		DRM_INFO("CRTC %d HVS after:\n", drm_crtc_index(crtc));



-- 
Cheers,
Stephen Rothwell

  reply	other threads:[~2017-07-21  0:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-18  1:39 linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree Stephen Rothwell
2017-07-21  0:03 ` Stephen Rothwell [this message]
2020-04-21  1:52 Stephen Rothwell
2020-04-21  6:10 ` Tomi Valkeinen
2020-04-23  3:17   ` Stephen Rothwell
2020-05-15 11:32     ` Tomi Valkeinen
2020-10-29  1:18 Stephen Rothwell
2022-04-13 23:47 Stephen Rothwell
2022-04-14  6:33 ` Christian König
2022-04-26  1:48 ` Stephen Rothwell
2022-11-15 23:47 Stephen Rothwell
2022-11-16  0:25 ` Stephen Rothwell
2022-11-16 12:13   ` Christian König
2023-01-27  2:28 Stephen Rothwell

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=20170721100323.799d683a@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=airlied@linux.ie \
    --cc=boris.brezillon@free-electrons.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@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 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).