[Intel-gfx] [PATCH] drm/i915: fix plane/cursor handling when runtime suspended

[Chris Wilson]

On Tue, Aug 12, 2014 at 10:37:21PM +0200, Daniel Vetter wrote:
> On Tue, Aug 12, 2014 at 10:30 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Tue, Aug 12, 2014 at 10:19:20PM +0200, Daniel Vetter wrote:
> >> On Tue, Aug 12, 2014 at 9:33 PM, Paulo Zanoni <przanoni at gmail.com> wrote:
> >> > 2014-08-12 16:28 GMT-03:00 Chris Wilson <chris at chris-wilson.co.uk>:
> >> >> On Tue, Aug 12, 2014 at 04:12:38PM -0300, Paulo Zanoni wrote:
> >> >>> But we just get/put RPM around this function, not for the whole time
> >> >>> while the object is pinned.
> >> >>
> >> >> Ah misread, saw pin->get, unpin->put and assumed the symmetry. But why
> >> >> unpin then? It doesn't touch any hardware registers.
> >> >
> >> > Only because Daniel asked it on a conversation we had on IRC, and I
> >> > automatically assumed the patch would be rejected if I didn't include
> >> > it :)
> >> >
> >> > Since both you and VIlle pointed that out, I should probably submit
> >> > yet another version, without the unpin part, and let Daniel choose
> >> > which one to merge...
> >>
> >> Hm, I've indeed forgotten about the lazy unbinding. But that poses the
> >> question about the final bo unref. For example:
> >> 1) create bo, gtt mmap it to force it into existence (and into the global gtt)
> >> 2) unmap binding
> >> 3) wait for rpm entry
> >> 4) unref bo ... causing pte writes for the global gtt unbinding while
> >> runtime suspended or not?
> >>
> >> boom or not boom?
> >>
> >> Maybe the bug is simply in a different function ;-)
> >
> > Yes. If you get serious about it, you will want to move the lazy stuff
> > into its own workqueue to be run the next time the device is awake.
> 
> 4b) shrinker happens and unbinds (potentially purgeable) buffer objects.
> 
> In that case I don't think the core mm would be happy if we'd
> indefinitely delay this until someone wiggles the mouse.

You underestimate just how much we can delay it ;-) But for your next
trick, you could unbind the buffer without touching the ptes since the
gpu is not using those pages... Diminishing returns I guess.

> Especially if
> the compositor wants that memory to render the frame it needs to
> switch everything on again ...

But's true without rpm anyway. It would need to enable the device to
render, whether or not the system is thrashing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre