kernel/linux.git/drivers/gpu/drm/drm_ioctl.c, branch v3.0.92

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: rework PCI/platform driver interface.

2011-02-07T03:09:36+00:00

This abstracts the pci/platform interface out a step further, we can go further but this is far enough for now to allow USB to be plugged in. The drivers now just call the init code directly for their device type. Signed-off-by: Dave Airlie

drm: Fix support for PCI domains

2010-08-09T22:20:20+00:00

(For some reason I thought that went in ages ago ...) This fixes support for PCI domains in what should hopefully be a backward compatible way along with a change to libdrm. When the interface version is set to 1.4, we assume userspace understands domains and the world is at peace. We thus pass proper domain numbers instead of 0 to userspace. The newer libdrm will then try 1.4 first, and fallback to 1.1, along with ignoring domains in the later case (well, except on alpha of course) Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Dave Airlie

drm: Cleanup after failing to create master->unique and dev->name

2010-08-04T22:42:19+00:00

v2: Userspace (notably xf86-video-{intel,ati}) became confused when drmSetInterfaceVersion() started returning -EBUSY as they used a second call (the first done in drmOpen()) to check their master credentials. Since userspace wants to be able to repeatedly call drmSetInterfaceVersion() allow them to do so. v3: Rebase to drm-core-next. Signed-off-by: Chris Wilson Signed-off-by: Dave Airlie

drm: Add support for platform devices to register as DRM devices

2010-06-01T00:07:39+00:00

Allow platform devices without PCI resources to be DRM devices. [airlied: fixup warnings with dev pointers] Signed-off-by: Jordan Crouse Signed-off-by: Dave Airlie

drm: Remove memory debugging infrastructure.

2009-06-18T20:00:33+00:00

It hasn't been used in ages, and having the user tell your how much memory is being freed at free time is a recipe for disaster even if it was ever used. Signed-off-by: Eric Anholt

drm: fix leak of uninitialized data to userspace

2008-12-29T07:47:22+00:00

...so drm_getunique() is trying to copy some uninitialized data to userspace. The ECX register contains the number of words that are left to copy -- so there are 5 * 4 = 20 bytes left. The offset of the first uninitialized byte (counting from the start of the string) is also 20 (i.e. 0xf65d2294&((1 << 5)-1) == 20). So somebody tried to copy 40 bytes when the string was only 19 long. In drm_set_busid() we have this code: dev->unique_len = 40; dev->unique = drm_alloc(dev->unique_len + 1, DRM_MEM_DRIVER); ... len = snprintf(dev->unique, dev->unique_len, pci:%04x:%02x:%02x.%d", ...so it seems that dev->unique is never updated to reflect the actual length of the string. The remaining bytes (20 in this case) are random uninitialized bytes that are copied into userspace. This patch fixes the problem by setting dev->unique_len after the snprintf(). airlied- I've had to fix this up to store the alloced size so we have it for drm_free later. Reported-by: Sitsofe Wheeler Signed-off-by: Vegard Nossum Signed-off-by: Dave Airlie