Re: [Intel-gfx] [PATCH 0/4] Compact userptr object backing store allocation

[Tvrtko Ursulin]

On 14/11/2016 11:45, Tvrtko Ursulin wrote:
> Hi Andrew,
>
> On 11/11/2016 08:50, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> >
> > Userptr backing store with SWIOTBL active is currently allocated in
> > the same
> > inefficient manner, with one sg entry per object page, as what the commit
> > 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment
> > size") fixed
> > for regular GEM objects.
> >
> > We can fix that by adding new a __sg_alloc_table_from_pages core
> > function which
> > allows us to control the maximum desired coalesced segment size.
> >
> > Other than that the series starts with two simple fixes to
> > sg_alloc_table_from_pages which deal with incorrect data type usage and a
> > theoretical overflow condition. Fixing the latter enables easy
> > addition of the
> > above mentioned __sg_alloc_table_from_pages.
> >
> > Tvrtko Ursulin (4):
> >   lib/scatterlist: Fix offset type in sg_alloc_table_from_pages
> >   lib/scatterlist: Avoid potential scatterlist entry overflow
> >   lib/scatterlist: Introduce and export __sg_alloc_table_from_pages
> >   drm/i915: Use __sg_alloc_table_from_pages for userptr allocations
> >
> >  drivers/gpu/drm/i915/i915_drv.h                |  9 +++
> >  drivers/gpu/drm/i915/i915_gem.c                | 15 +----
> >  drivers/gpu/drm/i915/i915_gem_userptr.c        | 28 ++-------
> >  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 +-
> >  drivers/rapidio/devices/rio_mport_cdev.c       |  4 +-
> >  include/linux/scatterlist.h                    | 11 ++--
> >  lib/scatterlist.c                              | 78
> > ++++++++++++++++++++------
> >  7 files changed, 87 insertions(+), 62 deletions(-)
>
> I have three patches to lib/scatterlist.c in this series which has all
> been reviewed and tested.
>
> We would like to merge them via the DRM tree if there are no objections?

Excuse me for the re-ping - still looking for an ack to merge these few 
patches via the drm tree. (The code in question does not have a 
designated maintainer.)

Regards,

Tvrtko