09b4ea47d1041612b101c369969db123ac2c1511 |
|
28-Oct-2011 |
Ilija Hadzic <ihadzic@research.bell-labs.com> |
drm: make DRM_UNLOCKED ioctls with their own mutex drm_getclient, drm_getstats and drm_getmap (with a few minor adjustments) do not need global mutex, so fix that and make the said ioctls DRM_UNLOCKED. Details: drm_getclient: the only thing that should be protected here is dev->filelist and that is already protected everywhere with dev->struct_mutex. drm_getstats: there is no need for any mutex here because the loop runs through quasi-static (set at load time only) data, and the actual count access is done with atomic_read() drm_getmap already uses dev->struct_mutex to protect dev->maplist, which also used to protect the same structure everywhere else except at three places: * drm_getsarea, which doesn't grab *any* mutex before touching dev->maplist (so no drm_global_mutex doesn't help here either; different issue for a different patch). However, drivers seem to call it only at initialization time so it probably doesn't matter * drm_master_destroy, which is called from drm_master_put, which in turn is protected with dev->struct_mutex everywhere else in drm module, so we are good here too. * drm_getsareactx, which releases the dev->struct_mutex too early, but this patch includes the fix for that. v2: * incorporate comments received from Daniel Vetter * include the (long) explanation above to make it clear what we are doing (and why), also at Daniel Vetter's request * tighten up mutex grab/release locations to only encompass real critical sections, rather than some random code around them Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
51eab416c9b4b3ed16553d405ec4a5f67daa34cf |
|
24-Mar-2011 |
Dave Airlie <airlied@redhat.com> |
drm/vblank: update recently added vbl interface to be more future proof. 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 <michel@daenzer.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
19b01b5fbf0b78930b3b06ee6080539c17b5d1fd |
|
18-Mar-2011 |
Ilija Hadzic <ihadzic@research.bell-labs.com> |
drm/kernel: vblank wait on crtc > 1 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 <ihadzic@research.bell-labs.com> Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Acked-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Tested-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
e73f88af66fcc50083fae4b7e1c39b469179a97a |
|
04-Mar-2011 |
Dave Airlie <airlied@redhat.com> |
drm: add cap bit to denote if dumb ioctl is available or not. This allows libkms to make an easier decision. Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
9f35421e09c494c36079d7cf5724ae9f832431d7 |
|
21-Feb-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/core: add ioctl to query device/driver capabilities 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 <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
8410ea3b95d105a5be5db501656f44bbb91197c1 |
|
14-Dec-2010 |
Dave Airlie <airlied@gmail.com> |
drm: rework PCI/platform driver interface. 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 <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
c17c2f892e23a3c70281a4e79bd7c2c226b1a561 |
|
06-Aug-2010 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
drm: Fix support for PCI domains (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 <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
3fb688fdc1890f9e8e97597f690c145ab888aec0 |
|
04-Aug-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Cleanup after failing to create master->unique and dev->name 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 <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
dcdb167402cbdca1d021bdfa5f63995ee0a79317 |
|
27-May-2010 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm: Add support for platform devices to register as DRM devices Allow platform devices without PCI resources to be DRM devices. [airlied: fixup warnings with dev pointers] Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
9a298b2acd771d8a5c0004d8f8e4156c65b11f6b |
|
24-Mar-2009 |
Eric Anholt <eric@anholt.net> |
drm: Remove memory debugging infrastructure. 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 <eric@anholt.net>
/drivers/gpu/drm/drm_ioctl.c
|
1147c9cdd0f60f09a98702a9f865176af18a989f |
|
02-Dec-2008 |
Vegard Nossum <vegard.nossum@gmail.com> |
drm: fix leak of uninitialized data to userspace ...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 <sitsofe@yahoo.com> Signed-off-by: Vegard Nossum <vegardno@thuin.ifi.uio.no> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a |
|
28-Nov-2008 |
Dave Airlie <airlied@redhat.com> |
drm: move to kref per-master structures. This is step one towards having multiple masters sharing a drm device in order to get fast-user-switching to work. It splits out the information associated with the drm master into a separate kref counted structure, and allocates this when a master opens the device node. It also allows the current master to abdicate (say while VT switched), and a new master to take over the hardware. It moves the Intel and radeon drivers to using the sarea from within the new master structures. Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|
c0e09200dc0813972442e550a5905a132768e56c |
|
29-May-2008 |
Dave Airlie <airlied@redhat.com> |
drm: reorganise drm tree to be more future proof. With the coming of kernel based modesetting and the memory manager stuff, the everything in one directory approach was getting very ugly and starting to be unmanageable. This restructures the drm along the lines of other kernel components. It creates a drivers/gpu/drm directory and moves the hw drivers into subdirectores. It moves the includes into an include/drm, and sets up the unifdef for the userspace headers we should be exporting. Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/drm_ioctl.c
|