[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <875xsk8e2z.fsf@kernel.org>
Date: Thu, 01 Aug 2024 18:20:20 +0300
From: Kalle Valo <kvalo@...nel.org>
To: "Mark Pearson" <mpearson-lenovo@...ebb.ca>
Cc: "Baochen Qiang" <quic_bqiang@...cinc.com>, ath12k@...ts.infradead.org,
linux-wireless@...r.kernel.org, kernel@...cinc.com,
netdev@...r.kernel.org
Subject: Re: [PATCH] wifi: ath12k: use 128 bytes aligned iova in transmit
path for WCN7850
"Mark Pearson" <mpearson-lenovo@...ebb.ca> writes:
> On Sun, Jul 14, 2024, at 10:38 PM, Baochen Qiang wrote:
>
>> In transmit path, it is likely that the iova is not aligned to PCIe TLP
>> max payload size, which is 128 for WCN7850. Normally in such cases hardware
>> is expected to split the packet into several parts in a manner such that
>> they, other than the first one, have aligned iova. However due to hardware
>> limitations, WCN7850 does not behave like that properly with some specific
>> unaligned iova in transmit path. This easily results in target hang in a
>> KPI transmit test: packet send/receive failure, WMI command send timeout
>> etc. Also fatal error seen in PCIe level:
>>
>> ...
>> Capabilities: ...
>> ...
>> DevSta: ... FatalErr+ ...
>> ...
>> ...
>>
>> Work around this by manually moving/reallocating payload buffer such that
>> we can map it to a 128 bytes aligned iova. The moving requires sufficient
>> head room or tail room in skb: for the former we can do ourselves a favor
>> by asking some extra bytes when registering with mac80211, while for the
>> latter we can do nothing.
>>
>> Moving/reallocating buffer consumes additional CPU cycles, but the good news
>> is that an aligned iova increases PCIe efficiency. In my tests on some X86
>> platforms the KPI results are almost consistent.
>>
>> Since this is seen only with WCN7850, add a new hardware parameter to
>> differentiate from others.
>>
>> Tested-on: WCN7850 hw2.0 PCI
>> WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
>>
>> Signed-off-by: Baochen Qiang <quic_bqiang@...cinc.com>
>
> We've tested this in the Lenovo lab using the T14 G5 AMD with a
> 6.10.0-rc7+ kernel from wireless-next and this patch applied.
> Previously we had stability issues under traffic load. With the patch
> applied we can no longer reproduce the issue.
>
> Tested-by: Mark Pearson <mpearson-lenovo@...ebb.ca>
>
> Can this be tagged for stable backporting? It's an important fix.
I added cc stable to the commit message. I forgot to do it before I
pushed my changes out, but it's in my local branch.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Powered by blists - more mailing lists