drm: change ioctl permissions

Previously read-only KMS ioctls had some somewhat inconsistent settings
regarding whether mastership was required.  For example, GETRESOURCES
did not require master, but GETPLANERESOURCES, GETPROPERTY, etc. did.

At least for debugging, it is nice to be able to use modetest to dump
property values while another process is master, and there seems to
be no harm in allowing read-only access to the KMS state to other
processes.

Signed-off-by: Rob Clark <rob@ti.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, event);
   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).

The atomic functions are mandatory, as they will end up getting
called from enough places that it is easier not to have to bother
with if-null checks everywhere.

TODO:
  + add some stub atomic functions that can be used by drivers
    until they are updated to support atomic operations natively
  + roll-back previous property values if check/commit fails, so
    userspace doesn't see incorrect values.
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: split property values out

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.
drm: convert plane to properties

Use atomic properties mechanism to set plane attributes.  This by
itself doesn't accomplish anything, but it avoids having multiple
code paths to do the same thing when nuclear-pageflip and atomic-
modeset are introduced.
drm: add drm_plane_state

Break the mutable state of a plane out into a separate structure.
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).
drm: convert page_flip to properties

Use atomic properties mechanism for CRTC page_flip.  This by itself
doesn't accomplish anything, but it avoids having multiple code
paths to do the same thing when nuclear-pageflip and atomic-modeset
are introduced.
drm: add drm_crtc_state

Start breaking out the mutable state of the CRTC into it's own
structure.  Plus add _check_state() and _set_property() helpers.
This only moves the state that is related to scanout fb, which
is needed for nuclear-pageflip.  The rest of the mutable state
should be moved from drm_crtc to drm_crtc_state as part of the
atomic-modeset implementation.
drm: atomic pageflip
drm/omap: update for atomic age
OMAPDSS: HDMI: support non-cea non standard VESA formats

If the timings sent to check does not match any of the standard modes,
assume that is a custom timing and set it to VESA mode with 0 as code,
As CEA standard would need to send CEA code during the AVI info frame
and behaviour is a wrong code is sent is not understood currently on
VESA (non- Audio) non-standard timing is supported if the max pixel
clock requested is less than the maximum pixel clock supported by OMAP
for HDMI.

Signed-off-by: Mythri P K <mythripk@ti.com>
panda dsi pll

Conflicts:

	arch/arm/mach-omap2/board-omap4panda.c
	drivers/video/omap2/dss/dpi.c
	drivers/video/omap2/dss/dsi.c
	drivers/video/omap2/dss/dss.c
XXX cleanup dss fixes..
XXX random drm debug
XXX omapdrm atomic
XXX
XXX eclipse hack