From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com ([192.55.52.88]:23783 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752631AbbJMOF2 (ORCPT ); Tue, 13 Oct 2015 10:05:28 -0400 Subject: Re: [Intel-gfx] [PATCH] drm/i915: Deny wrapping an userptr into a framebuffer To: Chris Wilson , intel-gfx@lists.freedesktop.org References: <1444742546-27401-1-git-send-email-chris@chris-wilson.co.uk> <561D0E72.9060507@linux.intel.com> Cc: Daniel Vetter , stable@vger.kernel.org From: Tvrtko Ursulin Message-ID: <561D0F62.10707@linux.intel.com> Date: Tue, 13 Oct 2015 15:04:18 +0100 MIME-Version: 1.0 In-Reply-To: <561D0E72.9060507@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 13/10/15 15:00, Tvrtko Ursulin wrote: > > On 13/10/15 14:22, Chris Wilson wrote: >> Pinning a userptr onto the hardware raises interesting questions about >> the lifetime of such a surface as the framebuffer extends that life >> beyond the client's address space. That is the hardware will need to >> keep scanning out from the backing storage even after the client wants >> to remap its address space. As the hardware pins the backing storage, P.S. Or even after the client exits in the new world order! Regards, Tvrtko