ASoC: WCD9310: remove dependency between DMIC's and Decimators.

The source of input signal(ADC or DMIC) needs to configured correctly
in CDC_TXn_MUX_CTL registers for correct operation of Decimators.
Currently for DMIC's, this configuration is done in DMIC DAPM widget
power up/down call back creating  dependency between DMIC number and
Decimator number (with current code, DMIC1 can send signal to only
DEC1, DMIC2 can send signal to only DEC2). Remove this dependency by
setting type of input signal when Decimator MUX input is set.

Change-Id: Ic084bb892d663dea51ca5a5a95c6bdba30453744
Signed-off-by: Kiran Kandi <kkandi@codeaurora.org>
ASoC: Handle slimbus port disconnection before opening another

Problem Description:
Open and close the same set of slimbus ports after
certain iterations will fail port open, as that port
was not disconnected successfully.

Fix Description:
Handle sequence of closing slimbus ports. Store
the channel masks associated with each codec dai
and reset them after they are closed from slimbus
Then, release the close slimbus port event, after
all the channels are closed completely

Change-Id: Ie14b9f0920b37f905151b48f18df181503acc21d
CRs-fixed: 370761
Signed-off-by: Swaminathan Sathappan <Swami@codeaurora.org>

Conflicts:

	sound/soc/codecs/wcd9310.c
msm: audio_slimbus: Register device with clock driver and rename clocks

Rename the clocks per the new naming convention under which
similarly named clocks are distinguished between using their
associated device's name and ID.

Change-Id: If35cda86f35837d1c8c599147a6f4852390bbc96
Signed-off-by: Tianyi Gou <tgou@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/clock-8960.c
slimbus: Don't allow a grouped channel to be controlled individually

Once client defines a group of channels, it should be only allowed to
be controlled as a group and not individually to avoid synchronization
issues between grouped channels.

Change-Id: Ib318497b2666eb5134a1cb220e5df6569c9fcc2e
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim_msm: Remove active channels of a satellite when it restarts

When a subsystem hosting satellite restarts, it may not have cleaned
up its active channels. Remove all active channels when this is
detected. Other satellites, and channels already removed (if cleanup
was executed on the subsystem hosting satellite) are not affected.

Change-Id: I50ac40e450335a4fa5be957bacf997311410bee1
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim_msm: Use new clock APIs

Slimbus MSM controller driver calls clk_enable and clk_disable from
non-atomic contexts.
So the calls are just replaced by clk_prepare_enable and
clk_disable_unprepare respectively.

Change-Id: Ieaa5b62d58c153ac70c5d221888860231fedcf4e
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim_msm: Provision to support RX using interrupts if BAM fails

If BAM registration fails or BAM pipe connection for slimbus-RX pipe
fails, driver falls back on using RX through CSRs and interrupts.

Change-Id: Icb621468a227cb826db43695fa74b30452fbf9c1
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Scheduling algorithm should ensure non-zero channel-offset

Messaging slots are at the beginning of a slimbus superframe.
A channel cannot start at offset 0 in the superframe to ensure
messaging space gets non-zero slots.
Make sure channel scheduling algorithm leaves some slots for message
space.

Change-Id: I25dd3703b1ae331f4b8017b9ca92410f5811088c
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Modify check for empty slots

There was a corner case where the open slot count was going -ve
indicating that there are no slots left for messaging. The current
check to ensure non-zero messaging slots does not take that into
account. This commit fixes that check.

CRs-fixed: 370229
Change-Id: I832ce0a26f1919d3d03b4ef0311603a5a778685e
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Disconnect source port if source end is removed by client

If source end of a channel removes its vote, it should be allowed to
be reclaimed by other client (or by other source port by same client)
who wants to be the source for this channel.

CRs-Fixed: 376731
Change-Id: Ia30c6a4b07de7df98cde8bc928205b4f4598036d
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Export clock pause function

Previously this function was left-out to be exported by mistake.
Exporting the function helps any caller driver to be a module.

Change-Id: I2b9caca62821caea5ae92123689c6f8ddf2b207a
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Fix channel concurrent usage during reconfiguration sequence

Reconfiguration sequence can lead to changes in channel segment
distribution and state. Since multiple clients can use 1 channel,
make sure channels cannot be manipulated when reconfiguration
sequence is in progress, and make sure that client doesn't send
reconfiguration sequence when no changes are pending to be sent
in the sequence from it.

CRs-Fixed: 383406
Change-Id: Ib5f0bc32f67f51f118fa417a2e580c8dc87ef0d0
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim_msm: Keep track of satellite reconfiguring a channel

With mutiple clients able to use the same channel, it is not correct
assumption that a channel was active due to satellite client's
reconfiguration only. So during sub-system restart of a satellite,
rely on satellite-reconfiguration vote for a channel instead of
channel status to remove channels that were setup by the satellite
before sub-system restart.

CRs-Fixed: 389514
Change-Id: I825381f15cb55396fece5b390d395c7f0a7580ff
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
slimbus: Decrement channel reference during reconfigure now

Slimbus clients can specify multiple add/remove channel requests
through control_ch API, followed by reconfiguration request (also
known as "commit request"). Clients may rely on the reconfiguration
request to actuate the channel activation/removal and not the
control-channel API.
So the channel reference should be decremented during reconfiguration
request, and not control_ch API.

CRs-Fixed: 389518
Change-Id: Id6ff57c6a4cad878e35004937fb08daf3b9afe7b
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

Conflicts:

	drivers/slimbus/slimbus.c

Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
mako: slimbus: fix the duplicated slimbus code

There were duplicated codes to check whether there are pending changes

Change-Id: I4554c6be94c42f236f487e335fa1dbe71b970c12
slimbus: clear slimbus read transaction if synchronous read fails

Failed read transaction is removed from the table of active transactions if the
transaction fails.

Signed-off-by: SathishKumar Mani <smani@codeaurora.org>
Signed-off-by: Iliyan Malchev <malchev@google.com>
slim_msm: Satellite channel should not be deallocated more than once

It is possible that satellite channel deallocation is requested more
than once. (e.g. if the satellite times out waiting for response from
previous removal, then it will request removal again during
channel deallocation from its side).
Make sure that does not result in deallocating the channel more than
once.

Signed-off-by: SathishKumar Mani <smani@codeaurora.org>
slimbus: Avoid same channel definition, removal in same sequence

Do not add the channel removal request to the remove list
when the client sends it right after the channel definition
without sending reconfigure_now request. Also remove the
channel define request from define list. This avoids
channel definition count being inconsistent, which may
lead to slimbus driver going into wrong state.

Signed-off-by: SathishKumar Mani <smani@codeaurora.org>
slim_msm: don't call completion after timeout

making the completion pointer to NULL, if the timeout
occurs before firing the interrupt. This is to avoid
calling the complete function from the interrupt
handler, if the interrupt fires after completion
timeout. It's from QCT

Change-Id: I31d4a74297e670711041d866de55e1b5350575c1

Conflicts:

	drivers/slimbus/slim-msm-ctrl.c
slim_msm: Retry initial sequence messages

Initial sequence messages (logical address assignment, and master
capability message) are very important messages to enable the
devices. It is possible that the device may NACK these messages
initially if it is in process of acquiring sync.
If these type of messages fail, retry a few times before actually
deeming the device unresponsive. Log the registers in case of NACKs
to better analyze the reason.

Signed-off-by: SathishKumar Mani <smani@codeaurora.org>