[Precise][SRU][PATCH 1/1] drm/i915: Periodically sanity check power management

[Seth Forshee]

On Fri, Mar 08, 2013 at 06:28:15AM -0800, Leann Ogasawara wrote:
> On 03/07/2013 12:46 PM, Seth Forshee wrote:
> > On Thu, Mar 07, 2013 at 12:14:55PM -0800, leann.ogasawara at canonical.com wrote:
> >> From: Chris Wilson <chris at chris-wilson.co.uk>
> >>
> >> BugLink: http://bugs.launchpad.net/bugs/1146425
> >>
> >> Every time we use the device after a period of idleness, check that the
> >> power management setup is still sane. This is to workaround a bug
> >> whereby it seems that we begin suppressing power management interrupts,
> >> preventing SandyBridge+ from going into turbo mode.
> >>
> >> This patch does have a side-effect. It removes the mark-busy for just
> >> moving the cursor - we don't want to increase the render clock just for
> >> the sprite, though we may want to bump the display frequency. I'd argue
> >> that we do not, and certainly don't want to take the struct_mutex here
> >> due to the large latencies that introduces.
> > Regarding this last paragraph: The upstream commit does remove a call to
> > intel_mark_busy() from intel_crtc_update_cursor(), which I suspect is
> > what this refers to. That call is present in our precise kernel but is
> > not removed by this patch. Do you know whether or not that omission was
> > intentional?
> 
> Hi Seth,
> 
> After checking with Intel, the ommission was intentional.  According to
> Intel, there are multiple Gen6+ related rps issues which are fixed in
> the upstream kernel.  The Precise kernel unfortunately does not have all
> of these fixes applied.  Intel states that it is only safe to remove the
> call to intel_mark_busy() after having applied all the rps fixes. 
> Unfortunately, all of the rps fixes may not be acceptable for Precise
> SRU so as it stands the call to intel_mark_busy() needs to  remain present.

Okay, thanks for checking. In that case:

Acked-by: Seth Forshee <seth.forshee at canonical.com>