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

[Rob Clark]

On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark <rob at 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