All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ath10k: fix copy engine 5 destination ring stuck
@ 2016-09-21 10:58 ` Rajkumar Manoharan
  0 siblings, 0 replies; 4+ messages in thread
From: Rajkumar Manoharan @ 2016-09-21 10:58 UTC (permalink / raw)
  To: ath10k; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan, stable

Firmware is running watchdog timer for tracking copy engine ring index
and write index. Whenever both indices are stuck at same location for
given duration, watchdog will be trigger to assert target. While
updating copy engine destination ring write index, driver ensures that
write index will not be same as read index by finding delta between these
two indices (CE_RING_DELTA).

HTT target to host copy engine (CE5) is special case where ring buffers
will be reused and delta check is not applied while updating write index.
In rare scenario, whenever CE5 ring is full, both indices will be referring
same location and this is causing CE ring stuck issue as explained
above. This issue is originally reported on IPQ4019 during long hour stress
testing and during veriwave max clients testsuites. The same issue is
also observed in other chips as well. Fix this by ensuring that write
index is one less than read index which means that full ring is
available for receiving data.

Cc: stable@vger.kernel.org
Tested-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/ce.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 65d8d714e917..00d3f93058db 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -433,6 +433,13 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe *pipe, u32 nentries)
 	unsigned int nentries_mask = dest_ring->nentries_mask;
 	unsigned int write_index = dest_ring->write_index;
 	u32 ctrl_addr = pipe->ctrl_addr;
+	u32 cur_write_idx = ath10k_ce_dest_ring_write_index_get(ar, ctrl_addr);
+
+	/* Prevent CE ring stuck issue that will occur when ring is full.
+	 * Make sure that write index is 1 less than read index.
+	 */
+	if ((cur_write_idx + nentries)  == dest_ring->sw_index)
+		nentries -= 1;
 
 	write_index = CE_RING_IDX_ADD(nentries_mask, write_index, nentries);
 	ath10k_ce_dest_ring_write_index_set(ar, ctrl_addr, write_index);
-- 
2.10.0

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [PATCH] ath10k: fix copy engine 5 destination ring stuck
@ 2016-09-21 10:58 ` Rajkumar Manoharan
  0 siblings, 0 replies; 4+ messages in thread
From: Rajkumar Manoharan @ 2016-09-21 10:58 UTC (permalink / raw)
  To: ath10k; +Cc: stable, linux-wireless, Rajkumar Manoharan, rmanohar

Firmware is running watchdog timer for tracking copy engine ring index
and write index. Whenever both indices are stuck at same location for
given duration, watchdog will be trigger to assert target. While
updating copy engine destination ring write index, driver ensures that
write index will not be same as read index by finding delta between these
two indices (CE_RING_DELTA).

HTT target to host copy engine (CE5) is special case where ring buffers
will be reused and delta check is not applied while updating write index.
In rare scenario, whenever CE5 ring is full, both indices will be referring
same location and this is causing CE ring stuck issue as explained
above. This issue is originally reported on IPQ4019 during long hour stress
testing and during veriwave max clients testsuites. The same issue is
also observed in other chips as well. Fix this by ensuring that write
index is one less than read index which means that full ring is
available for receiving data.

Cc: stable@vger.kernel.org
Tested-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/ce.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 65d8d714e917..00d3f93058db 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -433,6 +433,13 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe *pipe, u32 nentries)
 	unsigned int nentries_mask = dest_ring->nentries_mask;
 	unsigned int write_index = dest_ring->write_index;
 	u32 ctrl_addr = pipe->ctrl_addr;
+	u32 cur_write_idx = ath10k_ce_dest_ring_write_index_get(ar, ctrl_addr);
+
+	/* Prevent CE ring stuck issue that will occur when ring is full.
+	 * Make sure that write index is 1 less than read index.
+	 */
+	if ((cur_write_idx + nentries)  == dest_ring->sw_index)
+		nentries -= 1;
 
 	write_index = CE_RING_IDX_ADD(nentries_mask, write_index, nentries);
 	ath10k_ce_dest_ring_write_index_set(ar, ctrl_addr, write_index);
-- 
2.10.0


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: ath10k: fix copy engine 5 destination ring stuck
  2016-09-21 10:58 ` Rajkumar Manoharan
@ 2016-09-28  9:48   ` Kalle Valo
  -1 siblings, 0 replies; 4+ messages in thread
From: Kalle Valo @ 2016-09-28  9:48 UTC (permalink / raw)
  To: Rajkumar Manoharan
  Cc: ath10k, stable, linux-wireless, Rajkumar Manoharan, rmanohar

Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> Firmware is running watchdog timer for tracking copy engine ring index
> and write index. Whenever both indices are stuck at same location for
> given duration, watchdog will be trigger to assert target. While
> updating copy engine destination ring write index, driver ensures that
> write index will not be same as read index by finding delta between these
> two indices (CE_RING_DELTA).
> 
> HTT target to host copy engine (CE5) is special case where ring buffers
> will be reused and delta check is not applied while updating write index.
> In rare scenario, whenever CE5 ring is full, both indices will be referring
> same location and this is causing CE ring stuck issue as explained
> above. This issue is originally reported on IPQ4019 during long hour stress
> testing and during veriwave max clients testsuites. The same issue is
> also observed in other chips as well. Fix this by ensuring that write
> index is one less than read index which means that full ring is
> available for receiving data.
> 
> Cc: stable@vger.kernel.org
> Tested-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

0628467f97b5 ath10k: fix copy engine 5 destination ring stuck

-- 
https://patchwork.kernel.org/patch/9343317/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ath10k: fix copy engine 5 destination ring stuck
@ 2016-09-28  9:48   ` Kalle Valo
  0 siblings, 0 replies; 4+ messages in thread
From: Kalle Valo @ 2016-09-28  9:48 UTC (permalink / raw)
  To: Rajkumar Manoharan; +Cc: rmanohar, linux-wireless, stable, ath10k

Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> Firmware is running watchdog timer for tracking copy engine ring index
> and write index. Whenever both indices are stuck at same location for
> given duration, watchdog will be trigger to assert target. While
> updating copy engine destination ring write index, driver ensures that
> write index will not be same as read index by finding delta between these
> two indices (CE_RING_DELTA).
> 
> HTT target to host copy engine (CE5) is special case where ring buffers
> will be reused and delta check is not applied while updating write index.
> In rare scenario, whenever CE5 ring is full, both indices will be referring
> same location and this is causing CE ring stuck issue as explained
> above. This issue is originally reported on IPQ4019 during long hour stress
> testing and during veriwave max clients testsuites. The same issue is
> also observed in other chips as well. Fix this by ensuring that write
> index is one less than read index which means that full ring is
> available for receiving data.
> 
> Cc: stable@vger.kernel.org
> Tested-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

0628467f97b5 ath10k: fix copy engine 5 destination ring stuck

-- 
https://patchwork.kernel.org/patch/9343317/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-09-28  9:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-21 10:58 [PATCH] ath10k: fix copy engine 5 destination ring stuck Rajkumar Manoharan
2016-09-21 10:58 ` Rajkumar Manoharan
2016-09-28  9:48 ` Kalle Valo
2016-09-28  9:48   ` Kalle Valo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.