linux-toradex.git/drivers/gpu/drm/drm_info.c, branch v3.17-rc5

drm: remove unused "struct drm_freelist"

2014-08-01T20:43:10+00:00

This object is not used except for static fields in drm_bufs *cough*.
Inline the watermark fields and drop the unused structure definition.

Signed-off-by: David Herrmann 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: remove drm_bus->get_name

2014-04-23T08:32:53+00:00

The only user is the info debugfs file, so we only need something
human readable. Now for both pci and platform devices we've used the
name of the underlying device driver, which matches the name of the
drm driver in all cases. So we can just use that instead.

The exception is usb, which used a generic "USB". Not to harmful with
just one usb driver, but better to use "udl", too.

With that converted we can rip out all the ->get_name implementations.

Reviewed-by: Thierry Reding 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter

drm: remove dev->vma_count

2013-12-18T01:43:29+00:00

This is just used for a debugfs file, and we can easily reconstruct
this number by just walking the list twice. Which isn't really bad for
a debugfs file anyway.

So let's rip this out.

There's the other issue that the dev->vmalist itself is a bit useless,
since that can be reconstructed with all the memory mapping
information from proc. But remove that is a different topic entirely.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: Kill file_priv->ioctl_count tracking

2013-12-18T01:42:13+00:00

It's racy, and it's only used in debugfs. There are simpler ways to
know whether something is going on (like looking at dmesg with full
debugging enabled). And they're all much more useful.

So let's just rip this out.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: Collect per-crtc vblank stuff to a struct

2013-10-09T05:55:31+00:00

drm_vblank_init() is too ugly. Make it a bit easier on the eye by
collecting all the per-crtc vblank counters, timestamps etc. to
a structure and just allocate an array of those.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie

drm/gem: switch dev->object_name_lock to a mutex

2013-08-21T02:58:01+00:00

I want to wrap the creation of a dma-buf from a gem object in it,
so that the obj->export_dma_buf cache can be atomically filled in.

Instead of creating a new mutex just for that variable I've figured
I can reuse the existing dev->object_name_lock, especially since
the new semantics will exactly mirror the flink obj->name already
protected by that lock.

v2: idr_preload/idr_preload_end is now an atomic section, so need to
move the mutex locking outside.

[airlied: fix up conflict with patch to make debugfs use lock]

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm/gem: fix up flink name create race

2013-08-21T02:53:45+00:00

This is the 2nd attempt, I've always been a bit dissatisified with the
tricky nature of the first one:

http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html

The issue is that the flink ioctl can race with calling gem_close on
the last gem handle. In that case we'll end up with a zero handle
count, but an flink name (and it's corresponding reference). Which
results in a neat space leak.

In my first attempt I've solved this by rechecking the handle count.
But fundamentally the issue is that ->handle_count isn't your usual
refcount - it can be resurrected from 0 among other things.

For those special beasts atomic_t often suggest way more ordering that
it actually guarantees. To prevent being tricked by those hairy
semantics take the easy way out and simply protect the handle with the
existing dev->object_name_lock.

With that change implemented it's dead easy to fix the flink vs. gem
close reace: When we try to create the name we simply have to check
whether there's still officially a gem handle around and if not refuse
to create the flink name. Since the handle count decrement and flink
name destruction is now also protected by that lock the reace is gone
and we can't ever leak the flink reference again.

Outside of the drm core only the exynos driver looks at the handle
count, and tbh I have no idea why (it's just for debug dmesg output
luckily).

I've considered inlining the drm_gem_object_handle_free, but I plan to
add more name-like things (like the exported dma_buf) to this scheme,
so it's clearer to leave the handle freeing in its own function.

This is exercised by the new gem_flink_race i-g-t testcase, which on
my snb leaks gem objects at a rate of roughly 1k objects/s.

v2: Fix up the error path handling in handle_create and make it more
robust by simply calling object_handle_unreference.

v3: Fix up the handle_unreference logic bug - atomic_dec_and_test
retursn 1 for 0. Oops.

v4: Squash in inlining of drm_gem_object_handle_reference as suggested
by Dave Airlie and add a note that we now have a testcase.

Cc: Dave Airlie 
Cc: Inki Dae 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: fix locking in gem debugfs/procfs file

2013-08-19T04:16:47+00:00

The idr is protected with our spinlock, if we don't hold that nothing
prevents the gem objects from disappearing from under us.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm/debugfs: remove redundant info from gem_names

2012-10-23T00:15:04+00:00

It's a relic of "drm: Convert proc files to seq_file and introduce debugfs",
which wrongly converted DRM_INFO + sprintf to 2 seq_printfs.

Signed-off-by: Marcin Slusarz 
Cc: Ben Gamari 
Cc: Eric Anholt 
Signed-off-by: Dave Airlie

drm: fix warning on 32-bit.

2012-10-16T00:28:21+00:00

This cast was causing a warning on 32-bit builds.

Signed-off-by: Dave Airlie