[PATCH 00/20] prime/flink fixes and related stuff

Daniel Vetter daniel.vetter at ffwll.ch
Sun Aug 4 10:41:37 PDT 2013


On Sat, Jul 27, 2013 at 11:22 AM, Inki Dae <inki.dae at samsung.com> wrote:
>
> 2013/7/16 Daniel Vetter <daniel.vetter at ffwll.ch>
>>
>> Hi all,
>>
>> This patch series is my 2nd real stab at fixing up the locking issues
>> around our
>> two buffer sharing mechanisms in gem: flink and prime.
>>
>> I think the approach taken here is much better than my first stab, and it
>> also
>> seems to no longer leak buffers ;-) There some assorted cleanup and prep
>> work
>> (and one i915 fix) thrown into the mix, it's all stuff I've stumbled over
>> while
>> digging through the code.
>>
>> Open issues left in prime-land after these patches:
>> - exynos probably wants a similar patch to "drm/i915: explicit store base
>> gem
>>   object in dma_buf->priv". The current code should be correct, but it's a
>> bit
>
>
> How about using stuffs of drm_prime instead of specific ones? Seem like that
> we could replace specific dmabuf stuffs with common ones of drm_prime, at
> least in case of Exynos: i.e. each driver can export a gem to a dmabuf
> through drm_gem_prime_export function of drm_prime instead of specific one.
> By doing so, I think we could remove duplicated codes of drivers, specific
> dmabuf stuffs. I'm not sure but it seems like that there is any reason you
> try to use existing stuffs with a little change: maybe the stuffs of
> drm_prime couldn't be used for all drm drivers commonly.

I have to admit that I didn't really understand your email, mostly
since you talk about "stuff" and "stuffs" and I didn't really grok
which piece of code you actually mean. Can you pls elaborate, maybe
taking the functions for exynos as an example?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list