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

drm: Add helpers for setting up an array of dma_fence dependencies.

2019-04-16T22:32:20Z

I needed to add implicit dependency support for v3d, and Rob Herring has been working on it for panfrost, and I had recently looked at the lima implementation so I think this will be a good intersection of what we all want and simplify our scheduler implementations. v2: Rebase on xa_limit_32b API change, and tiny checkpatch cleanups on the way in (unsigned int vs unsigned, extra return before EXPORT_SYMBOL_GPL) Signed-off-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20190401222635.25013-6-eric@anholt.net Reviewed-and-tested-by: Qiang Yu (v1)

drm: Add a drm_gem_objects_lookup helper

2019-04-12T17:53:58Z

Similar to the single handle drm_gem_object_lookup(), drm_gem_objects_lookup() takes an array of handles and returns an array of GEM objects. v2: - Take the userspace pointer directly and allocate the array. - Expand the function documentation. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Acked-by: Alyssa Rosenzweig Acked-by: Tomeu Vizoso Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20190409205427.6943-3-robh@kernel.org

drm: Add helpers for locking an array of BO reservations.

2019-03-14T16:22:57Z

Now that we have the reservation object in the GEM object, it's easy to provide a helper for this common case. Noticed while reviewing panfrost and lima drivers. This particular version came out of v3d, which in turn was a copy from vc4. v2: Fix kerneldoc warnings. Signed-off-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20190308161716.2466-2-eric@anholt.net Acked-by: Rob Herring (v1)

drm: Add reservation_object to drm_gem_object

2019-02-19T10:08:40Z

Many users of drm_gem_object embed a struct reservation_object into their subclassed struct, so let's add one to struct drm_gem_object. This will allow removing the reservation object from the subclasses and removing the ->gem_prime_res_obj callback. With the addition, add a drm_gem_reservation_object_wait() helper function for drivers to use in wait ioctls. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Rob Herring Acked-by: Daniel Vetter Reviewed-by: Eric Anholt Reviewed-by: Christian Gmeiner Link: https://patchwork.freedesktop.org/patch/msgid/20190202154158.10443-2-robh@kernel.org Signed-off-by: Maxime Ripard

drm: remove deprecated "[__]drm_gem_object_[un]reference[_locked]" functions

2018-11-24T21:12:54Z

There are no more places where these (deprecated) functions are being used from, thus they can now be removed. Signed-off-by: Fernando Ramos Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-3-greenfoo@gluegarage.com

drm/gem: Add drm_gem_object_funcs

2018-11-20T13:56:18Z

This adds an optional function table on GEM objects. The main benefit is for drivers that support more than one type of memory (shmem,vram,cma) for their buffers depending on the hardware it runs on. With the callbacks attached to the GEM object itself, it is easier to have core helpers for the the various buffer types. The driver only has to make the decision about buffer type on GEM object creation and all other callbacks can be handled by the chosen helper. drm_driver->gem_prime_res_obj has not been added since there's a todo to put a reservation_object into drm_gem_object. v3: Add todo entry v2: Drop drm_gem_object_funcs->prime_mmap in favour of drm_gem_prime_mmap() (Daniel Vetter) v1: - drm_gem_object_funcs.map -> .prime_map let it only do PRIME mmap like the function it superseeds (Daniel Vetter) - Flip around the if ladders and make obj->funcs the first choice highlighting the fact that this the new default way of doing it (Daniel Vetter) Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter Acked-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-4-noralf@tronnes.org

drm: move read_domains and write_domain into i915

2018-02-16T14:12:48Z

i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all other drivers. Move the fields into drm_i915_gem_object instead and patch the i915 code with the following sed commands: sed -i "s/obj->base.read_domains/obj->read_domains/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c sed -i "s/obj->base.write_domain/obj->write_domain/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c Change is only compile tested. v2: move fields around as suggested by Chris. Signed-off-by: Christian König Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20180216124338.9087-1-christian.koenig@amd.com Signed-off-by: Chris Wilson

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