On Tue, Dec 17, 2013 at 11:42:11PM +0100, Daniel Vetter wrote:
> But only when we indeed set up a gtt mapping. We need this since the
> vma also holds a pages_pin_count, on top of the unconditional
> pages_pin_count we grab for all stolen objects (to avoid swap-out).
>
> This should avoid a pages_
On Wed, Dec 18, 2013 at 1:00 AM, Ben Widawsky
wrote:
> I'm missing why _i915_gem_object_create_stolen() isn't good enough for
> pinning the pages.
Citing my commit message "... vma also holds a pages_pin_count". Which
is on top of the general pages_pin_count we have for all stolen
objects to avoi
On Tue, Dec 17, 2013 at 11:42:11PM +0100, Daniel Vetter wrote:
> But only when we indeed set up a gtt mapping. We need this since the
> vma also holds a pages_pin_count, on top of the unconditional
> pages_pin_count we grab for all stolen objects (to avoid swap-out).
>
> This should avoid a pages_
But only when we indeed set up a gtt mapping. We need this since the
vma also holds a pages_pin_count, on top of the unconditional
pages_pin_count we grab for all stolen objects (to avoid swap-out).
This should avoid a pages_pin_count underrun when cleaning up
framebuffers objects taken over from
