linux-toradex.git/drivers/gpu/drm/drm_drv.c, branch v3.4.2

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 core support for unplugging a device (v2)

2012-03-15T13:35:33+00:00

Two parts to this, one is simple unplug from sysfs for the device node.

The second adds an unplugged state, if we have device opens, we
just set the unplugged state and return, if we have no device
opens we drop the drm device.

If after a lastclose we discover we are unplugged we then
drop the drm device.

v2: use an atomic for unplugged and wrap it for users,
add checks on open + mmap + ioctl entry points.

Signed-off-by: Dave Airlie

drm: remove master fd restriction on mode setting getters

2012-02-03T09:29:35+00:00

Its useful to be able to call the mode setting getter ioctls.
Not requiring master fd, enables writing a simple program which
can query the state of the video system.

Since these ioctls are only "getters" there is no security or
synchronization issues which would require master fd. Opening
an new fd is already protected by the file permissions on the
device file.

Signed-off-by: Mandeep Singh Baines 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Ilija Hadzic 
Cc: Jesse Barnes 
Cc: Stephane Marchesin 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie

drm: make DRM_UNLOCKED ioctls with their own mutex

2012-01-05T14:43:02+00:00

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 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: no need to hold global mutex for static data

2012-01-05T14:42:52+00:00

drm_getcap and drm_version ioctls only reads static data,
there is no need to protect them with drm_global_mutex,
so make them DRM_UNLOCKED

Signed-off-by: Ilija Hadzic 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie

Merge tag 'v3.2-rc6' of /home/airlied/devel/kernel/linux-2.6 into drm-core-next

2011-12-20T14:43:53+00:00

Merge in the upstream tree to bring in the mainline fixes.

Conflicts:
	drivers/gpu/drm/exynos/exynos_drm_fbdev.c
	drivers/gpu/drm/nouveau/nouveau_sgdma.c

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: do not sleep on vblank while holding a mutex

2011-11-11T11:12:47+00:00

drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vblanks between the current and the
one it is waiting for. In some cases it can block the entire windowing
system.

v2: incorporate comments received from Daniel Vetter and
    Michel Daenzer.

v3/v4: after a lengty discussion with Daniel Vetter, it was concluded
       that the only thing not yet protected with locks and atomic
       ops is the write to dev->last_vblank_wait. It's only used in a
       debug file in proc, and the current code already employs no
       correct locking: the proc file only takes dev->struct_mutex,
       whereas drm_wait_vblank implicitly took the drm_global_mutex.
       Given all this, it's not worth bothering to try to fix
       the locks at this time.

Signed-off-by: Ilija Hadzic 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie

gpu: Add export.h as required to drivers/gpu files.

2011-10-31T23:32:03+00:00

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE

Signed-off-by: Paul Gortmaker