msm: slimbus: various change

msm: slimbus: remove default drivers

slimbus: Add Qualcomm Slimbus driver

Signed-off-by: David Brown <davidb@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>

slim:msm: Change to register access for RX path if required

MSM controller for slimbus usually uses a BAM pipe to receive control
data. However, some targets may not have a BAM pipe assinged for
receiving this data. In that case, RX data should be received using
direct register access instead.
Introduce a Device-Tree property to change this access.

Change-Id: I9bb1502f25e0e855937bc6fb4131f55348d04794
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>

slimbus: Callback to indicate device report present message

Clients can register a callback (just like probe) and that callback
will be called when the client's device reports present per slimbus
specification. The callback is hosted in a workqueue to avoid doing
it in same context from which probe is called (and/or in the context
receiving report present message). Callback is called when the device
reports present for the first time after the bus is initialized.

Change-Id: I8396b87121950f99a09764d497bf2d4b1535565d
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slim: msm: Control interface clock if it's specified

Some platforms (e.g. 8974) have interface clock that is not ON by
default. Turn it ON during probe, and control it like core clock
if it needs to be controlled.

Change-Id: Ifffb4b7ea9afb5f3f1208b4b2b6638594ffca541
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slimbus: Add slave devices to controller after controller HW is up

Register controller is only responsible for making sure slimbus
controller structure is initialized with framework. This should not
assume that slimbus controller's hardware programming is done (e.g. if
slave's probe is trying to get logical address, then that will fail if
controller is registered, but slimbus hardware programming is not
complete, since probe is called synchrounously when device is added.
So this API separates register controller from slave device
registration. It should be called by controller when its hardware
programming is complete.

Change-Id: I52fa5567fc072951c89f99c70507aa3b1e4e22af
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slimbus: Defer probing slimbus until ADSP is ready

If slimbus master resides in ADSP, slimbus driver has to wait until it's
up and running.  Do probe deferral until ADSP is ready.

Change-Id: I31ba4e270331c3b5250758f604d0d0cde9537427
Signed-off-by: Joonwoo Park <joonwoop@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>

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>

slimbus: Clear slimbus read transaction if synchronous read fails

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

CRs-fixed: 396237
Change-Id: Idda4d8b5fa2cdfde8a049cc4af4d92e9e57f678a
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

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.

CRs-fixed: 396230
Change-Id: If0824f7ba962dbce068756e810a7bad8342373ec
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

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.

CRs-fixed: 395926
Change-Id: I002635849bcaa7309de1fbddf1127c456bca6f20
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slim_msm: Move out common functionality from MSM controller driver

Starting with new platforms, MSM slimbus controller can operate in
master mode or satellite mode. (Not in both modes for the same build)
Move out common functional code from the controller driver that can
be reused by satellite mode and master mode.

Change-Id: Idbc3fa93067f67f645981071ff6ad457c284576f
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slimbus: Allow controller to override default scheduling algorithm

Framework provides a slimbus scheduling algorithm and controller may
choose to override it. e.g. controller will override this if it
supports fixed set of channels at a fixed clock gear.
In that case, it is controller's responsibility to act on client
requests and update channel scheduling, subframe coding information.

Change-Id: I31fe72ef85f931900467b737652da7516d173dc5
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slimbus: Allow controller to specify logical addresses

It is possible that the controller has fixed addressing table for
enumeration devices. In that case, logical address will be set by
controller and not by framework. get_laddr allows a controller to
assign logical address. Make sure framework allows such addressing
by not assuming that index into address table will represent logical
address.

Change-Id: I0e3873980c2ee2ece01237f450ecefff4e99aedc
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slim_msm: Allow remote management of pipes for MSM slimbus BAM

Slimbus BAM may not be locally owned and/or controlled. In that case,
a remote processor (e.g. LPASS) configures BAM and sets security
configurations for the BAM pipes.
Allow driver to choose whether BAM is locally or remotely managed.

Change-Id: I10741cb394428f525c1633e707e88e699aa63cf5
Signed-off-by: Sagar Dharia <sdharia@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.

CRs-fixed: 409161
Change-Id: Iec4dd51d98416b7d769176bb1ef6cd2f5bacfa12
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>

slim_ngd: Slimbus satellite controller driver

NGD (non-ported generic device, also known as satellite device) is
used to implement light-weight slimbus controller driver.
This driver is responsible for:
1. Communicating with codec (or any slimbus slave registered from
application processor side) directly using slimbus HW messaging
interface.
2. Communicating with the manager device (controller by master driver)
on LPASS to do bandwidth and data channel management. NGD takes these
requests from slimbus slave on application processor side and passes
them to the manager device using slimbus messaging itself.
SPS BAM is used for receiving messages to offload CPU, and to enable
receiving multiple messages before driver can process them.
Runtime-pm is used for power management. Controller is in active
power state when messaging and/or data-channels are active from
application processor side.

Change-Id: Iff53c0ca9b768a3dac3bccb5004fd2f96070af50
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slilmbus: remove some functions that are incompatible with the current setup
we do not have the same qdsp6v2 files as the hammerhead so this will not work

Signed-off-by: poondog <markj338@gmail.com>

slimbus: remove this too

Signed-off-by: poondog <markj338@gmail.com>

slim_msm: Fix unsafe locking in msm_sat_enqueue()

msm_sat_enqueue() calls spin_lock() and msm_sat_dequeue() calls
spin_lock_irqsave(). This leads to lockdep warnings about the
same lock being taken in interrupts on and interrupts off context
which can lead to a potential deadlock.

=================================
[ INFO: inconsistent lock state ]
3.4.0+ #382 Tainted: G        W
---------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
kworker/u:2/94 [HC1[1]:SC0[0]:HE0:SE1] takes:
 (&(&sat->lock)->rlock){?.+...}, at: [<c0348b80>] msm_sat_enqueue+0x20/0xb0
{HARDIRQ-ON-W} state was registered at:
  [<c00bd290>] __lock_acquire+0x664/0x8d8
  [<c00bd690>] lock_acquire+0x18c/0x1e8
  [<c06989a4>] _raw_spin_lock+0x38/0x48
  [<c0348b80>] msm_sat_enqueue+0x20/0xb0
  [<c0349338>] msm_slim_rxwq+0x278/0x42c
  [<c0349580>] msm_slim_rx_msgq_thread+0x94/0x1f8
  [<c008e480>] kthread+0x90/0xa0
  [<c000f438>] kernel_thread_exit+0x0/0x8
irq event stamp: 24219
hardirqs last  enabled at (24218): [<c0699188>] _raw_spin_unlock_irqrestore+0x3c/0x68
hardirqs last disabled at (24219): [<c06993f4>] __irq_svc+0x34/0x78
softirqs last  enabled at (24129): [<c00738a8>] irq_exit+0x54/0xa8
softirqs last disabled at (24108): [<c00738a8>] irq_exit+0x54/0xa8

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&sat->lock)->rlock);
  <Interrupt>
    lock(&(&sat->lock)->rlock);

 *** DEADLOCK ***

3 locks held by kworker/u:2/94:
 #0:  ((sat->satcl.name)){.+.+.+}, at: [<c0087124>] process_one_work+0x1e8/0x648
 #1:  ((&sat->wd)){+.+.+.}, at: [<c0087124>] process_one_work+0x1e8/0x648
 #2:  (&dev->tx_lock){+.+...}, at: [<c0349cac>] msm_xfer_msg+0xb4/0x51c

stack backtrace:
[<c00151b0>] (unwind_backtrace+0x0/0x120) from [<c00b9d48>] (print_usage_bug+0x258/0x2c0)
[<c00b9d48>] (print_usage_bug+0x258/0x2c0) from [<c00ba12c>] (mark_lock+0x37c/0x68c)
[<c00ba12c>] (mark_lock+0x37c/0x68c) from [<c00bd20c>] (__lock_acquire+0x5e0/0x8d8)
[<c00bd20c>] (__lock_acquire+0x5e0/0x8d8) from [<c00bd690>] (lock_acquire+0x18c/0x1e8)
[<c00bd690>] (lock_acquire+0x18c/0x1e8) from [<c06989a4>] (_raw_spin_lock+0x38/0x48)
[<c06989a4>] (_raw_spin_lock+0x38/0x48) from [<c0348b80>] (msm_sat_enqueue+0x20/0xb0)
[<c0348b80>] (msm_sat_enqueue+0x20/0xb0) from [<c0348dc8>] (msm_slim_interrupt+0x1b8/0x4b0)
[<c0348dc8>] (msm_slim_interrupt+0x1b8/0x4b0) from [<c00d2ccc>] (handle_irq_event_percpu+0x118/0x3a4)
[<c00d2ccc>] (handle_irq_event_percpu+0x118/0x3a4) from [<c00d2f94>] (handle_irq_event+0x3c/0x5c)
[<c00d2f94>] (handle_irq_event+0x3c/0x5c) from [<c00d5c4c>] (handle_fasteoi_irq+0xd0/0x11c)
[<c00d5c4c>] (handle_fasteoi_irq+0xd0/0x11c) from [<c00d2ae4>] (generic_handle_irq+0x24/0x2c)
[<c00d2ae4>] (generic_handle_irq+0x24/0x2c) from [<c000f370>] (handle_IRQ+0x7c/0xc0)
[<c000f370>] (handle_IRQ+0x7c/0xc0) from [<c0008774>] (gic_handle_irq+0x6c/0xc4)
[<c0008774>] (gic_handle_irq+0x6c/0xc4) from [<c0699404>] (__irq_svc+0x44/0x78)
Exception stack(0xee061cd8 to 0xee061d20)
1cc0:                                                       00000001 eebda7c8
1ce0: 00000000 eebda400 20000013 c12b5430 ec96c168 c12b542c c12b5430 00000001
1d00: 20000013 ee061e14 3eb13eb1 ee061d20 c00ba520 c069918c 20000013 ffffffff
[<c0699404>] (__irq_svc+0x44/0x78) from [<c069918c>] (_raw_spin_unlock_irqrestore+0x40/0x68)
[<c069918c>] (_raw_spin_unlock_irqrestore+0x40/0x68) from [<c0279f2c>] (__debug_object_init+0x30c/0x344)
[<c0279f2c>] (__debug_object_init+0x30c/0x344) from [<c007b068>] (init_timer_on_stack_key+0x18/0x30)
[<c007b068>] (init_timer_on_stack_key+0x18/0x30) from [<c0695248>] (schedule_timeout+0x8c/0x4c0)
[<c0695248>] (schedule_timeout+0x8c/0x4c0) from [<c069768c>] (wait_for_common+0xec/0x164)
[<c069768c>] (wait_for_common+0xec/0x164) from [<c0349fc4>] (msm_xfer_msg+0x3cc/0x51c)
[<c0349fc4>] (msm_xfer_msg+0x3cc/0x51c) from [<c034a358>] (slim_sat_rxprocess+0x244/0x664)
[<c034a358>] (slim_sat_rxprocess+0x244/0x664) from [<c0087290>] (process_one_work+0x354/0x648)
[<c0087290>] (process_one_work+0x354/0x648) from [<c0089754>] (worker_thread+0x1a8/0x2a8)
[<c0089754>] (worker_thread+0x1a8/0x2a8) from [<c008e480>] (kthread+0x90/0xa0)
[<c008e480>] (kthread+0x90/0xa0) from [<c000f438>] (kernel_thread_exit+0x0/0x8)

Make this lock irqsafe as well so that this potential bug doesn't
occur.

Change-Id: Icbef6d1d749ee6ee81b079e19e57f22c38f00c68
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

slimbus: Specify number of channels for the group in group handle

Use group handle instead of next element in channel's data structure
to identify how many channels were specified by a client in the group.
That way clients can specify different number of channels for shared
channels, and work with their own client-handle. Note that sequence of
channel still matters (so 2 clients sharing a channel should not
specify channels in different order, otherwise scheduling of the
channels will not be in the correct order)

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

slimbus: Populate slimbus device's logical address during assignment

Slimbus device is assigned logical address when it reports present.
Make sure to populate the device's logical address (laddr) during
this assignment.

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

slim_ngd: Rectify define, removal messages per protocol

Populate required bits only as client handle while sending
channel define, removal messages to the master driver.
Previously, complete logical address was set as client handle
which would corrupt other fields in that byte if logical
address had non-zero MSBs. This patch fixes that problem.

Change-Id: I96e8a7917c1fe68e1c86f6837c0b9f8ee187ca3d
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slimbus: Refine scope of controller and scheduler mutex locks

Controller mutex scope is restricted to controller specific data
structures, such as addressing table, transaction table.
Scheduler lock is used to protect scheduling data structures (such
as channels, and bandwidth).
This way, controller mutex is not needed when expensive
reconfiguration sequence(used for channel scheduling, bandwidth
management) is in progress. Transactions over messaging channel (such
as element read/writes, logical address assignment) can happen in
parallel and don't have to block on reconfiguration sequence which
only affects data channels.

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

slimbus: Add slimbus device driver unregistration function

slim_driver_unregister is added to reverse effects of
slim_driver_register. That way a slimbus device driver can be
registered when driver module is loaded, and unregistered when
the driver module is unloaded.

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

slim_msm: Reading the smaller length messages properly

If the smaller length messages(<= 4 Bytes) like REPORT_ABSENT
are received over slimbus, the master driver is reading the
excessive length than required. Due to that the next messages
over slimbus are getting corrupted. This patch fixes this issue
and also handles the REPORT_ABSENT message sent by the third party
slimbus client devices.

CRs-Fixed: 431529
Change-Id: I7b3c07a94603482a6a9a7645ade70228144703bc
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>

slimbus: Handle channel control correctly if controller manages BW

If bandwidth allocation is managed by controller (and not framework),
channel control commands from all clients should be sent to the
controller.

Change-Id: Ibdd27c35a48818efdd55a0a84c52fbb9671cdb77
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slim_ngd: Support reserving message bandwidth for clients

Message bandwidth can be reserved by clients to do message-intensive
transactions over Slimbus. While slimbus framework supports that,
NGD driver was missing corresponding code to send this request to
master driver on ADSP. This patch adds that support.

Change-Id: If6a340746816658ac0aa1b4bd7c2270205eb6d4a
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>

slim_ngd: Make sure transaction is not dereferenced after it's freed

Every read transaction over slimbus is a set of one transmit and one
receive. Receive part frees meta-data for the read transaction since
it is no longer needed, and the transaction-ID can be reused.
Make sure that the transmit function doesn't try to dereference the
transaction meta-data after possibly receiving a response.

CRs-fixed: 515802
Change-Id: Id736ad368d4944a6aabc89f4ff295d664bc5efa0
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>

slim-ngd: NULL pointer check for client buffer

There is the chance of passing NULL pointer by the client
during the Slimbus/Codec transactions. Hence add NULL
pointer check for client buffer aswell.

CRs-Fixed: 608324
Change-Id: I161e8f04401afebb64ed72d5f392a67feb6ec13a
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

slim_ngd: Add NULL pointer check apart from error check

Check against NULL pointer after allocating
the memory for msm_slim_ctrl structure pointer
dynamically to avoid unexpected crashes.

Earlier this pointer is checked only for error
codes. In this patch NULL pointer check is also
added.

Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

slim_msm: Report flow-error and mask apps slimbus port interrupts

Apps side slimbus ports may overflow/underflow if BAM pipes connected
to those ports don't have descriptors scheduled.
Report such errors and mask the port interrupts until BAM pipes have
descriptors scheduled to avoid interrupts firing multiple times.

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

slim_msm: Signal client's completion for per transfer notification

Slimbus ports are connected to BAM pipes and ports inform the pipe
when descriptor's data transfer is done. Clients queue a completion
per descrptor when that descriptor is processed. This completion will
get overwritten if client queues multiple descriptors. Use
per-transfer user-data as client's completion to avoid this problem.
This also reduces controller-driver involvement in data transfer.

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

slim_msm: Get platform-specific information from platform-data

Number of pipes available to application processor for data channels,
and product-code field of enumeration address needed for setting
these pipes can be different for different platforms.
Store this platform-specific information in platform-data, and get
it from Device-Tree if applicable.

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

Slimbus: Correct the conditional check during channel removal

Use actual channel number to check if the channel to be
removed is present in the define_chan list before removing
it, instead of using the internal channel number used by
the frame work.

Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

slim_ngd: Handle error flags before handling SENT flag

It's possible that error flags were set alongwith SENT flag for
TX transaction status. In such a scenario, error flag status should
be handled (and SENT flag should be cleared). Move error-flag
handling ahead of SENT flag handling to avoid interrupt being called
twice, and completion being set twice.

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

slimbus: Enable clients to send user messages to devices.

Slimbus protocol allows user messages of destination referred, or
source referred type to be sent to a slimbus device.
Provide framework to support such messages. Note that, controller
may not support all user messages.

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

slimbus: Use physical address type where physical address is used

Use physical address type for buffers using physical address.
(e.g. interaction with data-mover engine)

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

Slim_ngd: Modify waiting mechanism in kthread

wait_for_completion_timeout() is not a good option in
kthread as it leads to scheduling the kthread on the every timeout.
Hence modify it to wait_for_completion() from
wait_for_completion_timeout().

Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>

msm: slimbus: initial overclocking of slimbus

Increase
root freq from 11 (24.526MHz) to 31 max (27+MHz) which is the largest it will
take .Increase clock gear from 7 to 10 (max again)

This means SLIMbus will use its maximum potential to give the best audio quality for the hardware.
Takes advantage of both hardware and the mods from zeroinfinity, also opening the door for more things that were previously limited by this.
Researched and experimented by ZeroInfinity and Poondog

Signed-off-by: poondog <markj338@gmail.com>

msm: slimbus: Optimize overclocking of master component

msm: slimbus: enhancements mkII

This time we keep the root freq to 11.
If Root Freq is set at 11, 24,576MHz has the best compatibility for all present sampling rates (e.g, any sample rate can be converted, 48KHz to 96KHz, 44.1KHz to 96KHz, 48KHz to 128KHz etc.) Increasing the root frequency is likely to cause invalid present sample rate combinations which leads to audio glitches such as distortion. "A Natural Frequency is defined as a CLK frequency that allows a family of data rates to be supported. The different sample rate flows can be optimally supported by changing a particular Natural Frequency using the Clock Gear." I looked at a Clock Gear/RF table and it looks like CLK Gear 10 and RF 24,576MHz (Stock RF) is an excellent combination due to its compatibility towards every other sample rates.

ZeroInfinity/Poondog

Signed-off-by: ZeroInfinity <infinitezero345@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>

msm: slimbus: some more tweaks and added new freqs

Set ROOT_FREQ at 22, which is double what we had before.
According to some documents this is what we want for optimium audio quality
Forcec SLIM_RATE to 44.1KHz and 48KHz instead of much lower values.
This way it will be forced to run at these freqs to match the majority of audio files user will be playing.

ZeroInfinity/Poondog

Signed-off-by: ZeroInfinity <infinitezero345@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
Signed-off-by: Lens-F <tnoah12@gmail.com>

defconfig: enable SLIMBUS_MSM_NGD