linux-toradex.git/include/drm/drm.h, branch v3.4.73

drm: base prime/dma-buf support (v5)

2012-03-30T10:52:44+00:00

This adds the basic drm dma-buf interface layer, called PRIME. This
commit doesn't add any driver support, it is simply and agreed upon starting
point so we can work towards merging driver support for the next merge window.

Current drivers with work done are nouveau, i915, udl, exynos and omap.

The main APIs exposed to userspace allow translating a 32-bit object handle
to a file descriptor, and a file descriptor to a 32-bit object handle.

The flags value is currently limited to O_CLOEXEC.

Acknowledgements:
Daniel Vetter: lots of review
Rob Clark: cleaned up lots of the internals and did lifetime review.

v2: rename some functions after Chris preferred a green shed
fix IS_ERR_OR_NULL -> IS_ERR
v3: Fix Ville pointed out using buffer + kmalloc
v4: add locking as per ickle review
v5: allow re-exporting the original dma-buf (Daniel)

Reviewed-by: Daniel Vetter 
Reviewed-by: Rob Clark 
Reviewed-by: Sumit Semwal 
Reviewed-by: Inki Dae 
Acked-by: Ben Widawsky 
Signed-off-by: Dave Airlie

drm: add some caps for userspace to discover more info for dumb KMS driver (v2)

2012-02-16T18:35:11+00:00

For the simple KMS driver case we need some more info about what the preferred
depth and if a shadow framebuffer is preferred.

I've only added this for intel/radeon which support the dumb ioctls so far.

If you need something really fancy you should be writing a real X.org driver.

v2: drop cursor information, just return an error from the cursor ioctls
and we can make userspace fallback to sw cursor in that case, cursor
info was getting too messy, best to start smaller.

Signed-off-by: Dave Airlie

drm: add an fb creation ioctl that takes a pixel format v5

2011-11-15T19:53:23+00:00

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
    update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
    pull in Ville's fix for the memcpy in drm_plane_init
    apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)

Signed-off-by: Ville Syrjälä 
Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Signed-off-by: Jesse Barnes 
Signed-off-by: Dave Airlie

drm: add plane support v3

2011-11-15T19:53:10+00:00

Planes are a bit like half-CRTCs.  They have a location and fb, but
don't drive outputs directly.  Add support for handling them to the core
KMS code.

v2: fix ABI of get_plane - move format_type_ptr to the end
v3: add 'flags' field for interlaced support (from Ville)

Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jesse Barnes 
Signed-off-by: Dave Airlie

drm/vblank: update recently added vbl interface to be more future proof.

2011-03-24T11:28:46+00:00

This makes the interface a bit cleaner by leaving a single gap in the
vblank bit space instead of creating two gaps.

Suggestions from Michel on mailing list/irc.

Reviewed-by: Michel Dänzer 
Signed-off-by: Dave Airlie

drm/kernel: vblank wait on crtc > 1

2011-03-20T23:25:54+00:00

Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
the capability to wait on vblank events for CRTCs that are greater than 1
and thus cannot be represented with primary/secondary flags in the legacy
interface. It was discussed on the dri-devel list in these two threads:

http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html

This patch extends the interface to drm_wait_vblank ioctl so that crtc>1
can be represented. It also adds a new capability to drm_getcap ioctl so
that the user space can check whether the new interface to drm_wait_vblank
is supported (and fall back to the legacy interface if not)

Signed-off-by: Ilija Hadzic 
Reviewed-by: Mario Kleiner 
Acked-by: Mario Kleiner 
Reviewed-by: Alex Deucher 
Tested-by: Alex Deucher 
Signed-off-by: Dave Airlie

drm: add cap bit to denote if dumb ioctl is available or not.

2011-03-04T05:56:22+00:00

This allows libkms to make an easier decision.

Signed-off-by: Dave Airlie

drm/core: add ioctl to query device/driver capabilities

2011-03-04T04:47:30+00:00

We're coming to see a need to have a set of generic capability checks in
the core DRM, in addition to the driver-specific ioctls that already
exist.

This patch defines an ioctl to do as such, but does not yet define any
capabilities.

[airlied: drop the driver callback for now.]

Signed-off-by: Ben Skeggs 
Signed-off-by: Dave Airlie

drm: dumb scanout create/mmap for intel/radeon (v3)

2011-02-07T02:16:14+00:00

This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.

It looks to me like it would be useful in the following cases:
a) in development drivers - we can always provide a shadowfb fallback.
b) libkms users - we can clean up libkms a lot and avoid linking
to libdrm_*.
c) plymouth via libkms is a lot easier.

Userspace bits would be just calls + mmaps. We could probably
mark these handles somehow as not being suitable for acceleartion
so as top stop people who are dumber than dumb.

Signed-off-by: Dave Airlie

drm: move ttm global code to core drm

2010-08-03T23:46:06+00:00

I wrote this for the prime sharing work, but I also noticed other external
non-upstream drivers from a large company carrying a similiar patch, so I
may as well ship it in master.

Signed-off-by: Dave Airlie