ARM: add get_user() support for 8 byte types (3.4 backport version)

A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).
drm: fix typo

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm: add atomic fxns

The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically.  This will be the basis of atomic-
modeset and nuclear-pageflip.

The basic flow is:

   state = dev->atomic_begin();
   for (... one or more ...)
      obj->set_property(obj, state, prop, value);
   if (dev->atomic_check(state))
      dev->atomic_commit(state);
   dev->atomic_end(state);

The split of check and commit steps is to allow for ioctls with a
test-only flag (which would skip the commit step).

Conflicts:
	drivers/gpu/host1x/drm/drm.c
	drivers/gpu/host1x/drm/drm.h
	drivers/staging/imx-drm/imx-drm-core.c
drm: convert crtc to ww_mutex

At the moment, this doesn't do anything.  But for atomic we will have an
ww_acquire_ctx associated with the state, to simplify the locking and
avoid potential deadlock when we cannot control the locking order.
drm: add object property type

An object property is an id (idr) for a drm mode object.  This
will allow a property to be used set/get a framebuffer, CRTC, etc.
drm: add DRM_MODE_PROP_DYNAMIC property flag

This indicates to userspace that the property is something that can
be set dynamically without requiring a "test" step to check if the
hw is capable.  This allows a userspace compositor, such as weston,
to avoid an extra ioctl to check whether it needs to fall-back to
GPU to composite some surface prior to submission of GPU render
commands.
drm: add DRM_MODE_PROP_SIGNED property flag

Flag for range property types indicating that the value is a signed
integer rather than unsigned.  For range properties, the signed flag
will trigger use of signed integer comparisions, to handle negative
values properly.
drm: helpers to find mode objects

Add a few more useful helpers to find mode objects.
drm: split propvals out and blob property support

Split property values out into a different struct, so we can later
move property values into state structs.  This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.

And since we are touching all the same code, add support for mutable
blob properties, which will also be needed for atomic modeset.
drm: Allow drm_mode_object_find() to look up an object of any type

To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm: Refactor object property check code

Refactor the code to check whether an object has a specific property
to a new function.

v1: original
v2: rebase on atomic -- Rob Clark
v3: EINVAL->ENOENT

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm: convert plane to properties/state

Break the mutable state of a plane out into a separate structure
and use atomic properties mechanism to set plane attributes.  This
makes it easier to have some helpers for plane->set_property()
and for checking for invalid params.  The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.

The same should be done for CRTC, encoder, and connector, but this
patch only includes the first part (plane).

Conflicts:
	drivers/gpu/host1x/drm/dc.c
drm: convert crtc to properties/state

Break the mutable state of a crtc out into a separate structure
and use atomic properties mechanism to set crtc attributes.  This
makes it easier to have some helpers for crtc->set_property()
and for checking for invalid params.  The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.

This also re-works the locking a bit.. maybe some of these changes
should be rejuggled into different patch.  But now atomic plane updates
grab current (and if necessary, incoming) crtc locks for their
synchronization.
drm: Atomic modeset ioctl

The atomic modeset ioctl cna be used to push any number of new values
for object properties. The driver can then check the full device
configuration as single unit, and try to apply the changes atomically.

The ioctl simply takes a list of object IDs and property IDs and their
values. For setting values to blob properties, the property value
indicates the length of the data, and the actual data is passed via
another blob pointer.

The caller can demand non-blocking operation from the ioctl, and if the
driver can't satisfy that requirement an error will be returned.

The caller can also request to receive asynchronous completion events
after the operation has reached the hardware. An event is sent for each
object specified by the caller, whether or not the actual state of
that object changed. Each event also carries a framebuffer ID, which
indicates to user space that the specified object is no longer
accessing that framebuffer.

TODO: detailed error reporting?

v1: original
v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
v4: drop atomic event, align flags w/ pageflip (atomic flags should be
    a strick superset of pageflip flags to keep things easier for the
    drivers)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm/msm: add atomic support

TODO: probably can split this up into prep patch which splits the
msm_queue_fence_cb out of gem..
HACK: drm: allow FB's in drm_mode_object_find

Ugg.. we do actually want to permit FB's in atomic case, since FB will
be looked up like any other object property value.

Currently we do the FB refcnt'ing dance in atomic->commit(), and would
rather not have to special case FB's or collect an FB ref when we look
up the property.  Not sure if it is better to rework the atomic FB
refcnt'ing or loosen this restriction?