kernel/include/drm/drm_gem.h, branch linux-4.14.y

drm/gem: Add drm_gem_dumb_map_offset()

2017-07-29T11:49:55Z

Add a common drm_driver.dumb_map_offset function for GEM backed drivers. Signed-off-by: Noralf Trønnes Reviewed-by: Philipp Zabel Reviewed-by: Laurent Pinchart Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/1500837417-40580-2-git-send-email-noralf@tronnes.org

drm: Remove pending_read_domains and pending_write_domain

2017-07-05T20:18:07Z

The last user of these (i915.ko) no longer does. We can slim down the core GEM object by removing the unused 8 bytes. Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170705154900.28697-1-chris@chris-wilson.co.uk

drm/gem: Add DEFINE_DRM_GEM_FOPS

2017-03-14T13:38:34Z

Sadly there's only 1 driver which can use it, everyone else is special for some reason: - gma500 has a horrible runtime PM ioctl wrapper that probably doesn't really work but meh. - i915 needs special compat_ioctl handler because regrets. - arcgpu needs to fixup the pgprot because (no idea why it can't do that in the fault handler like everyone else). - tegra does even worse stuff with pgprot - udl does something with vm_flags too ... - cma helpers, etnaviv, mtk, msm, rockchip, omap all implement some variation on prefaulting. - exynos is exynos, I got lost in the midlayers. - vc4 has to reinvent half of cma helpers because those are too much midlayer, plus vm_flags dances. - vgem also seems unhappy with the default vm_flags. So pretty sad divergence and I'm sure we could do better, but not really an idea. Oh well, maybe this macro here helps to encourage more consistency at least going forward. Reviewed-by: Sean Paul Reviewed-by: Liviu Dudau Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-25-daniel.vetter@ffwll.ch

drm: Extract drm_prime.h

2017-03-09T15:18:02Z

Plus a little bit more documentation. v2: Untangle the missing forward decls to make drm_prime|gem.h free-standing. Reviewed-by: Gustavo Padovan Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-3-daniel.vetter@ffwll.ch

drm: Introduce drm_gem_object_{get,put}()

2017-02-28T15:16:43Z

For consistency with other reference counting APIs in the kernel, add drm_gem_object_get() and drm_gem_object_put(), as well as an unlocked variant of the latter, to reference count GEM buffer objects. Compatibility aliases are added to keep existing code working. To help speed up the transition, all the instances of the old functions in the DRM core are already replaced in this commit. The existing semantic patch for the DRM subsystem-wide conversion is extended to account for these new helpers. Reviewed-by: Sean Paul Acked-by: Christian König Signed-off-by: Thierry Reding Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-6-thierry.reding@gmail.com

drm/gem|prime|mm: Use recommened kerneldoc for struct member refs

2017-01-25T15:20:21Z

I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Jani Nikula Cc: Chris Wilson Reviewed-by: Gustavo Padovan Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-5-daniel.vetter@ffwll.ch

drm/doc: Fix more kerneldoc/sphinx warnings

2016-08-16T14:09:58Z

These are the leftovers I could only track down using keep_warnings = True. For some of them we might want to update our style guide on how to reference structures and constants, not sure ... Cc: Markus Heiser Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-1-git-send-email-daniel.vetter@ffwll.ch

drm: Remove unused drm_device from drm_gem_object_lookup()

2016-05-17T06:47:30Z

drm_gem_object_lookup() has never required the drm_device for its file local translation of the user handle to the GEM object. Let's remove the unused parameter and save some space. Signed-off-by: Chris Wilson Cc: dri-devel@lists.freedesktop.org Cc: Dave Airlie Cc: Daniel Vetter [danvet: Fixup kerneldoc too.] Signed-off-by: Daniel Vetter

drm/gem: support BO freeing without dev->struct_mutex

2016-05-04T10:25:47Z

Finally all the core gem and a lot of drivers are entirely free of dev->struct_mutex depencies, and we can start to have an entirely lockless unref path. To make sure that no one who touches the core code accidentally breaks existing drivers which still require dev->struct_mutex I've made the might_lock check unconditional. While at it de-inline the ref/unref functions, they've become a bit too big. v2: Make it not leak like a sieve. v3: Review from Lucas: - drop != NULL in pointer checks. - fixup copypasted kerneldoc to actually match the functions. v4: Add __drm_gem_object_unreference as a fastpath helper for drivers who abolished dev->struct_mutex, requested by Chris. v5: Fix silly mistake in drm_gem_object_unreference_unlocked caught by intel-gfx CI - I checked for gem_free_object instead of gem_free_object_unlocked ... Cc: Chris Wilson Cc: Alex Deucher Cc: Lucas Stach Reviewed-by: Lucas Stach (v3) Reviewed-by: Chris Wilson (v4) Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1462178451-1765-1-git-send-email-daniel.vetter@ffwll.ch

drm: Update GEM refcounting docs

2015-11-24T10:41:49Z

I just realized that I've forgotten to update all the gem refcounting docs. For pennance also add pretty docs for the overall drm_gem_object structure, with a few links thrown in fore good. As usually we need to make sure the kerneldoc reference is at most a sect2 for otherwise it won't be listed. Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1445533889-7661-1-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter