On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark robdclark@gmail.com wrote:
On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson chris@chris-wilson.co.uk wrote:
On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark rob@ti.com wrote:
In the process of adding GEM support for OMAP DRM driver, I noticed that I was adding code for creating/freeing mmap offsets which was virtually identical to what was already duplicated in i915 and gma500 drivers.
Rather than duplicating the code a 3rd time, it seemed like a good idea to move it to the GEM core.
Note that I don't actually have a way to test psb or i915, but the changes seem straightforward enough.
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.
I admit I've not got quite as far as dealing with this yet.. I'm just starting on the dri2 part in xorg driver. (Previous pvr xorg driver has some non-GEM way of sharing buffers.) So I'm figuring out some of this stuff as I go.
For me I think it isn't the end of the world to have same offset in all processes, although I'm interested if there is a better way. There is just one 'struct drm_local_map' in 'struct drm_gem_object', so I admit that I'm not quite sure how this was intended to work.
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).
BR, -R