On 4/28/2024 6:32 PM, Meiyong Yu wrote: > > >> On Apr 28, 2024, at 8:54 PM, Meiyong Yu <meiyong.yu@xxxxxxx> wrote: >> >> >> >>> On Apr 28, 2024, at 6:46 AM, Jeff Johnson <quic_jjohnson@xxxxxxxxxxx> wrote: >>> >>> On 4/27/2024 2:12 AM, Tamizh Chelvam Raja wrote: >>>> From: Venkateswara Naralasetty <quic_vnaralas@xxxxxxxxxxx> >>>> >>>> If STATUS_BUFFER_DONE is not set for a monitor status ring entry, >>>> we don't process the status ring until STATUS_BUFFER_DONE set >>>> for that status ring entry. >>>> >>>> During LMAC reset it may happen that hardware will not write >>>> STATUS_BUFFER_DONE tlv in status buffer, in that case we end up >>>> waiting for STATUS_BUFFER_DONE leading to backpressure on monitor >>>> status ring. >>>> >> >> Can you known the LMAC reset event, if you can known, you can set all the ring entry >> status to done after reset is done, and the logic of code will be more clear. >> Host unaware of this event as this is internal to hardware. And as per the suggestion we are reaping next entry and proceeding further on this. > > If sene of the LMAC reset event is asynchronous, You can do this: > 1) when LMAC init than set a value to the new add global variabe lmac_life_cycle_id > 2) before add tlv to ring, set lmac_life_cycle_id to tlv > 3) when LMAC reset event is trigger, increase the value of lmac_life_cycle_id > 4) when get the status of tlv in ring(must delay for same period to ensure the real send ring is already send), > check the value lmac_life_cycle_id in tlv, if it smaller than the global one set tlv status to DONE > > >>>> To fix the issue, when HP(Head Pointer) + 1 entry is peeked and if DMA >>>> is not done and if HP + 2 entry's DMA done is set, >>>> replenish HP + 1 entry and start processing in next interrupt. >>>> If HP + 2 entry's DMA done is not set, poll onto HP + 1 entry DMA >>>> done to be set. >>>> >>>> Also, during monitor attach HP points to the end of the ring and >>>> TP(Tail Pointer) points to the start of the ring. >>>> Using ath11k_hal_srng_src_peek() may result in processing invalid buffer >>>> for the very first interrupt. Since, HW starts writing buffer from TP. >>>> >>>> To avoid this issue call ath11k_hal_srng_src_next_peek() instead of >>>> calling ath11k_hal_srng_src_peek(). >>>> >>>> Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1 >>>> >>>> Reported-by: kernel test robot <lkp@xxxxxxxxx> >>>> Closes: https://lore.kernel.org/oe-kbuild-all/202303281719.CvnPkOiK-lkp@xxxxxxxxx/ >>> >>> I believe these are misleading. LKP didn't find the problem you are fixing, it >>> found a problem in the implementation of the patch. >>> So I would move these below the "---" so the LKP knows the issue it found is >>> fixed, but the git history isn't itself isn't misleading >>> >>>> Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@xxxxxxxxxxx> >>>> Co-developed-by: Tamizh Chelvam Raja <quic_tamizhr@xxxxxxxxxxx> >>>> Signed-off-by: Tamizh Chelvam Raja <quic_tamizhr@xxxxxxxxxxx> >>>> --- >>>> v3: >>>> * Rebased on top of ToT >>>> v2: >>>> * Fixed compilation warning Reported-by: kernel test robot <lkp@xxxxxxxxx> >>>> >>>> drivers/net/wireless/ath/ath11k/dp_rx.c | 88 ++++++++++++++++++++++--- >>>> drivers/net/wireless/ath/ath11k/hal.c | 14 ++++ >>>> drivers/net/wireless/ath/ath11k/hal.h | 2 + >>> >>> My Qualcomm Innovation Center copyright checker reports: >>> drivers/net/wireless/ath/ath11k/dp_rx.c copyright missing 2024 >>> drivers/net/wireless/ath/ath11k/hal.c copyright missing 2024 >>> >> > -- Tamizh
