Keep track of ring seqno progress and if there are no
progress detected, declare hang. Use actual head (acthd)
to distinguish between ring stuck and batchbuffer looping
situation. Stuck ring will be kicked to trigger progress.
This commit adds a hard limit for batchbuffer completion time.
If batch
On Wed, May 29, 2013 at 09:43:05PM +0200, Daniel Vetter wrote:
> This was accidentally broken in the south error interrupt handling
> work:
>
> commit 8664281b64c457705db72fc60143d03827e75ca9
> Author: Paulo Zanoni
> Date: Fri Apr 12 17:57:57 2013 -0300
>
> drm/i915: report Gen5+ CPU and P
On Wed, May 29, 2013 at 09:45:20PM +0200, Daniel Vetter wrote:
> On Wed, May 29, 2013 at 07:56:11PM +0200, Daniel Vetter wrote:
> > Now that we track the cpu transcoder we need accurately in the pipe
> > config we can finally fix up the transcoder check. With the current
> > code eDP on port D will
On Wed, May 29, 2013 at 05:23:46PM +0100, Damien Lespiau wrote:
> On Tue, May 28, 2013 at 07:22:25PM -0700, Ben Widawsky wrote:
> > v2: Add new PCH_NOP check (Damien)
> > Add SDEIMR comment (Damien)
> >
> > Signed-off-by: Ben Widawsky
>
> Reviewed-by: Damien Lespiau
Merged thus far, I need to
On Wed, May 29, 2013 at 07:56:11PM +0200, Daniel Vetter wrote:
> Now that we track the cpu transcoder we need accurately in the pipe
> config we can finally fix up the transcoder check. With the current
> code eDP on port D will be broken since we'd errornously cut the
> power.
>
> For reference s
This was accidentally broken in the south error interrupt handling
work:
commit 8664281b64c457705db72fc60143d03827e75ca9
Author: Paulo Zanoni
Date: Fri Apr 12 17:57:57 2013 -0300
drm/i915: report Gen5+ CPU and PCH FIFO underruns
Cc: Paulo Zanoni
Cc: Ben Widawsky
Signed-off-by: Daniel Ve
On Tue, May 28, 2013 at 07:22:24PM -0700, Ben Widawsky wrote:
> HSW has some special requirements for the VEBOX. Splitting out the
> interrupt handler will make the code a bit nicer and less error prone
> when we begin to handle those.
>
> The slight functional change in this patch (queueing work
On Tue, May 28, 2013 at 07:22:19PM -0700, Ben Widawsky wrote:
> The video enhancement command streamer is a new ring on HSW which does
> what it sounds like it does. This patch provides the most minimal
> inception of the ring.
>
> In order to support a new ring, we need to bump the number. The pa
On Mon, May 27, 2013 at 05:15:16PM +0800, Wang Xingchao wrote:
> Haswell Display audio depends on power well in graphic side, it should
> request power well before use it and release power well after use.
> I915 will not shutdown power well if it detects audio is using.
> This patch protects displa
Now that we track the cpu transcoder we need accurately in the pipe
config we can finally fix up the transcoder check. With the current
code eDP on port D will be broken since we'd errornously cut the
power.
For reference see
commit 2124b72e6283c4e84a55e71077fee91793f4c801
Author: Paulo Zanoni
D
On Mon, May 13, 2013 at 04:32:13PM +0300, Mika Kuoppala wrote:
> Rework of per ring hangcheck made this obsolete.
>
>
>
Probably could have put this in the last patch. Assuming you add the
comment on #4, and Daniel/Chris are okay with the proposed functional
change, 4 & 5 are:
Reviewed-by: Ben Wid
On Tue, May 28, 2013 at 07:22:26PM -0700, Ben Widawsky wrote:
> At the moment, these values are wiped out anyway by the rps
> enable/disable. That will be changed in the next patch though.
>
> v2: Add post install setup to address issue found by Damien in the next
> patch.
> replaced
> WARN_ON(dev
On Tue, May 28, 2013 at 07:22:27PM -0700, Ben Widawsky wrote:
> PM interrupts have an expanded role on HSW. It helps route the EBOX
> interrupts. This patch is necessary to make the existing code which
> touches the mask, and enable registers more friendly to other code paths
> that also will need
On Wed, May 29, 2013 at 09:22:36AM -0700, Ben Widawsky wrote:
> From: "Xiang, Haihao"
>
> v2: Removed rebase relic VECS ring from i915_gem_request_info (Damien)
>
> v3: s/hsw/hws in debugfs which I introduced in v2 (Jon)
>
> Signed-off-by: Xiang, Haihao
> [Order changed, and modified by]
> CC:
On Wed, May 29, 2013 at 07:06:15PM +0300, Ville Syrjälä wrote:
> On Fri, May 24, 2013 at 07:05:12PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > We were previously only setting the WM_PIPE registers, now we are
> > setting the LP watermark registers. This should allow deeper PC
> > s
On Tue, May 28, 2013 at 07:22:25PM -0700, Ben Widawsky wrote:
> v2: Add new PCH_NOP check (Damien)
> Add SDEIMR comment (Damien)
>
> Signed-off-by: Ben Widawsky
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedes
Without this change I saw PIPE_FIFO_UNDERRUN_STATUS set in PIPEASTAT, which
I took to indicate an underrun problem.
Here's what I found with other modes on this monitor:
1920x1200 works with pixel doubling enabled. Pixel clock 193.2 MHz.
2048x1152 works with pixel doubling enabled. Pixel clock 19
From: "Xiang, Haihao"
v2: Removed rebase relic VECS ring from i915_gem_request_info (Damien)
v3: s/hsw/hws in debugfs which I introduced in v2 (Jon)
Signed-off-by: Xiang, Haihao
[Order changed, and modified by]
CC: "Bloomfield, Jon"
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915
On Fri, May 24, 2013 at 11:59:21AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Now we compute the results for both 1/2 and 5/6 partitioning and then
> use hsw_find_best_result to choose which one to use.
>
> With this patch, Haswell watermarks support should be in good shape.
> The only
On Tue, May 28, 2013 at 07:22:20PM -0700, Ben Widawsky wrote:
> Like the other rings, the VECS supports semaphores. The semaphore stuff
> is a bit wonky so this patch on it's own should be nice for review.
>
> This patch should have no functional impact.
>
> v2: Fix the English parts of clarifica
On Fri, May 24, 2013 at 07:05:12PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We were previously only setting the WM_PIPE registers, now we are
> setting the LP watermark registers. This should allow deeper PC
> states, resulting in power savings.
>
> We're only using 1/2 data buffer pa
On Tue, May 28, 2013 at 07:22:18PM -0700, Ben Widawsky wrote:
> This replaces the existing MBOX update code with a more generalized
> calculation for emitting mbox updates. We also create a sentinel for
> doing the updates so we can more abstractly deal with the rings.
>
> When doing MBOX updates
On Tue, May 28, 2013 at 07:22:17PM -0700, Ben Widawsky wrote:
> Semaphores are tied very closely to the rings in the GPU. Trivial patch
> adds comments to the existing code so that when we add new rings we can
> include comments there as well. It also helps distinguish the ring to
> semaphore mailb
Only lvds/tv did actually check for cloning or not, but many more
places should.
Notices because my ivb tried to enable both cpu edp and vga on the
first crtc - the resulting confusion between has_pch_encoder,
has_dp_encoder but not actually being a pch dp encoder resulting in
hilarity (hitting a
On Tue, May 28, 2013 at 11:50:46AM -0700, Ben Widawsky wrote:
> > > - if (gt_iir & (GT_GEN6_BLT_CS_ERROR_INTERRUPT |
> > > - GT_GEN6_BSD_CS_ERROR_INTERRUPT |
> > > - GT_RENDER_CS_ERROR_INTERRUPT)) {
> > > + if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
> > > +
On Tue, May 28, 2013 at 04:00:18PM +0200, Daniel Vetter wrote:
> Only lvds/tv did actually check for cloning or not, but many more
> places should.
>
> Notices because my ivb tried to enable both cpu edp and vga on the
> first crtc - the resulting confusion between has_pch_encoder,
> has_dp_encode
On Mon, May 27, 2013 at 04:21:19PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We were previously calling sandybridge_update_wm on HSW, but the SNB
> function didn't really match the HSW specification, so we were just
> writing the wrong values.
>
> With this patch, the haswell_update_wm
On Tue, May 28, 2013 at 10:39:07AM -0700, Stuart Abercrombie wrote:
> Any comments?
>
> Without this, plugging one of the older Chromebook models into a Dell U3011
> monitor produces a garbled display at the default 2048x1280 resolution.
>
> The original threshold was apparently fairly arbitrary:
Any comments?
Without this, plugging one of the older Chromebook models into a Dell U3011
monitor produces a garbled display at the default 2048x1280 resolution.
The original threshold was apparently fairly arbitrary:
http://cgit.freedesktop.org/~anholt/xf86-video-intel/commit/?id=8fcf9a81179ee8
On Tue, Apr 23, 2013 at 05:27:08PM +0300, Mika Kuoppala wrote:
> crtc is holding a reference to a cursor bo and it needs
> to be released when crtc is destroyed so that we don't leak
> the cursor bo.
>
> v2: Enhance set and move cursor so that disabled
> cursor is handled correctly (Ville Syrjälä)
On Wed, May 29, 2013 at 02:33:07PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > It appears that a beneficial side-effect of Mika's more accurate hangman
> > work is to speed up hang detection and execution. This exposes a bug in
> > the reset code that then treats repeated simulated h
Chris Wilson writes:
> It appears that a beneficial side-effect of Mika's more accurate hangman
> work is to speed up hang detection and execution. This exposes a bug in
> the reset code that then treats repeated simulated hangs as an
> indication that the machine is wedged. Jiggle the code aroun
On Wed, May 29, 2013 at 10:06:20AM +0100, Chris Wilson wrote:
> On Wed, May 29, 2013 at 10:41:29AM +0200, Daniel Vetter wrote:
> > If we always force the pipe A to on we can't use the hw state to
> > decide whether it should be on. Hence quirk the quirk.
> >
> > The problem is that crtc->active tr
On Wed, May 29, 2013 at 10:41:29AM +0200, Daniel Vetter wrote:
> If we always force the pipe A to on we can't use the hw state to
> decide whether it should be on. Hence quirk the quirk.
>
> The problem is that crtc->active tracks the state of the entire
> display pipe, i.e. including planes, enco
If we always force the pipe A to on we can't use the hw state to
decide whether it should be on. Hence quirk the quirk.
The problem is that crtc->active tracks the state of the entire
display pipe, i.e. including planes, encoders and all. But our hw
state readout simply looks at the pipe. But with
On Wed, May 29, 2013 at 10:09:34AM +0200, Daniel Vetter wrote:
> On Wed, May 29, 2013 at 9:54 AM, Chris Wilson
> wrote:
> > On Wed, May 29, 2013 at 09:28:22AM +0200, Daniel Vetter wrote:
> >> If we always force the pipe A to on we can't use the hw state to
> >> decide whether it should be on. Hen
On Wed, May 29, 2013 at 9:54 AM, Chris Wilson wrote:
> On Wed, May 29, 2013 at 09:28:22AM +0200, Daniel Vetter wrote:
>> If we always force the pipe A to on we can't use the hw state to
>> decide whether it should be on. Hence quirk the quirk.
>
> This is misleading as it is not the hw state that
On Wed, May 29, 2013 at 09:28:22AM +0200, Daniel Vetter wrote:
> If we always force the pipe A to on we can't use the hw state to
> decide whether it should be on. Hence quirk the quirk.
This is misleading as it is not the hw state that is unreliable, but
crtc->active that is a misnomer. The quirk
On Tue, May 28, 2013 at 11:30:44AM -0300, Paulo Zanoni wrote:
> 2013/5/28 Daniel Vetter :
> > - Correct cpu->pch display matching is already check when we detect
> > the PCH type at driver load.
> > - Plane/pipe state is already checked both when a) enabling, b)
> > disabling and in c) the mode
If we always force the pipe A to on we can't use the hw state to
decide whether it should be on. Hence quirk the quirk.
Note that in the hw state readout we don't really care since we have a
big hack to force-enable pipe A anyway.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64764
Cc: s
40 matches
Mail list logo
