The current implementaion of data ports management
assumes that the ports are allocated contiguously,
which is not a correct assumption.
This patch addresses this limitation and handles
the data ports which are allocated non-contiguously.
Change-Id: I04e83bc525a50db4d0a37028498be848af018bb5
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Provide non-blocking write support so that clients can queue multiple
writes, or larger transfers without performance implications.
TX buffer is created and descriptors out of this buffer
are submitted to HW to transmit data.
Descriptor is returned to 'available' pool of TX buffer when HW
interrupt for transmission status is recieved.
Change-Id: Icc2af6bf4f770c8cadb9bd2ef7be0f95eb22c5d8
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
If slimbus controller overrides bandwidth management, channel slots
should not be managed since controller is expected to do that.
Slimbus controller will go into idle mode due to this change when
channel setup/teardown is done. Make sure controller can transition
states correctly in runtime-pm suspend, and system-suspend case.
Change-Id: Id41aed822e3c98af8c1fe7db3a3527a1206739be
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
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.
Change-Id: I9a0ee0f34231ce33e08bbc6dc6d0ed51a3aca9e0
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Since Manager's ports don't have any direction when allocated, make
sure the direction is not checked when connect-port is called on a
manager port. Ensure that controller's port resourced are freed-up
when dealloc_mgrports is called.
Change-Id: I588408276cbee020623666b08433b57475cf47cc
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Slimbus data port on apps side can be connected in any diretion (as
source, or as destination). BAM pipe connected to that port should
only be disconnected/reconnected if this port direction changes.
This helps with reducing calls to connect/disconnect BAM pipes.
Allocate descriptors to avoid getting descriptor-space from the
common pool and free them only when the port is deallocated.
Change-Id: Ie31acdb9e4c4bba12f1cc70d0c9ad7bf471b3056
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
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.
Change-Id: I4a2bf716ad0a9ee4f71c4ee36b84826b9d90e3b8
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
HW may NACK initial capability message if it was in process of
acquiring sync. Capability message is used to setup communication
between master and satellite and should not be lost due to NACKs.
Retry this message a few times before deeming master as unreachable.
CRs-fixed: 471340
Change-Id: Ifa805f299dcefc4ecc09db784dc236be28950747
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
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>
When slimbus on apps removes its QMI vote for slimbus on ADSP, it's
possible that ADSP may decide to do idle power collapse. During this,
slimbus HW and corresponding BAM HW will get reset.
While removing active vote from ADSP, BAM pipe for slimbus RX is
disconnected, so that it is not affected when the BAM HW on ADSP is
reset.
After sending QMI active vote to ADSP, driver checks HW state to
determine if the ADSP HW indeed was reset. If it was not reset, BAM
pipe is reconnected.
If it's deemed that the ADSP HW was reset, slimbus HW portion is
reprogrammed, communication with slimbus driver on ADSP is established
again using capability message. BAM pipe is reconnected at this time,
and slimbus is ready for use.
Change-Id: Ie0ad838e3790650f4f240fa7b78a2b8296316efd
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Slimbus manager HW is controlled from ADSP. When ADSP restarts, NGD
controller goes in inactive state, and BAM pipes are disconnected.
When ADSP comes up later, controller is re-initialized and all slaves
on this controller are re-assigned logical address. BAM pipes are
reconnected as well. These steps are done after ADSP slimbus HW
informs NGD controller that it has come up.
CRs-Fixed: 419384
Change-Id: Ic1ba1fe14adeb9661de3735a0afc8e4b05fa4606
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
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>
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 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Kiran Gunda