On Tue, Aug 12, 2014 at 10:30 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote: >> > 2014-08-12 16:28 GMT-03:00 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>: >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html