gpu: ion: repurpose flags field for heap_mask and caching

In the latest Ion API, userspace clients specify the heap_mask for an
allocation in the `heap_mask' field of the ion_allocation_data
structure, and they specify caching in the `flags' field. Before, the
heap_mask was in the `flags' field and caching was specified with the
O_DSYNC file open flag.

We would like to support the new API without actually updating Ion. To
do this, | the heap_mask back into the flags field on an allocation
ioctl (since the internal kernel APIs still expect to see it
there). Also make sure that caching is taken from the buffer flags
field rather than the O_DSYNC file flag.

Change-Id: I872afb40d9bf7c49bb31f19c5e9726ac714ef850
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
gpu: ion: move msm-specific ioctls to custom_ioctl

To avoid collisions with future ioctls that may be added to ion,
msm-specific ioctls should use the `custom_ioctl' interface provided
by struct ion_device, as originally intended.

Change-Id: Ic36f1ff37ce79926482942f70d466acf95c9c170
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>

Conflicts:

	drivers/gpu/ion/ion.c
	drivers/gpu/ion/msm/msm_ion.c
fix mismerge
msm: ion: Only return Ion flags in ion_handle_get_flags

Since the ion_buffer.flags field is shared between the actual Ion
flags as well as the Ion heap mask, make sure that we're only
returning flags. The heap_mask bits should be masked off.

Change-Id: Ibdaf0ea374b7b80a036bddd11d19c4bafa173ef6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Use mr1_chocolate variant
ASoC: msm: qdsp6: Fixed the issue unmap command is sent incorrectly

When session CLOSE command is sent right before session RUN command
is acknowledged, callback function can mistakenly think that
the next received acknowledgement is for CLOSE command instead of
RUN command. This triggers driver to send memory unmap command to
the Q6 while it is still processing the CLOSE command. Eventually,
this leads to an invalid memory access and causes Q6 crash.

Change-Id: Ib5d560fbcb7e8ced79cc1075a9f6bea3b55a86b6
CRs-Fixed: 377281
Signed-off-by: Jay Wang <jaywang@codeaurora.org>
msm: Asoc: LPA: Fix pause and next clip play issue

- When paused and press next button to play next song,
sometimes CMD_EOS fails to get Ack from LPASS and
is wait timeout for 5sec causing delay for next
playback start.
- In the failure case, even before trigger start
of driver is done,LPA driver receives pcm_close.
In this case, though EOS is issued, it is not
getting honored from LPASS.
- If trigger start not happen in LPA driver,
avoid CMD_EOS to LPASS as it will not be handled.

CRs-Fixed: 368519, 366926
Change-Id: Ib5ff21925bb44849b27ed4709b72efcccf412b5d
Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>
ASoC: msm: qdsp6: Fixed the volume command timeout issue

QDSP6 can send out of sequence response and this breaks
the no wait command tracking logic. It results the wait
command response gets ignored and causes the wait time out.
To resolve the issue, each response needs to be checked
to determine if the response is for no wait or wait command.

CRs-Fixed: 402768
Signed-off-by: Jay Wang <jaywang@codeaurora.org>
Change-Id: I772f9e6d1d58186d67a3543dfc3b0d545dd8a73d
ASoC: msm: Fix for a seekbar issue during audio playback.

Issue is that when seek happens several times during audio playback,
and at some point last buffer write done event from DSP is received,
an ioctl drain is issued, which will set pending_buffer flag to 0,
In the mean time before drain finishes a seek comes, which issues
a flush on all the buffers and try to resume the playback again.
Now because the pending_buffer flag is set to 0, CMD_RUN will return
without any further writes to DSP. As a result no audio buffers are
reaching the DSP and hence no audio is getting played.
Make a fix is to set pending_buffer flag to 1 whenever playback is resumed
after seek.

Change-Id: I89812332f14e0682be28445ad1f15564f129ae11
Signed-off-by: Mingming Yin <mingming@codeaurora.org>