msm: kgsl: Allow sync points to be created on the submitters context
msm: kgsl: Do not take active_cnt for events and waittimestamp

In the mists of time it was nessesary to take an active count
for waittimestamp and events because we did not want to run
the risk of suspending while the GPU was active.  Now that we
have the dispatcher we have much better control over the GPU
so the original risk is diminished.

The problem is that holding active_cnt prevents us from going
into nap and suspend and with server-side-sync a lot of the
events we are waiting for might take a very long time before
they even get dispatched on the GPU so we are essentially
keeping the clocks on waiting for other people.

z180 must take active count on its own.

Change-Id: Ic0dedbadcb608115938b198faebe333d19c6a8f6
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: manage active count in adreno_ioctl()

Most of the adreno specific ioctls do not need the hardware
on. The few that do are perfcounter related, it may be
better at some point to optimize them further to shadow
the counters when the hardware is not on rather than
forcing the power on.

Change-Id: I9ea83106e0aaf3d3ac8d261bdec4e4c2e21c4659
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
msm: kgsl: Run the idle timer while the GPU is not power collapsed
msm: kgsl: update kgsl_cmdbatch_destroy with the tip

The kgsl_cmdbatch_destroy function is outdated with the tip and
the difference patch cannot be cherry-picked easily.

Signed-off-by: Jeff Boody <jboody@codeaurora.org>
msm: kgsl: protect syncpoint events with a reference count

Replace the event spinlock with krefs to avoid the possiblity
of calling a sleeping function while holding the spinlock and
to generally make the whole cmdbatch cancel loop a lot more
stable.

Change-Id: I08ba54fa4c5a11c05e3503dfc6a4ee040733e5a6
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: fix race condition setting the event->handle

A race condition existed for setting the event->handle since the
async event can signal at any time after it has been registered.
When the event signals the reference count for the synclist and
the async callback are decremented causing the event to be freed.
The kgsl_cmdbatch_add_sync_fence function needs to take another
reference to ensure that the handle can be set before the event
is freed.

Change-Id: I0d8a02246e42dce014661d6f14c685415f1704cd
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
defconfing: Various Change
ext2: Remove s_dirt handling

Places which modify superblock feature / state fields mark the superblock
buffer dirty so it is written out by flusher thread. Thus there's no need to
set s_dirt there.

The only other fields changing in the superblock are the numbers of free
blocks, free inodes and s_wtime. There's no real need to write (or even
compute) these periodically. Free blocks / inodes counters are recomputed on
every mount from group counters anyway and value of s_wtime is only
informational and imprecise anyway. So it should be enough to write these
opportunistically on mount, remount, umount, and sync_fs times.

Signed-off-by: Jan Kara <jack@suse.cz>
ext2: do not register write_super within VFS

Jan Kara removed 'sb->s_dirt' VFS flag references, so we do not need to
register the ext2 'ext2_write_super()' method in the VFS superblock operations,
because 'sb->s_dirt' won't be ever set to 1 and VFS won't ever call
'->write_super()' anyway. Thus, remove the method.

Tested using xfstests.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext2: write superblock only once on unmount

Currently on unmount if we are mounted R/W, we first write the superblock to
the media if it is dirty, and then write it again, which is not optimal. This
patch makes ext2 write the superblock on unmount less times.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Clean
workqueue: cond_resched() after processing each work item
commit b22ce27 upstream.

If !PREEMPT, a kworker running work items back to back can hog CPU.
This becomes dangerous when a self-requeueing work item which is
waiting for something to happen races against stop_machine.  Such
self-requeueing work item would requeue itself indefinitely hogging
the kworker and CPU it's running on while stop_machine would wait for
that CPU to enter stop_machine while preventing anything else from
happening on all other CPUs.  The two would deadlock.

Jamie Liu reports that this deadlock scenario exists around
scsi_requeue_run_queue() and libata port multiplier support, where one
port may exclude command processing from other ports.  With the right
timing, scsi_requeue_run_queue() can end up requeueing itself trying
to execute an IO which is asked to be retried while another device has
an exclusive access, which in turn can't make forward progress due to
stop_machine.

Fix it by invoking cond_resched() after executing each work item.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Jamie Liu <jamieliu@google.com>
References: http://thread.gmane.org/gmane.linux.kernel/1552567
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>