hwc: Fix truncation errors in scaling decision

When checking if we are downscaling beyond what the hardware
supports, we were dividing by the factors rather than multiplying
the other side with them.  The truncation of the divisions had
hwc allowing downscaling by a factor slightly larger than what
was supported.

Change-Id: I6ae4d897f4afe68ae26f0d7385e4003d6f2a4253
Signed-off-by: Lajos Molnar <lajos@ti.com>
[steven@steven676.net: adapt for OMAP3 HWC]
hwc: use proper scaler limits for OMAP3

The DSS scaler limits were apparently copied blindly from the OMAP4 HWC.
Use the OMAP3 limits (gleaned from drivers/video/omap2/dss/dispc.c in
the kernel source) instead:

* Decimation not supported (max decimation factor == 1)
* Maximum DSS FCLK 173 MHz

Change-Id: I1e266848c90876a595c62abc3082b0190282809e
hwc: don't vsync after swap in omap3_hwc_set()

SurfaceFlinger is responsible for waiting for vsync since 4.1, so we
should not do it here.

Change-Id: I0e66f2ccdc9bf0905d1ba839d9043a3d997eed7d
hwc: bring sanity to vsync loop code

* Shrink the buffer from 4k to 32 bytes; it's used to store one unsigned
  64-bit int in decimal representation, so 4k is INSANELY oversized
* Make timestamp unsigned -- the value from the kernel is unsigned and
  we're parsing it using strtoull()
* Don't read into the last byte of the buffer (to ensure
  null termination)
* Null-terminate the buffer immediately after the last read byte
* Remove unused variable

Change-Id: Idfe0d8c8f4fe57928b3acf55f70c96de010b60e6
Merge changes Idfe0d8c8,I0e66f2cc,I1e266848,I6ae4d897 into cm-11.0

* changes:
  hwc: bring sanity to vsync loop code
  hwc: don't vsync after swap in omap3_hwc_set()
  hwc: use proper scaler limits for OMAP3
  hwc: Fix truncation errors in scaling decision