OMAPFB: Asynchronous vsync notification

Enabled and disabled through new OMAPFB_ENABLEVSYNC ioctl.  Events delivered
as switch events.

Change-Id: I3a40523d35e2eff3510892a4adcd6a4821c883a5
Signed-off-by: Erik Gilling <konkers@android.com>
Signed-off-by: Tony Lofthouse <a0741364@ti.com>
encore: include support for hwcomposer

Fixes issues with invalid private data size error

[steven@steven676.net: remove unneeded portion of patch]

Change-Id: Ibd3ff5798335f6f553ae80629c04771915fac309
OMAPLFB: Dont foward compositions to DSSCOMP if overlay is Zero

Do not foward compositions to DSSCOMP in case overlay number
passed by HWC is zero. The dsscomp->num_overlay = 0 means
that there is no primary display and no rendering is required.

Change-Id: If7b582efeb55ce84878d0bfbd19eabd2ebd3afaa
Signed-off-by: Tony Lofthouse <a0741364@ti.com>
Signed-off-by: Dandawate Saket <dsaket@ti.com>
encore defconfigs update

* Bring defconfigs into line with recommendations in
  http://source.android.com/devices/tech/kernel.html
* Remove ext2 and ext3 filesystem drivers to save space (we're now using
  the ext4 driver to handle ext2/3 filesystems)

Change-Id: Iac810f7c745802e5c811446cf7726d13cf1b3c3a
ARM: OMAP3+: Implement timer workaround for errata i103 and i767

Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
      registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)

Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.

GPTimer non-posted synchronization mode is not impacted by this
limitation.

Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
    domain
3). Use no-idle mode when the timer is active

Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.

Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.

For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.

	__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
	__omap_dm_timer_enable_posted(timer);

Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.

Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.

Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.

[steven@steven676.net: squash in 7b44cf2 ("ARM: OMAP: Fix timer posted
mode support")]

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[steven@steven676.net: backport to p-android-omap3-3.0]

Change-Id: Id10648050492d8c91ea22093127584f02ec3655b
usb:gadget:android: avoid sending extra uevents

Don't schedule a uevet from android_disconnect
if there is no change in the connection state
and if the DISCONNECT event was already sent.
This patch will avoid these unecessary messages:

android_work: did not send uevent (0 0   (null))

Change-Id: I074d9fb712a18b2f805d4e46a4f6a5412b682ffe
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Arun Joseph <arunjoseph@ti.com>
[steven@steven676.net: make apply to p-android-omap3-3.0]
plat: dma: increase dma priority

Change-Id: I05f5b1aaf5010abf07b2f97f84fd81872bb8dfc1
OMAP3: PVR: allow userspace to control memory bus pinning

Allowing userland to control the memory bus pinning should reduce power
consumption when the screen is off.

Change-Id: I3b001a05ce61b722cfd9d9f238ca14139a2d1c99
video: omap2: Add support for VSYNC notify via sysfs

 * Sending uevents at 60Hz is very nasty for userspace with many
   listeners. This patch provides an alternate notification mechanism
   via the framebuffer sysfs which we can simply poll on.
 * Requires a userspace change to hwcomposer to support this.

Based on Change-Id Iba180da52ae05b3e702790e27c7ded65d57445c9 from
the msm8660-common CM kernel for Samsungs

[steven@steven676.net: make apply to encore kernel]

Change-Id: I32e1158ee63aab026eed361d39aecbbedfd23dad