[PATCH 0/3] RFC: Common functions for GEM offset creation

[Daniel Vetter]

>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>>> My only concern is that for the common functions the mmap_offset to create
>>> should be passed in a parameter, so that we could support more than one
>>> mapping for an object.

[ snip ]

> On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark <robdclark at gmail.com> wrote:
> Chris, any suggestions?  I still haven't found a good excuse for
> offsets to be per-process.
>
> I'm just wondering if I should go ahead and send a non-RFC version of
> the patches.  I guess in the end it is not userspace visible so
> completely possible to change later.  But it seems these util fxns
> should also be useful to a handful of other upcoming SoC DRM drivers
> (such as the Samsung one that was recently posted).

Imo you're patches looks nice and should go in as is. Fixing the mmap
handling of gem objects for real looks like more work: For the second
cpu-coherent mapping of i915 gem objects (as opposed to the gpu
coherent mapping using the mmap_offset infrastructure) we directly
create a vma for the underlying shmfs node in a hand-rolled mmap ioctl
(using do_mmap), the core drm mmap handling is layered with a bit of
historical cruft of it's own and ttm seems to do a bit of reinventing
the wheel. So imo this needs some more cleanup to be nice and
beautiful than just adding an additional argument. It's somewhere on
one of my todo list ... ;-)

Cheers, Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch