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

Daniel Vetter daniel at ffwll.ch
Tue Aug 12 22:37:21 CEST 2014


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. Especially if
the compositor wants that memory to render the frame it needs to
switch everything on again ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list