[Intel-gfx] [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast

[Ankitprasad Sharma]

On Tue, 2015-11-24 at 13:22 +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2015 at 10:06:16AM +0000, Chris Wilson wrote:
> > On Fri, Nov 20, 2015 at 03:07:58PM +0530, Ankitprasad Sharma wrote:
> > > On Wed, 2015-11-18 at 10:59 +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 05, 2015 at 05:15:59PM +0530, ankitprasad.r.sharma at intel.com wrote:
> > > > > From: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
> > > > > 
> > > > > In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> > > > > we try a nonblocking pin for the whole object (since that is fastest if
> > > > > reused), then failing that we try to grab one page in the mappable
> > > > > aperture. It also allows us to handle objects larger than the mappable
> > > > > aperture (e.g. if we need to pwrite with vGPU restricting the aperture
> > > > > to a measely 8MiB or something like that).
> > > > 
> > > > We already have a fallback to the shmem pwrite. Why do we need this?
> > > This is mainly for the non-shmem backed objects, as we do not have
> > > fallback path for that. Agree for the shmem backed objects, as we
> > > already have a fallback.
> > > 
> > > Would like to request Chris, if he can clarify further.
> > 
> > Exactly that, with stolen we cannot use the shmem path so there exists
> > no fallback. In order to pwrite to stolen, the GTT path must be fully
> > capable.
> 
> Ok, in that case this should probably be part of the stolen obj series,
> just for clarification.
> -Daniel
Daniel,
I have moved this patch to the stolen memory series with the latest
version. Can we please move ahead for the review and merge of the first
2 patches?

Thanks,
Ankit