drivers: soc: rpmh: Use completion instead of wait queue

The wait_event() call bails out of the wait, without adding the task to
the wait list, if the condition argument is already true. This poses a
problem for a wait_queue_head_t object that is declared in stack. The
function that created the object on stack, would therfore not wait and
when it returns from the function, would free up the wait_queue_head_t
object. However, the thread that is supposed to signal the wakeup may
still be accessing the wait_queue_head_t object when the stack is freed
or worse reinitialized with another call.

Thread A:

void foo(void)
{
	DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wait);
	atomic_t count = ATOMIC_INIT(0);

	...
	do_something_and_signal(&wait, &count);
	...
	wait_event(wait, (atomic_read(&count) == 0));
}

Thread B:

void bar(wait_queue_head_t *wait, atomic_t *count)
{
	if (atomic_dec_and_test(count))
		wake_up(wait);
}

In this example, Thread A sets up the wait queue and triggers a call to
do some work. A call that would ultimately signal the completion of wait
by calling wakeup in Thread B. If thread B were to run immediately and
execute atomic_dec_and_test() while thread A is still yet to call
wait_event(), making the condition (count == 0) true, Thread A would
exit the function and release the stack. In the meanwhile Thread B is
still executing wake_up() when it realizes the wait_queue_head_t
object has been re-initalized and would throw a spin bug when it
accesses the re-initialized spinlock in the wait_queu_head_t. The reason
for this behavior is this condition check, in wait_event() which bails
out from the call -

do {
	might_sleep();
	if (condition)
		break;
	__wait_event(wq, condition);
} while (0)

Solve this this situation for the RPMH driver by using completion
instead of wait_queues. Completion objects guarantee the signal is
respected and waited up on.

Change-Id: Ic3f7c0cbb7c929a998d7d031ce7e01abf8e1fdd5
Signed-off-by: Lina Iyer <ilina@codeaurora.org>