On Tue, Nov 15, 2016 at 08:58:15AM +, Chris Wilson wrote:
> @@ -12340,7 +12325,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
> cleanup_request:
> i915_add_request_no_flush(request);
> cleanup_unpin:
> - intel_unpin_fb_obj(fb, crtc->primary->state->rotation);
> + to
On Tue, Nov 15, 2016 at 10:02:23AM +, Chris Wilson wrote:
> On Tue, Nov 15, 2016 at 10:52:00AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 08:58:15AM +, Chris Wilson wrote:
> > > With atomic plane states we are able to track an allocation right from
> > > preparation, during use
On Tue, Nov 15, 2016 at 10:52:00AM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 08:58:15AM +, Chris Wilson wrote:
> > With atomic plane states we are able to track an allocation right from
> > preparation, during use and through to the final free after being
> > swapped out for a new p
On Tue, Nov 15, 2016 at 08:58:15AM +, Chris Wilson wrote:
> With atomic plane states we are able to track an allocation right from
> preparation, during use and through to the final free after being
> swapped out for a new plane. We can couple the VMA we pin for the
> framebuffer (and its rotat
With atomic plane states we are able to track an allocation right from
preparation, during use and through to the final free after being
swapped out for a new plane. We can couple the VMA we pin for the
framebuffer (and its rotation) to this lifetime and avoid all the clumsy
lookups in between.
Si
With atomic plane states we are able to track an allocation right from
preparation, during use and through to the final free after being
swapped out for a new plane. We can couple the VMA we pin for the
framebuffer (and its rotation) to this lifetime and avoid all the clumsy
lookups in between.
Si
