msm: bam_dmux: Extend locking around SPS transfer call

When a new receive packet is created in queue_rx(), it is added to the
receive packet queue and also queued with the SPS driver.  Once the
packet is filled, then BAM DMUX calls sps_get_iovec() to get the filled
receive buffer.  BAM DMUX then pulls the receive packet info off of the
RX queue and compares the DMA address from the sps_get_iovec() call to
the expected DMA address.  In some cases, they do not match resulting in
BAM DMUX processing the wrong RX buffer.

Going back to the queue_rx() processing, the packet is added to the
receive queue with a mutex locked, but then the mutex is unlocked before
the call to sps_transfer_one() which allows a race condition to exist if
multiple threads call queue_rx().

During normal operation, queue_rx() is only called by the
single-threaded receive workqueue, but during the call to
reconnect_to_bam(), a race condition is expected between the call to
rx_siwtch_to_interrupt_mode() and the final call to queue_rx() if a
packet comes in and is processed before the queue_rx() call is
completed.

This change extends the receive pool mutex locking around
sps_transfer_one() call which resolves the issue.

CRs-Fixed: 377609
Change-Id: Iba5b10e291a1612846fa58dae87aadbd79aa297b
Signed-off-by: Eric Holmberg <eholmber@codeaurora.org>