| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jerome Glisse <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Inki Dae <[email protected]>
Cc: Ben Skeggs <[email protected]>
Cc: Patrik Jakobsson <[email protected]>
Signed-off-by: David Herrmann <[email protected]>
Acked-by: Alex Deucher <[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]>
|
|
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Acked-by: Inki Dae <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Cc: Intel Graphics Development <[email protected]>
Cc: Ben Skeggs <[email protected]>
Reviwed-by: Rob Clark <[email protected]>
Cc: Alex Deucher <[email protected]>
Acked-by: Patrik Jakobsson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: David Howells <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Acked-by: Dave Jones <[email protected]>
|
|
Most of the DRM drivers appear to be missing the .compat_ioctl file
operation entry necessary for 32-bit application compatibility.
This patch uses drm_compat_ioctl for all drivers which don't have
their own, and which are using drm_ioctl for .unlocked_ioctl.
This leaves drivers/gpu/drm/psb/psb_drv.c unchanged; it has a custom
.unlocked_ioctl and will presumably need a custom .compat_ioctl as
well.
Signed-off-by: Keith Packard <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This is ported from udlfb.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=832188
Cc: [email protected]
Signed-off-by: Dave Airlie <[email protected]>
|
|
udl can only be used as an output offload so doesn't need to support
handle->fd direction.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The GEM vm operations structure is passed to the VM core that stores it
in a const field. There vm operations structures can thus be const in
DRM as well.
Signed-off-by: Laurent Pinchart <[email protected]>
Cc: Inki Dae <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Rob Clark <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
There should be VM_MIXEDMAP, not VM_PFNMAP, because udl_gem_fault() inserts
pages via vm_insert_page(). Other drm/gem drivers already do this.
Signed-off-by: Konstantin Khlebnikov <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: [email protected]
Signed-off-by: Dave Airlie <[email protected]>
|
|
This is an initial drm/kms driver for the displaylink devices.
Supports fb_defio,
supports KMS dumb interface
supports 24bpp via conversion to 16bpp, hw can do this better.
supports hot unplug using new drm core features.
On an unplug, it disables connector polling, unplugs connectors
from sysfs, unplugs fbdev layer (using Kay's API), drops all the
USB device URBs, and call the drm core to unplug the device.
This driver is based in large parts on udlfb.c so I've licensed
it under GPLv2.
Signed-off-by: Dave Airlie <[email protected]>
|