On Fri, Mar 31, 2023 at 10:31:25AM -0400, Jonathan Bither wrote:
On 3/31/23 08:10, Sascha Hauer wrote:
The RTW88 chipsets have four different priority queues in hardware. For the USB type chipsets the packets destined for a specific priority queue must be sent through the endpoint corresponding to the queue. This was not fully understood when porting from the RTW88 USB out of tree driver and thus violated.
This patch implements the qsel to endpoint mapping as in get_usb_bulkout_id_88xx() in the downstream driver.
Without this the driver often issues "timed out to flush queue 3" warnings and often TX stalls completely.
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de
drivers/net/wireless/realtek/rtw88/usb.c | 70 ++++++++++++++++-------- 1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c index 2a8336b1847a5..a10d6fef4ffaf 100644 --- a/drivers/net/wireless/realtek/rtw88/usb.c +++ b/drivers/net/wireless/realtek/rtw88/usb.c @@ -118,6 +118,22 @@ static void rtw_usb_write32(struct rtw_dev *rtwdev, u32 addr, u32 val) rtw_usb_write(rtwdev, addr, val, 4); } +static int dma_mapping_to_ep(enum rtw_dma_mapping dma_mapping) +{
- switch (dma_mapping) {
- case RTW_DMA_MAPPING_HIGH:
return 0;- case RTW_DMA_MAPPING_NORMAL:
return 1;- case RTW_DMA_MAPPING_LOW:
return 2;- case RTW_DMA_MAPPING_EXTRA:
return 3;- default:
return -EINVAL;- }
+}
Would it be beneficial to use defines for the returns? Would the USB_ENDPOINT_XFER_ defines be applicable?
The USB_ENDPOINT_XFER_* macros encode the type of the transfer, like bulk, control, isochronous and interrupt. What I need here really is the endpoint number. I don't see a benefit in adding a define here.
Sascha