Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
sed -i "s/$__from/$__to/g" $__file;
done
Pay special attention to the compat #define
v2: keep sed and #define removal separate
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Sam Ravnborg <[email protected]> (v1)
Reviewed-by: Steven Price <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Add helper, which will allow us to transition the drivers one by one,
dropping the suffix.
v2: add missing space after function name (Jani)
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Sam Ravnborg <[email protected]> (v1)
Reviewed-by: Steven Price <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The fake offset is going to stay, so change the calling convention for
drm_gem_object_funcs.mmap to include the fake offset. Update all users
accordingly.
Note that this reverts 83b8a6f242 ("drm/gem: Fix mmap fake offset
handling for drm_gem_object_funcs.mmap") and on top then adds the fake
offset to drm_gem_prime_mmap to make sure all paths leading to
obj->funcs->mmap are consistent.
v3: move fake-offset tweak in drm_gem_prime_mmap() so we have this code
only once in the function (Rob Herring).
Fixes: 83b8a6f242 ("drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap")
Cc: Daniel Vetter <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit c40069cb7b ("drm: add mmap() to drm_gem_object_funcs")
introduced a GEM object mmap() hook which is expected to subtract the
fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
a fake offset.
To fix this, let's always call mmap() object callback with an offset of 0,
and leave it up to drm_gem_mmap_obj() to remove the fake offset.
TTM still needs the fake offset, so we have to add it back until that's
fixed.
Fixes: c40069cb7b ("drm: add mmap() to drm_gem_object_funcs")
Cc: Gerd Hoffmann <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Acked-by: Gerd Hoffmann <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
drm_gem_object_funcs->vm_ops alone can't handle everything which needs
to be done for mmap(), tweaking vm_flags for example. So add a new
mmap() callback to drm_gem_object_funcs where this code can go to.
Note that the vm_ops field is not used in case the mmap callback is
present, it is expected that the callback sets vma->vm_ops instead.
Also setting vm_flags and vm_page_prot is the job of the new callback.
so drivers have more control over these flags.
drm_gem_mmap_obj() will use the new callback for object specific mmap
setup. With this in place the need for driver-speific fops->mmap
callbacks goes away, drm_gem_mmap can be hooked instead.
drm_gem_prime_mmap() will use the new callback too to just mmap gem
objects directly instead of jumping though loops to make
drm_gem_object_lookup() and fops->mmap work.
Signed-off-by: Gerd Hoffmann <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
This reverts commit 220df83a53.
Turns out drm_gem_dumb_map_offset really only worked for the dumb buffer
case, so revert the name change.
Signed-off-by: Rob Herring <[email protected]>
Yes this is a bit a big patch, but since it's essentially a complete
rewrite of all the prime docs I didn't see how to better split it up.
Changes:
- Consistently point to drm_gem_object_funcs as the preferred hooks,
where applicable.
- Document all the hooks in &drm_driver that lacked kerneldoc.
- Completely new overview section, which now also includes the cleaned
up lifetime/reference counting subchapter. I also mentioned the weak
references in there due to the lookup caches.
- Completely rewritten helper intro section, highlight the
import/export related functionality.
- Polish for all the functions and more cross references.
I also sprinkled a bunch of todos all over.
Most important: 0 code changes in here. The cleanup motivated by
reading and improving all this will follow later on.
v2: Actually update the prime helper docs. Plus add a few FIXMEs that
I won't address right away in subsequent cleanup patches.
v3:
- Split out the function moving. This patch is now exclusively
documentation changes.
- Typos and nits (Sam).
v4: Polish suggestions from Noralf.
Acked-by: Gerd Hoffmann <[email protected]>
Acked-by: Emil Velikov <[email protected]>
Acked-by: Noralf Trønnes <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Gerd Hoffmann <[email protected]>
Cc: Noralf Trønnes <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Eric Anholt <[email protected]>
Cc: Emil Velikov <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-and-tested-by: Qiang Yu <[email protected]> (v1)
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 <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Acked-by: Rob Herring <[email protected]> (v1)
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 <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Acked-by: Christian König <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Chris Wilson <[email protected]>
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 <[email protected]>
Reviewed-by: Liviu Dudau <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Acked-by: Christian König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Cc: Chris Wilson <[email protected]>
Reviewed-by: Gustavo Padovan <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Cc: [email protected]
Cc: Dave Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
[danvet: Fixup kerneldoc too.]
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Lucas Stach <[email protected]>
Reviewed-by: Lucas Stach <[email protected]> (v3)
Reviewed-by: Chris Wilson <[email protected]> (v4)
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Pretty soon only some drivers will need dev->struct_mutex in their
gem_free_object callbacks. Hence it's really important to make sure
everything still keeps getting this right.
v2: Don't check for locking before we check for non-NULL obj. Spotted
by Dan Carpenter.
Link: http://mid.gmane.org/[email protected]
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
If kref_put_mutex returns true then the caller or the put function is responsible
for unlocking the mutex. The usual pattern assumes that the free
callback unlocks the mutex, but since that is shared with the locked
variant we need to explicitly unlock here.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
This reverts commit 355a701838.
This had some bad side effects under normal operation, and should
have been dropped earlier.
Signed-off-by: Dave Airlie <[email protected]>
It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.
This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.
v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage.
Signed-off-by: Thomas Hellstrom <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Randy Dunlap