drm plane helper functions

[ville.syrjala at linux.intel.com]

This set intoduces a bunch of helper functions for help drm plane
driver writers deal with scaling and other details. Still work in progress,
escpecially the last patch.

Some open questions:
- In which file should this kind of stuff be placed?

- How should the functions be named?

- Should the scaling factor helpers also perform pre-decimation, by
  increasing the stride or skipping pixels. OMAP is the only hardware
  I've seen that can skip pixels horizontally, but increasing the stride
  should be possible practically on every hardware.

- User space API for the CSC stuff

There is also a bunch of other stuff missing from the API:
- interlaced buffers
  This should be a fairly simple addition to addfb2. I'll try to
  propose something next week.

- color keying
  One question here is whether to expose just plain key values
  or perhaps min+max, or key+mask, or both depending on what the 
  hardware actually supports. I think for now I'll just ignore the
  fact that color keying may or may not be plane specific.

- alpha blending
  Constant alpha and per pixel alpha. I don't recall of the v4l2 fourccs
  had any alpha channel stuff in them, so we may need extra fourccs, or
  just some extra per-pixel alpha enable bit in the API.

- zorder
  What's a nice API for this? A signed int with 0 being reserved for
  the "CRTC plane". Negative values would place the planes below the
  "CRTC plane", and positive values above it. Setting a plane to a
  specific zorder would move the existing stack of planes away from
  zero to make room for the new plane, any holes in the stack would
  get squashed. Does that sound reasonable?

- gamma correction
  I've seen three major variations in hardware; selection from a small
  fixed set of functions, a single curve with some number of points
  which may or may not be spaced equally, and a full LUT.

- color adjustment
  My proposal would be something close to what DirectFB uses.
  Brightness,contrast,saturation,hue adjustments. Valid values 0x0000-0xffff,
  where 0x8000 means "no change", smaller values mean decrease and larger
  values increase. The drivers would then map that to hardware specific
  values however they see fit. I think a good guideline would be to utilize
  the full range even if the hardware only supports a few adjustment steps.
  This would allow the users of the API to remain hardware agnostic.

- VC1 range mapping
  I left this out of the CSC enums for now. I'm not 100% sure, but I think
  this simply boils down to two small integers which are used to multiply
  the luma and chroma values before color space conversion. I also don't know
  what the range of the resulting luma and chroma values is, ie. is it always
  full range or not, or can that detail still be specified separately.

If no one beats me to it I'll try to come up with some actual code/structs for these
things soon. Feel free to propose something if you think I've left something important
out.