All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
Date: Tue, 28 Jan 2014 20:42:14 +0100	[thread overview]
Message-ID: <20140128194214.GH7444@phenom.ffwll.local> (raw)
In-Reply-To: <CAKMK7uEZysj9NPiHOaRy5XTEt0yQ8Dew_gEYsiZMayZ98r6W3A@mail.gmail.com>

On Tue, Jan 28, 2014 at 06:17:00PM +0100, Daniel Vetter wrote:
> On Wed, Jan 8, 2014 at 7:43 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > The log looks fairly clear to me:
> >
> > 1. initially panel fitter is enabled on pipe B, and pipe B is outputting
> >    to LVDS and VGA. Border is enabled.
> > 2. pipe A gets enabled outputting to LVDS. This will overwrite the
> >    LVDS border bits
> > 3. pipe B is still active so we do the state check, but as the LVDS
> >    border bits have been clobbered earlier, the state checker gets
> >    angry
> 
> Meh, I've been fairly dense the entire time. This is indeed the
> root-cause, with the twist that we're allowing the impossible:
> Essentially we take away the panel fitter from pipe B to pipe A while
> it is strictly still in use by pipe B for VGA. Currently no idea how
> to properly fix this in a not too intrusive way.
> 
> The other issue is that the encoders connected to pipe B change in the
> first modeset, but that's not reflected in the pipe masks.

I think I need a bit more debug output first. Can you please apply the
below patch to drm-intel-nightly and then grab a drm.debug=0xe dmesg from
boot?

Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 122f87155b8e..554c30e89308 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9144,6 +9144,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes,
 		if (connector->new_encoder)
 			*prepare_pipes |=
 				1 << connector->new_encoder->new_crtc->pipe;
+
+		DRM_DEBUG_KMS("[CONNECTOR:%d:%s]: prepare_pipes %u\n",
+			connector->base.base.id,
+			drm_get_connector_name(&connector->base),
+			*prepare_pipes);
 	}
 
 	list_for_each_entry(encoder, &dev->mode_config.encoder_list,
@@ -9159,6 +9164,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes,
 
 		if (encoder->new_crtc)
 			*prepare_pipes |= 1 << encoder->new_crtc->pipe;
+
+		DRM_DEBUG_KMS("[ENCODER:%d:%s]: prepare_pipes %u\n",
+			encoder->base.base.id,
+			drm_get_encoder_name(&encoder->base),
+			*prepare_pipes);
 	}
 
 	/* Check for pipes that will be enabled/disabled ... */
@@ -9171,6 +9181,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes,
 			*disable_pipes |= 1 << intel_crtc->pipe;
 		else
 			*prepare_pipes |= 1 << intel_crtc->pipe;
+
+		DRM_DEBUG_KMS("[CRTC:%d:%s]: prepare_pipes %u\n",
+			intel_crtc->base.base.id,
+			pipe_name(intel_crtc->pipe),
+			*prepare_pipes);
 	}
 
 
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Excessive WARN()s in Intel 915 driver
Date: Tue, 28 Jan 2014 20:42:14 +0100	[thread overview]
Message-ID: <20140128194214.GH7444@phenom.ffwll.local> (raw)
In-Reply-To: <CAKMK7uEZysj9NPiHOaRy5XTEt0yQ8Dew_gEYsiZMayZ98r6W3A@mail.gmail.com>

On Tue, Jan 28, 2014 at 06:17:00PM +0100, Daniel Vetter wrote:
> On Wed, Jan 8, 2014 at 7:43 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > The log looks fairly clear to me:
> >
> > 1. initially panel fitter is enabled on pipe B, and pipe B is outputting
> >    to LVDS and VGA. Border is enabled.
> > 2. pipe A gets enabled outputting to LVDS. This will overwrite the
> >    LVDS border bits
> > 3. pipe B is still active so we do the state check, but as the LVDS
> >    border bits have been clobbered earlier, the state checker gets
> >    angry
> 
> Meh, I've been fairly dense the entire time. This is indeed the
> root-cause, with the twist that we're allowing the impossible:
> Essentially we take away the panel fitter from pipe B to pipe A while
> it is strictly still in use by pipe B for VGA. Currently no idea how
> to properly fix this in a not too intrusive way.
> 
> The other issue is that the encoders connected to pipe B change in the
> first modeset, but that's not reflected in the pipe masks.

I think I need a bit more debug output first. Can you please apply the
below patch to drm-intel-nightly and then grab a drm.debug=0xe dmesg from
boot?

Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 122f87155b8e..554c30e89308 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9144,6 +9144,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes,
 		if (connector->new_encoder)
 			*prepare_pipes |=
 				1 << connector->new_encoder->new_crtc->pipe;
+
+		DRM_DEBUG_KMS("[CONNECTOR:%d:%s]: prepare_pipes %u\n",
+			connector->base.base.id,
+			drm_get_connector_name(&connector->base),
+			*prepare_pipes);
 	}
 
 	list_for_each_entry(encoder, &dev->mode_config.encoder_list,
@@ -9159,6 +9164,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes,
 
 		if (encoder->new_crtc)
 			*prepare_pipes |= 1 << encoder->new_crtc->pipe;
+
+		DRM_DEBUG_KMS("[ENCODER:%d:%s]: prepare_pipes %u\n",
+			encoder->base.base.id,
+			drm_get_encoder_name(&encoder->base),
+			*prepare_pipes);
 	}
 
 	/* Check for pipes that will be enabled/disabled ... */
@@ -9171,6 +9181,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes,
 			*disable_pipes |= 1 << intel_crtc->pipe;
 		else
 			*prepare_pipes |= 1 << intel_crtc->pipe;
+
+		DRM_DEBUG_KMS("[CRTC:%d:%s]: prepare_pipes %u\n",
+			intel_crtc->base.base.id,
+			pipe_name(intel_crtc->pipe),
+			*prepare_pipes);
 	}
 
 
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-01-28 19:42 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-07 18:50 Excessive WARN()s in Intel 915 driver Alan Stern
2014-01-07 20:12 ` Daniel Vetter
2014-01-08 16:08   ` Alan Stern
2014-01-08 16:17     ` Daniel Vetter
2014-01-08 18:34       ` Alan Stern
2014-01-08 20:21         ` Daniel Vetter
2014-01-08 20:21           ` Daniel Vetter
2014-01-08 23:15           ` Alan Stern
2014-01-13 20:16           ` Alan Stern
2014-01-14  9:05             ` Daniel Vetter
2014-01-14 14:43               ` Alan Stern
2014-01-27  9:02                 ` Daniel Vetter
2014-01-27 15:30                   ` Alan Stern
2014-01-27 15:56                     ` Daniel Vetter
2014-01-27 16:05                       ` Alan Stern
2014-01-27 16:36                         ` Daniel Vetter
2014-01-27 16:36                           ` Daniel Vetter
2014-01-27 17:14                           ` Alan Stern
2014-01-28 16:34                   ` Alan Stern
2014-01-28 16:34                     ` Alan Stern
2014-01-14 12:52             ` [Intel-gfx] " Jani Nikula
2014-01-08 18:43       ` Ville Syrjälä
2014-01-08 18:43         ` Ville Syrjälä
2014-01-28 17:17         ` [Intel-gfx] " Daniel Vetter
2014-01-28 17:17           ` Daniel Vetter
2014-01-28 19:42           ` Daniel Vetter [this message]
2014-01-28 19:42             ` Daniel Vetter
2014-01-30 14:53             ` [Intel-gfx] " Alan Stern
2014-01-30 14:53               ` Alan Stern
2014-01-30 15:22               ` [Intel-gfx] " Daniel Vetter
2014-01-30 15:22                 ` Daniel Vetter
2014-01-30 15:52                 ` [Intel-gfx] " Alan Stern
2014-01-30 15:52                   ` Alan Stern
2014-06-25 18:06       ` Regression in i915 driver in 3.16-rc2 Alan Stern
2014-06-25 18:26         ` [Intel-gfx] " Ville Syrjälä
2014-06-25 18:26           ` Ville Syrjälä
2014-06-25 18:50           ` [Intel-gfx] " Alan Stern
2014-06-25 18:50             ` Alan Stern
2014-06-30 10:52             ` [Intel-gfx] " Jani Nikula
2014-06-30 10:52               ` Jani Nikula

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=20140128194214.GH7444@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=ville.syrjala@linux.intel.com \
    /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.