| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Part of the function uses the properly-typed dmabuf variable, the
other an untyped void *buf. Kill the later.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
No one outside of drm should use this, the official interfaces are
drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
is purely an implementation detail of gem.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
handle_unreference only clears up the obj->name and the reference,
but would leave a dangling handle in the idr. The right thing
to do is to call handle_delete.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Cc: Inki Dae <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:
New pile of stuff for -next:
- Cleanup of the old crtc helper callbacks, all encoders are now converted
to the i915 modeset infrastructure.
- Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is
prep work to eventually get things going for nuclear pageflips where we
need to adjust watermarks on the fly.
- More vm/vma patches from Ben. This refactoring isn't yet fully rolled
out, we miss the execbuf conversion and some of the low-level
bind/unbind support code.
- Convert our hdmi infoframe code to use the new common helper functions
(Damien). This contains some bugfixes for the common infoframe helpers.
- Some cruft removal from Damien.
- Various smaller bits&pieces all over, as usual.
* tag 'drm-intel-next-2013-08-09' of git://people.freedesktop.org/~danvet/drm-intel: (105 commits)
drm/i915: Fix FB WM for HSW
drm/i915: expose HDMI connectors on port C on BYT
drm/i915: fix a limit check in hsw_compute_wm_results()
drm/i915: unbreak i915_gem_object_ggtt_unbind()
drm/i915: Make intel_set_mode() static
drm/i915: Remove intel_modeset_disable()
drm/i915: Make intel_encoder_dpms() static
drm/i915: Make i915_hangcheck_elapsed() static
drm/i915: Fix #endif comment
drm/i915: Remove i915_gem_object_check_coherency()
drm/i915: Remove stale prototypes
drm/i915: List objects allocated from stolen memory in debugfs
drm/i915: Always call intel_update_sprite_watermarks() when disabling a plane
drm/i915: Pass plane and crtc to intel_update_sprite_watermarks
drm/i915: Don't try to disable plane if it's already disabled
drm/i915: Pass crtc to our update/disable_plane hooks
drm/i915: Split plane watermark parameters into a separate struct
drm/i915: Pull some watermarks state into a separate structure
drm/i915: Calculate max watermark levels for ILK+
drm/i915: Rename hsw_lp_wm_result to intel_wm_level
...
|
|
It's only used in drm_platform.c.
Signed-off-by: Damien Lespiau <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This function is only used in drm_fb_cma_helper.c.
Signed-off-by: Damien Lespiau <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
It's only used in drm_crtc.c.
Signed-off-by: Damien Lespiau <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The last user was removed in
commit 575dc34ee0de867ba83abf25998e0963bff451fa
Author: Dave Airlie <[email protected]>
Date: Mon Sep 7 18:43:26 2009 +1000
drm/kms: remove old std mode fallback code.
The new code adds modes in the helper, which makes more sense
I disliked the non-driver code adding modes.
Signed-off-by: Damien Lespiau <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This was last used by nouveau, replaced by a driver-specific property
in:
commit de69185573586302ada2e59ba41835df36986277
Author: Ben Skeggs <[email protected]>
Date: Mon Oct 17 12:23:41 2011 +1000
drm/nouveau: improve dithering properties, and implement proper auto mode
Signed-off-by: Damien Lespiau <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced
error which cause that reclocking on nv40 not working anymore.
There is missing assigment of return value from pll_calc to ret.
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Martin Peres <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Allocating type=0 marks the memory as free. This allows the ltcg memory
to be allocated twice.
Add a BUG_ON in core/mm.c to prevent this ever happening again.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Some registers were not initialized in init, this causes them to be
uninitialized after suspend.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Commit dceef5d87 (drm/nouveau/fb: initialise vram controller as pfb
sub-object) moved some code around and introduced these null derefs.
pfb->ram is set to the new ram object outside of this ctor.
Reported-by: Ronald Uitermark <[email protected]>
Tested-by: Ronald Uitermark <[email protected]>
Signed-off-by: Ilia Mirkin <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Michael Witten <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
|
|
We kzalloc this structure, and for real kms devices we should never
loose track of things really.
But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
conditionalize the code on !DRIVER_MODESET.
Cc: David Herrmann <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging it turned out that the drmstat tool in libdrm is still using
those files (but only when certain options are set). So we've decided
to keep profcs.
But I when I've started to dig around again what exactly this tool
does I've noticed that it tries to read the "mem", "vm", and "vma"
files from procfs. Now as far my git history digging shows "mem" never
did anything useful (at least in the version that first showed up in
upstream history in 2004) and the file was remove in
commit 955b12def42e83287c1bdb1411d99451753c1391
Author: Ben Gamari <[email protected]>
Date: Tue Feb 17 20:08:49 2009 -0500
drm: Convert proc files to seq_file and introduce debugfs
Which means that for over 4 years drmstat has been broken, and no one
cared. In my opinion that's proof enough that no one is actually using
drmstat, and so that we can savely nuke the procfs support from drm.
While at it fix up the error case cleanup for debugfs in drm_get_minor.
v2: Fix dates, libdrm stopped relying on procfs for drm node detection
in 2001.
v3: fixup compilation warning for !CONFIG_DEBUG_FS, reported by
Fengguang Wu.
Cc: kbuild test robot <[email protected]>
Cc: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.
v2: Don't forget to update DocBook.
v3: Go with Laurent's slightly more elaborate proposal for the DocBook
update. Add a few words on top of his diff to elaborate a bit on what
KMS drivers should and shouldn't do in lastclose. There was already a
paragraph present talking about restoring properties, I've simply
extended that one.
Cc: Laurent Pinchart <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)
In short besides the semantically important vga switcheroo stuff they
all try very hard to keep fbcon working in case X dies.
But none of them try to not do this at driver unload time safe for
vmwgfx, and digging through logs I couldn't find any reason for why
vmwgfx is special.
Since ->firstopen has lots of potential for abuse with kms drivers
(like delaying driver setup to pamper over races in the load sequence)
it's imo very much worth it to remove this logic so that we can
stop using the ->firstopen callback for kms drivers.
Also module unloading is rather a debug feature and developers should
know how to restore the display to a sane configuration.
Cc: Jakob Bornecrantz <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Currently, both ranges overlap. Fix the limits so both ranges are mutually
exclusive. Also use the occasion to convert whitespaces to tabs.
Signed-off-by: Kristian Høgsberg <[email protected]>
(fixed up tabs and adjust commit-msg accordingly)
Signed-off-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitly check for that in the new ioctl implementation.
v2: Drop the unused variable I've accidentally left in the code,
spotted by David Herrmann.
Cc: David Herrmann <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected drivers. David helped a lot in that. Quoting our mail
discussion:
On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann <[email protected]> wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter <[email protected]> wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann <[email protected]> wrote:
>>>> -#if __OS_HAS_MTRR
>>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>>>> -{
>>>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>>>> -}
>>>> -#else
>>>> -#define drm_core_has_MTRR(dev) (0)
>>>> -#endif
>>>> -
>>>
>>> That was the last user of DRIVER_USE_MTRR (apart from drivers setting
>>> it in .driver_features). Any reason to keep it around?
>>
>> Yeah, I guess we could rip things out. Which will also force me to
>> properly audit drivers for the eventual behaviour change this could
>> entail (in case there's an x86 driver which did not ask for an mtrr,
>> but iirc there isn't).
>
> david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
> test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
> fi ; done
> drivers/gpu/drm/exynos
> drivers/gpu/drm/gma500
> drivers/gpu/drm/i2c
> drivers/gpu/drm/nouveau
> drivers/gpu/drm/omapdrm
> drivers/gpu/drm/qxl
> drivers/gpu/drm/rcar-du
> drivers/gpu/drm/shmobile
> drivers/gpu/drm/tilcdc
> drivers/gpu/drm/ttm
> drivers/gpu/drm/udl
> drivers/gpu/drm/vmwgfx
> david@david-mb ~/dev/kernel/linux $
>
> So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
> But I cannot tell whether they break if we call arch_phys_wc_add/del,
> anyway. At least nouveau seemed to work here, but it doesn't use AGP
> or drm_bufs, I guess.
Cool, thanks a lot for stitching together the list of drivers to look
at. So for real KMS drivers it's the drives responsibility to add an
mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
already. Somehow the savage driver also ends up doing that, I have no
idea why.
Note that gma500 as a pure KMS driver doesn't need MTRR setup since
the platforms that it supports all support PAT. So no MTRRs needed to
get wc iomappings.
The mtrr support in the drm core is all for legacy mappings of garts,
framebuffers and registers. All legacy drivers set the USE_MTRR flag,
so we're good there.
All in all I think we can really just ditch this
/endquote
v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann
v3: Rebase on top of David Herrmann's agp setup/cleanup changes.
Cc: David Herrmann <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Acked-by: Andy Lutomirski <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
git://people.freedesktop.org/~danvet/drm-intel
* tag 'drm-intel-fixes-2013-08-15' of git://people.freedesktop.org/~danvet/drm-intel: (153 commits)
drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code
|
|
This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.
v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev->struct_mutex held that won't
result in an immediate deadlock since we never go through the dma_buf
interfaces for our own, reimported buffers. But it's still easy to
blow up and anger lockdep, but that's already the case with our ->map
implementation. Fixing this for real will involve per dma-buf ww mutex
locking by the callers. And lots of fun. So go with the duct-tape
approach for now.
Cc: Chris Wilson <[email protected]>
Reported-by: Maarten Lankhorst <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Tested-by: Armin K. <[email protected]> (v1)
Tested-by: Dave Airlie <[email protected]>
Acked-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Trying to drop a reference we don't have is a pretty serious bug.
Trying to paper over it is an even worse offense.
So scream into dmesg with a big WARN in case that ever happens.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Calling this function with a NULL object is simply a bug, so papering
over a NULL object not a good idea.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.
Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static (and remove the unused EXPORT_SYMBOL). To
avoid a forward declaration move it (and drm_gem_object_free_bug) up a
bit.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we need to
be concerned about, and either those pages are pinned independently,
or we're screwed no matter what.
And indeed, nouveau/radeon pin the backing storage in their
attach/detach functions.
Since I've created this patch cma prime support for dma_buf was added.
drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates&maps
the sg table with dma_get_sgtable. It doesn't touch any gem object
state otherwise. So the cma helpers also look safe.
The only thing we might claim it does is prevent concurrent mapping of
dma_buf attachments. But a) that's not allowed and b) the current code
is racy already since it checks whether the sg mapping exists _before_
grabbing the lock.
So the dev->struct_mutex locking here does absolutely nothing useful,
but only distracts. Remove it.
This should also help Maarten's work to eventually pin the backing
storage more dynamically by preventing locking inversions around
dev->struct_mutex.
v2: Add analysis for recently added cma helper prime code.
Cc: Laurent Pinchart <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Acked-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Inki Dae <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.
To use the release helper we need to export it, too.
Cc: Inki Dae <[email protected]>
Cc: Intel Graphics Development <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Basically just extracting some code duplicated in gma500, omapdrm, udl,
and upcoming msm driver.
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Variant of drm_gem_create_mmap_offset() which doesn't make the
assumption that virtual size and physical size (obj->size) are the same.
This is needed in omapdrm to deal with tiled buffers. And lets us get
rid of a duplicated and slightly modified version of
drm_gem_create_mmap_offset() in omapdrm.
Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
And simplify how we hold a ref+pin to what is being scanned out by using
fb refcnt'ing. The previous logic pre-dated fb refcnt, and as a result
was less straightforward than it could have been. By holding a ref to
the fb, we don't have to care about how many plane's there are and
holding a ref to each color plane's bo.
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Rob Clark <[email protected]>
Tested-by: Darren Etheridge <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
A small helper to queue up work to do, from workqueue context, after a
flip. Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.
v1: original
v2: wire up docbook + couple docbook fixes
Signed-off-by: Rob Clark <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This function is unused.
Signed-off-by: Stéphane Marchesin <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.
So I don't see any use for this stat gathering complexity at all.
To be able to gradually drop things start with ripping out the
interfaces to it, here the ioctl.
To prevent dristat from eating its own stack garbage we can't use the
drm_noop ioctl though, since we need to clear the return data with a
memset.
Cc: Eric Anholt <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.
I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tests/dristat.c and drm/tests/getclients.c. The later
is a testcase for the ioctl itself since up to
commit b018fcdaa5e8b4eabb8cffda687d00004a3c4785
Author: Eric Anholt <[email protected]>
Date: Thu Nov 22 18:46:54 2007 +1000
drm: Make DRM_IOCTL_GET_CLIENT return EINVAL when it can't find client #idx
there was actually no way at all for userspace to enumerate all
clients since the kernel just wouldn't tell it when to stop. Which
completely broke it's only user, dristat -c.
So obviously that ioctl wasn't much use for debugging. Hence I don't
see any point in keeping support for a tool which was pretty obviously
never really used, and while we have good replacements in the form of
equivalent debugfs files.
Still, to keep dristat -c from looping forever again stop it early by
returning an unconditional -EINVAL. Also add a comment in the code
about why.
v2: Slightly less hollowed-out implementation. libva uses GET_CLIENTS
to figure out whether the fd it has is already authenticated or not.
So we need to keep that part of things working. Simplest way is to
just return one entry to keep va_drm_is_authenticated in
libva/va/drm/va_drm_auth.c working.
This is exercised by igt/drm_get_client_auth which contains a
copypasta of the libva auth check code.
Cc: Gwenole Beauchesne <[email protected]>
Cc: David Herrmann <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.
I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that upper-case P sometimes ;-) But that's all stuff for future patch
bombs.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
No driver ever sets that flag, so good riddance!
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.
No merged drm driver has ever done that.
After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:
commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie <[email protected]>
Date: Sun Aug 29 12:04:35 2004 +0000
Drop GAMMA DRM from a great height ...
Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.
So stop this particular cargo-cult and rip it all out.
v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.
v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.
v4: Actually git add ... tsk.
Cc: Dave Airlie <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Rob Clark <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
It's kzalloced ...
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|