Currently for WCN3990, the host driver can send two wmi commands at once,
now it is limiting to one because if HOST wants to initiate 2 DMA transfers,
it is possible when copy complete interrupt for first DMA reaches HOST,
CE has already updated SRRI for both DMA transfers and is in the middle
of 2nd DMA. HOST uses SRRI to interpret how many DMA’s have been completed
and tries to unmap/free both the DMA entries, but CE is still in the middle
of 2nd DMA which can cause SMMU issues or corruption.
We are seeing a corner case smmu fault issue where copy engine is still accessing
the memory though host unmaps it hence as work around we are delaying the
unmapping the memory and tx credit to one.
Youghandhar Chintala (2):
ath10k: Set tx credit to one for wcn3990 snoc based devices
ath10k: Delay the unmapping of the buffer
drivers/net/wireless/ath/ath10k/core.c | 30 ++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/htc.c | 18 +++++++++++++---
drivers/net/wireless/ath/ath10k/htc.h | 1 +
drivers/net/wireless/ath/ath10k/hw.h | 6 ++++++
4 files changed, 52 insertions(+), 3 deletions(-)
--
2.29.0
Hi,
On Thu, Jan 20, 2022 at 10:44 PM Youghandhar Chintala
<[email protected]> wrote:
>
> Currently for WCN3990, the host driver can send two wmi commands at once,
> now it is limiting to one because if HOST wants to initiate 2 DMA transfers,
> it is possible when copy complete interrupt for first DMA reaches HOST,
> CE has already updated SRRI for both DMA transfers and is in the middle
> of 2nd DMA. HOST uses SRRI to interpret how many DMA’s have been completed
> and tries to unmap/free both the DMA entries, but CE is still in the middle
> of 2nd DMA which can cause SMMU issues or corruption.
>
> We are seeing a corner case smmu fault issue where copy engine is still accessing
> the memory though host unmaps it hence as work around we are delaying the
> unmapping the memory and tx credit to one.
>
> Youghandhar Chintala (2):
> ath10k: Set tx credit to one for wcn3990 snoc based devices
> ath10k: Delay the unmapping of the buffer
>
> drivers/net/wireless/ath/ath10k/core.c | 30 ++++++++++++++++++++++++++
> drivers/net/wireless/ath/ath10k/htc.c | 18 +++++++++++++---
> drivers/net/wireless/ath/ath10k/htc.h | 1 +
> drivers/net/wireless/ath/ath10k/hw.h | 6 ++++++
> 4 files changed, 52 insertions(+), 3 deletions(-)
I don't understand the root cause here myself. I also don't have
enough skin in the game to say whether this is the best/cleanest way
to work around the problem. Thus I'll refrain from a Reviewed-by tag.
That being said, I did a bunch of testing of this solution and I also
am aware of others that have tested it. Thus I'm convinced that it at
least works around the problem that has been observed. Hence:
Tested-by: Douglas Anderson <[email protected]>
In my case I was on the same (or nearly the same) hardware as
Youghandhar, though I had a slightly older build. FWIW:
Tested-on: WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
-Doug