+ mxt224_u1.c: some testing ...
loopdev: fix a deadlock

bd_mutex and lo_ctl_mutex can be held in different order.

Path #1:

blkdev_open
 blkdev_get
  __blkdev_get (hold bd_mutex)
   lo_open (hold lo_ctl_mutex)

Path #2:

blkdev_ioctl
 lo_ioctl (hold lo_ctl_mutex)
  lo_set_capacity (hold bd_mutex)

Lockdep does not report it, because path #2 actually holds a subclass of
lo_ctl_mutex.  This subclass seems creep into the code by mistake.  The
patch author actually just mentioned it in the changelog, see commit
f028f3b2 ("loop: fix circular locking in loop_clr_fd()"), also see:

	http://marc.info/?l=linux-kernel&m=123806169129727&w=2

Path #2 hold bd_mutex to call bd_set_size(), I've protected it
with i_mutex in a previous patch, so drop bd_mutex at this site.

Signed-off-by: Guo Chao <yan@linux.vnet.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Guo Chao <yan@linux.vnet.ibm.com>
Cc: M. Hindess <hindessm@uk.ibm.com>
Cc: Nikanth Karthikesan <knikanth@suse.de>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
+ stand-hotplug.c: clean up -> need testing ...
+ set "min-freq" as "freq_cpu1on" [need testing]

... because the second-core can save battery and speed up the system, so why we only use secand-core if freq is > 600 MHz ...
+ mxt224_u1.c: little code refactoring ...
block: row: Re-design urgent request notification mechanism

When ROW scheduler reports to the block layer that there is an urgent
request pending, the device driver may decide to stop the transmission
of the current request in order to handle the urgent one. This is done
in order to reduce the latency of an urgent request. For example:
long WRITE may be stopped to handle an urgent READ.

This patch updates the ROW URGENT notification policy to apply with the
below:

- Don't notify URGENT if there is an un-completed URGENT request in driver
- After notifying that URGENT request is present, the next request
  dispatched is the URGENT one.
- At every given moment only 1 request can be marked as URGENT.
  Independent of it's location (driver or scheduler)

Other changes to URGENT policy:
- Only READ queues are allowed to notify of an URGENT request pending.

CR fix:
If a pending urgent request (A) gets merged with another request (B)
A is removed from scheduler queue but is not removed from
rd->pending_urgent_rq.

CRs-Fixed: 453712
Change-Id: I321e8cf58e12a05b82edd2a03f52fcce7bc9a900
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:
	block/row-iosched.c

+ ...
restore correct init for our branch. just to be in sync.
PM / Sleep: Look for wakeup events in later stages of device suspend

Currently, the device suspend code in drivers/base/power/main.c
only checks if there have been any wakeup events, and therefore the
ongoing system transition to a sleep state should be aborted, during
the first (i.e. "suspend") device suspend phase.  However, wakeup
events may be reported later as well, so it's reasonable to look for
them in the in the subsequent (i.e. "late suspend" and "suspend
noirq") phases.

Change-Id: Idc55bb84fd820c4f0b5e037186fb337daa612fb4
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 52d136cc2cf6659ee247dbcc88c9e7bd7428ad06
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
PM / Sleep: Use wait queue to signal "no wakeup events in progress"

The current wakeup source deactivation code doesn't do anything when
the counter of wakeup events in progress goes down to zero, which
requires pm_get_wakeup_count() to poll that counter periodically.
Although this reduces the average time it takes to deactivate a
wakeup source, it also may lead to a substantial amount of unnecessary
polling if there are extended periods of wakeup activity.  Thus it
seems reasonable to use a wait queue for signaling the "no wakeup
events in progress" condition and remove the polling.

Change-Id: I19bfca1a13fa3d7437c7207575a4ebde60ad25cd
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: mark gross <markgross@thegnar.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 60af1066913162c5dd13fad3b872a67b1eb7da0f
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
PM / Sleep: Change wakeup source statistics to follow Android

Wakeup statistics used by Android are slightly different from what we
have in wakeup sources at the moment and there aren't any known
users of those statistics other than Android, so modify them to make
it easier for Android to switch to wakeup sources.

This removes the struct wakeup_source's hit_cout field, which is very
rough and therefore not very useful, and adds two new fields,
wakeup_count and expire_count.  The first one tracks how many times
the wakeup source is activated with events_check_enabled set (which
roughly corresponds to the situations when a system power transition
to a sleep state is in progress and would be aborted by this wakeup
source if it were the only active one at that time) and the second
one is the number of times the wakeup source has been activated with
a timeout that expired.

Additionally, the last_time field is now updated when the wakeup
source is deactivated too (previously it was only updated during
the wakeup source's activation), which seems to be what Android does
with the analogous counter for wakelocks.

Change-Id: Ifda34645ed321f12f7911b90b48408b58ee88fd6
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 30e3ce6dcbe3fc29c343b17e768b07d4a795de21
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:
	drivers/base/power/wakeup.c

+ ...
PM / Sleep: Add wakeup_source_activate and wakeup_source_deactivate tracepoints

Add tracepoints to wakeup_source_activate and wakeup_source_deactivate.
Useful for checking that specific wakeup sources overlap as expected.

Change-Id: I1fa803411a11e50a4904fc97758dcbe39fa82516
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Git-commit: 6791e36c4a40e8930e08669e60077eea6770c429
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:
	include/trace/events/power.h
TMU: video lock by temp. after recheck, we dont use that! it's for >>

so i was wrong to "FIX" the #if defined(CONFIG_VIDEO_MALI400MP)
to #if defined(CONFIG_VIDEO_MALI400MP_UMP)

Removing!
CPU Voltage: equalized non standard CPU to standard CPU voltage! -25mv!
now it's equal. need to TEST! and see if it's GOOD thing or BAD.
VIDEO DRIVER! MALI V2 and JB/ICS STOCK fixed! restored lost functions!
Now power will be saved more and VPLL is working GREAT all stable.
Disabled Debug for touch screen driver. not needed now. + code style.
VIDEO DRIVER: will be best to set bottom_lock_step init to 0 and static.
for each driver.