From: Jesse Barnes
Signed-off-by: Jesse Barnes
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 136 ---
2 files changed, 129 insertions(+), 12 deletions(-)
v2:
- Add State & Constant C
"STALL_AT_SCOREBOARD" is much clearer than "STALL_EN" now that there are
several different kinds of stalls. Also, "INSTRUCTION_CACHE_FLUSH" is a
lot easier to understand at a glance than the terse "IS_FLUSH."
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_reg.h | 16
Not all PIPE_CONTROLs have a length of 2, so remove it from the #define
and make each invocation specify the desired length.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_reg.h |2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c |4 ++--
2 files changed, 3 insertions(+)
On Tue, 2011-10-04 at 13:46 +1100, Bojan Smojver wrote:
> So, yeah, for all intents and purposes, I can only reproduce it on
> this system.
If it matters, before I switched to ThinkPad T510, I had a Dell Inspiron
6400, also with Intel graphics. I was then hitting:
https://bugzilla.redhat.com/show
On Mon, 2011-10-03 at 23:32 -0300, Eugeni Dodonov wrote:
> I was investigating the issue for a couple of weeks, but I was unable
> to reproduce it on any of my machines. Does it only happens only on
> this thinkpad, or you can reproduce it consistently on other machines
> as well?
My other machine
On Mon, Oct 03, 2011 at 04:31:22PM -0700, Keith Packard wrote:
> On Mon, 3 Oct 2011 15:14:14 -0700, Ben Widawsky wrote:
>
> > +# define DP_PSR_SUPPORTED 1
>
> That's PSR version 1, not just a simple boolean
Ok.
>
> > +# define DP_PSR_SETUP_TIME_330 (0 << 1)
> >
On Oct 3, 2011 3:44 AM, "Bojan Smojver" wrote:
>
> On Tue, 2011-09-27 at 16:12 +1000, Bojan Smojver wrote:
> > This problem is covered by various bugs, one of them being:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=37142
> >
> > At some point there was a "solution" to essentially the same
On Mon, 3 Oct 2011 16:21:08 -0700, Jesse Barnes
wrote:
> Agreed; fortunately shutting everything off when no outputs are
> active should be simpler than trying flip the bits on & off every mode
> set. :)
We'd have to track when outputs are shut off; just tracking per clock
doesn't seem any hard
On Mon, 3 Oct 2011 15:14:14 -0700, Ben Widawsky wrote:
> +# define DP_PSR_SUPPORTED 1
That's PSR version 1, not just a simple boolean
> +# define DP_PSR_SETUP_TIME_330 (0 << 1)
> +# define DP_PSR_SETUP_TIME_275 (1 << 1)
> +# define DP_PSR_SETUP_TIME_2
On Mon, 03 Oct 2011 16:18:48 -0700
Keith Packard wrote:
> On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes
> wrote:
>
> > Now... is keeping the various refclks enabled costing us any power?
> > IOW, should we be trying to disable them when everything has been
> > DPMS'd off too?
>
> That's the
On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes
wrote:
> Now... is keeping the various refclks enabled costing us any power?
> IOW, should we be trying to disable them when everything has been
> DPMS'd off too?
That's the same as tracking usage and enabling/disabling on the fly as
modes are set
On Mon, 03 Oct 2011 15:59:29 -0700
Eric Anholt wrote:
> On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes
> wrote:
> > On Mon, 26 Sep 2011 11:59:23 -0700
> > Kenneth Graunke wrote:
> >
> > > + /* Just flush everything for now */
> > > + flags |= PIPE_CONTROL_WC_FLUSH;
> > > + flags |= PIPE_CONT
On Mon, Oct 03, 2011 at 02:25:39PM -0700, Keith Packard wrote:
> On Tue, 20 Sep 2011 15:29:47 -0700, Ben Widawsky wrote:
>
> > Add the addresses and definitions I care about for Panel Self Refresh, as
> > documented in the eDP spec.
>
> I generally review the addresses and bit definitions for an
On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes
wrote:
> On Mon, 26 Sep 2011 11:59:23 -0700
> Kenneth Graunke wrote:
>
> > + /* Just flush everything for now */
> > + flags |= PIPE_CONTROL_WC_FLUSH;
> > + flags |= PIPE_CONTROL_IS_FLUSH;
> > + flags |= PIPE_CONTROL_TC_FLUSH;
> > + flag
On Tue, 20 Sep 2011 15:29:47 -0700, Ben Widawsky wrote:
> Add the addresses and definitions I care about for Panel Self Refresh, as
> documented in the eDP spec.
I generally review the addresses and bit definitions for any new
registers -- getting them wrong makes debugging the code really hard.
On Mon, 03 Oct 2011 14:14:53 -0700
Keith Packard wrote:
> On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes
> wrote:
>
> > This is the only bit I'd like to see changed. While we still have the
> > domain tracking code we may as well try to honor it and limit our
> > flushing here like we do wit
On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes
wrote:
> This is the only bit I'd like to see changed. While we still have the
> domain tracking code we may as well try to honor it and limit our
> flushing here like we do with MI_FLUSH.
I'd like to see this patch put in place, and then any 'op
On Wed, 28 Sep 2011 15:22:48 -0300
Paulo Zanoni wrote:
> 2011/9/27 Keith Packard :
> > Here's a patch sequence which cleans up a bunch of PCH refclk related
> > bits.
>
> For the series: Tested-by: Paulo Zanoni
>
> Tested all the patches on Ironlake (LVDS + VGA). Fixes fd.o bug #38750 for me.
On Tue, 27 Sep 2011 11:11:57 -0700
Keith Packard wrote:
> On Tue, 27 Sep 2011 17:56:39 +0100, Chris Wilson
> wrote:
>
> > Ah, now I see why we moved from using the active configuration earlier. ;-)
>
> My evil plan is revealed!
>
> > Doesn't this prevent us from ever using SSC though, as vir
On Fri, 30 Sep 2011 11:17:38 -0700
Keith Packard wrote:
> On Fri, 30 Sep 2011 09:20:55 -0400, Ted Ts'o wrote:
>
> > What kind of battery life do you get with these patches applied, out
> > of curiosity?
>
> 4-5 hours when doing the usual web-surfing, etc. Seems pretty much the
> same as people
On Thu, 29 Sep 2011 18:09:42 -0700
Keith Packard wrote:
> Talking to the eDP DDC channel requires that the panel be powered
> up. Wrap both the EDID and modes fetch code with calls to turn the vdd
> power on and back off.
>
These VDD AUX changes look good, ack on all of them.
--
Jesse Barnes,
On Thu, 29 Sep 2011 18:09:48 -0700
Keith Packard wrote:
> The return value was unused, so just stop doing that.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/inte
On Mon, Oct 03, 2011 at 01:21:03PM -0700, Andrew Lutomirski wrote:
> I'm up and running again. What's the latest patch I'm supposed to test?
>
> i915.semaphores=1 intel_iommu=off appears to work.
Patches are in the works. Thanks a lot for sticking to this and testing
all the stuff that didn't re
On Thu, 29 Sep 2011 18:09:37 -0700
Keith Packard wrote:
> Verify that the eDP VDD is on, either with the panel being on or with
> the VDD force-on bit being set.
>
> This demonstrates that in many instances, VDD is not on when needed,
> which leads to failed EDID communications.
>
> Signed-off-
On Fri, 30 Sep 2011 10:58:26 -0700
Keith Packard wrote:
> On Fri, 30 Sep 2011 18:32:35 +0200, Daniel Vetter wrote:
>
> > Ok, this is way over my head, just checked whether the patch does what it
> > claims to - nice exercise in reading dp modeset code ;-)
>
> Yeah, it's purely heuristic -- the
On Fri, 30 Sep 2011 18:17:32 +0200
Daniel Vetter wrote:
> On Thu, Sep 29, 2011 at 06:09:33PM -0700, Keith Packard wrote:
> > We were relying on the BIOS to set these bits, which doesn't always
> > happen.
> >
> > Signed-off-by: Keith Packard
>
> Ok, I'll try to increase our review-bandwidth fo
I'm up and running again. What's the latest patch I'm supposed to test?
i915.semaphores=1 intel_iommu=off appears to work.
--Andy
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 26 Sep 2011 11:59:23 -0700
Kenneth Graunke wrote:
> + /* Just flush everything for now */
> + flags |= PIPE_CONTROL_WC_FLUSH;
> + flags |= PIPE_CONTROL_IS_FLUSH;
> + flags |= PIPE_CONTROL_TC_FLUSH;
> + flags |= PIPE_CONTROL_DEPTH_FLUSH;
> + flags |= PIPE_CONTROL_VF
On Sat, Oct 01, 2011 at 07:15:18PM -0700, Ben Widawsky wrote:
> On Gen6+ we have other rings which may be in use. We haven't hung if the
> blit or media ring is still going
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_debugfs.c |6 +-
> drivers/gpu/drm/i915/i915_drv.h
On Sat, Oct 1, 2011 at 21:01, Keith Packard wrote:
> On Sat, 1 Oct 2011 11:59:09 +0200, Daniel Vetter wrote:
>
>> So while you bang your head against this, can you add the backlight power
>> sequencing delays for lvds panels, too? The lvds panel power sequencing
>> should be imo safe - we just ms
On Sat, Oct 01, 2011 at 07:15:16PM -0700, Ben Widawsky wrote:
> Do hangchecks for all rings instead of just RCS + cleanup.
> A bit of extra info on error.
> Don't kick the rings when doing debugging.
>
> Ben Widawsky (2):
> drm/i915: collect per ring page fault info on error
> drm/i915: check
On Sat, Oct 01, 2011 at 11:09:33PM -0700, Ben Widawsky wrote:
> On Sat, 01 Oct 2011 20:59:28 -0700
> Eric Anholt wrote:
>
> > On Sat, 1 Oct 2011 19:15:19 -0700, Ben Widawsky wrote:
> > > From: Daniel Vetter
> > >
> > > Only do it in the hope of resurrecting the gpu. Disable when reset is
> >
I found this workaround in the docs while trying to debug a certain test
case I stumbled upon. The patch is in flux as I try to get it to be
useful. Both my test case and xscreensaver slip have similar scenarios
which I'm hoping some variation of this patch will fix.
Again, this doesn't fix anyth
On Mon, 3 Oct 2011 09:41:28 +0200
Daniel Vetter wrote:
> On Sun, Oct 02, 2011 at 06:27:12PM -0700, Ben Widawsky wrote:
> > Found this through doc inspection. I don't have a failing test case that
> > this
> > fixes, but the docs specify we need to do it in addition to the A0
> > workaround.
>
I found this workaround in the docs while trying to debug a certain test
case I stumbled upon. The patch is in flux as I try to get it to be
useful. Both my test case and xscreensaver slip have similar scenarios
which I'm hoping some variation of this patch will fix.
Again, this doesn't fix anythi
On Sun, Oct 02, 2011 at 06:27:12PM -0700, Ben Widawsky wrote:
> Found this through doc inspection. I don't have a failing test case that this
> fixes, but the docs specify we need to do it in addition to the A0 workaround.
Can you confirm that the A0 workaround is really needed in addition to
this
On Sun, 2 Oct 2011 18:27:12 -0700, Ben Widawsky wrote:
> Found this through doc inspection. I don't have a failing test case that this
> fixes, but the docs specify we need to do it in addition to the A0 workaround.
Can you try running /usr/lib/xscreenaver/xslip with and without this
patch? That
37 matches
Mail list logo
