>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxx - +41 (0) 79 364 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
