From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Subject: Re: IEGD to xf86-video-intel
Date: Thu, 16 Jan 2014 16:11:49 +0200
Message-ID: <20140116141149.GM9454@intel.com>
References: <87vbxk8fio.fsf@intel.com> <52D7D37C.8080304@funkwerk-itk.com>
	<20140116132825.GL9454@intel.com>
	<CAKMK7uFBmt4E4NfOPNQyRp01Z5ZUqFMA4KQz97Sa_dcMcpkWAw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mga14.intel.com (mga14.intel.com [143.182.124.37])
	by gabe.freedesktop.org (Postfix) with ESMTP id 906F8105819
	for <intel-gfx@lists.freedesktop.org>;
	Thu, 16 Jan 2014 06:11:53 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <CAKMK7uFBmt4E4NfOPNQyRp01Z5ZUqFMA4KQz97Sa_dcMcpkWAw@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces@lists.freedesktop.org
Errors-To: intel-gfx-bounces@lists.freedesktop.org
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Thu, Jan 16, 2014 at 03:00:26PM +0100, Daniel Vetter wrote:
> On Thu, Jan 16, 2014 at 2:28 PM, Ville Syrj=E4l=E4
> <ville.syrjala@linux.intel.com> wrote:
> > On Thu, Jan 16, 2014 at 01:41:32PM +0100, Dragos Carp wrote:
> >> Hi Jani,
> >>
> >> thank you for your response.
> >> Attached is the dmesg output trimmed of more thousand lines like:
> >> [drm:i915_irq_handler], pipe B underrun
> >
> > That's a bit weird. We're supposed to disable the underrun reporting
> > after the first error. I guess the pipe state gets stuck somehow and
> > it just keeps reporting the same error all the time...
> =

> Only on pch platforms, but not on gmch stuff. Those still lack a bit
> of work to make them fit into the underrun reporting framework. And we
> need to enable those underruns to be much louder ...

Oh right. Somehow I remembered that it was universal. But now that
re-think things PIPESTAT doesn't even have an enable bit for underruns.
So I guess an underrun won't itself generate an interrupt on gmch
platforms, but instead you need some other interrupt to fire to detect
it. That means we should just have some flag/bool to shut up the debug
message and the rest of the code is fine as is.

-- =

Ville Syrj=E4l=E4
Intel OTC