All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Implement a better i945gm vblank irq vs. C-states workaround
Date: Thu, 3 Oct 2019 17:18:44 +0300	[thread overview]
Message-ID: <20191003141844.GL1208@intel.com> (raw)
In-Reply-To: <157011193132.2173.15392278985624990382@skylake-alporthouse-com>

On Thu, Oct 03, 2019 at 03:12:11PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-10-03 15:02:31)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The current "disable C3+" workaround for the delayed vblank
> > irqs on i945gm no longer works. I'm not sure what changed, but
> > now I need to also disable C2. I also got my hands on a i915gm
> > machine that suffers from the same issue.
> > 
> > After some furious poking of registers I managed to find a
> > better workaround: The "Do not Turn off Core Render Clock in C
> > states" bit. With that I no longer have to disable any C-states,
> > and as a nice bonus the power cost is only ~1/4 of the
> > "disable C3+" method (which mind you doesn't even work anymore,
> > and so would have an even higher power cost if we made it work
> > by also disabling C2).
> > 
> > So let's throw out all the cpuidle/qos crap and just toggle
> > the magic bit as needed. And we extend the workaround to cover
> > i915gm as well.
> 
> Nice discovery. ScratchPad0 suggests that it may have been a late
> addition, there might be some chips out there that don't have the magic
> bit. Working on most is better than broken on all.

Yeah. And at least 100% of *my* broken machines now work ;)

> 
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Empirical results rule, and I for one am much happier without needing
> qos dma_latency,
> Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-10-03 14:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03 14:02 [PATCH] drm/i915: Implement a better i945gm vblank irq vs. C-states workaround Ville Syrjala
2019-10-03 14:12 ` Chris Wilson
2019-10-03 14:18   ` Ville Syrjälä [this message]
2019-10-03 16:39 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-10-04  1:24 ` ✗ Fi.CI.IGT: failure " Patchwork

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=20191003141844.GL1208@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.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 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.