Re: [PATCH 00/11] SDIO support for ath10k
silexcom...@gmail.com writes: > From: Alagu Sankar > > This patchset, generated against master-pending branch, enables a fully > functional SDIO interface driver for ath10k. Patches have been verified on > QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, Access > Point > and P2P modes. > > The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1 > with the board data from respective SDIO card vendors. Receive performance > matches the QCA reference driver when used with SDIO3.0 enabled platforms. > iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s > > This patchset differs from the previous high latency patches, specific to > SDIO. > HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET is enabled for HI_ACS. This instructs > the > firmware to use HTT_T2H_MSG_TYPE_TX_COMPL_IND for outgoing packets. Without > this flag, the management frames are not sent out by the firmware. Possibility > of management frames being sent via WMI and data frames through the reduced Tx > completion needs to be probed further. > > Further improvements can be done on the transmit path by implementing packet > bundle. Scatter Gather is another area of improvement for both Transmit and > Receive, but may not work on all platforms > > Known issues: Surprise removal of the card, when the device is in connected > state, delays sdio function remove due to delayed WMI command failures. > Existing ath10k framework can not differentiate between a kernel module > removal and the surprise removal of teh card. > > Alagu Sankar (11): > ath10k_sdio: sdio htt data transfer fixes > ath10k_sdio: wb396 reference card fix > ath10k_sdio: DMA bounce buffers for read write > ath10k_sdio: reduce transmit msdu count > ath10k_sdio: use clean packet headers > ath10k_sdio: high latency fixes for beacon buffer > ath10k_sdio: fix rssi indication > ath10k_sdio: common read write > ath10k_sdio: virtual scatter gather for receive > ath10k_sdio: enable firmware crash dump > ath10k_sdio: hif start once addition Sorry, I run out of time to review this in detail. To make the review easier I recommend to split this patchset into two sets, first set containing only the bare essential to get basic functionality working (for example ping working on x86) and the second set containing all the optimisations (the bounce buffer stuff etc). And try to make the first set as small as possible so that we can get it faster applied. -- Kalle Valo
Re: [PATCH 00/11] SDIO support for ath10k
Gary Bisson writes: > On Fri, Oct 06, 2017 at 01:16:13PM +0200, Gary Bisson wrote: >> On Thu, Oct 05, 2017 at 10:54:26PM +0530, Alagu Sankar wrote: >> > On 05-10-2017 20:42, Gary Bisson wrote: >> > > >> > > First of all, thank you for sharing your patches, this will be a very >> > > nice improvement to have SDIO QCA9377 working with ath10k. >> > > >> > > I've tried your series with Nitrogen7 [1] platform which is supported in >> > > mainline already. It uses BD-SDMAC [2] which uses the same module as the >> > > SX-SDMAC. >> > > >> > > Below are some questions/remarks I have after the testing. >> > > >> > > Quick question on the firmware, is it the one from Kalle's repository?[3] >> > > >> > > If so, where does this firmware comes from? Is 00061 the firmware >> > > version? So far I've only seen up to v0.0.0.60, see qcacld-2.0 output: >> > > Host SW:4.5.20.037, FW:0.0.0.60, HW:QCA9377_REV1_1 >> > >> > Yes, it is from >> > https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested. >> > I have also used custom firmware from QCA/Silex as used in qcacld-2.0 >> > driver >> > without any issue. You need to use the firmware merger tool from >> > https://github.com/erstrom/linux-ath/wiki/Firmware to combine the >> > qwlan30.bin and otp30.bin to generate the firmware-sdio.bin. >> >> Good to know, thanks. Maybe Kalle can tell us more about the firmware >> itself, what's the difference between the version 0.0.0.60 and 0.0.0.61? > > Any update on this, is there a release notes for this 0.0.0.61 firmware? Unfortunately I don't have any changelogs for the firmware releases. > As a FYI, I've tried your ath10k patches (along with a few backported > patches from Erik) on the NXP-fork of 4.9 kernel [1]. > > I confirm that it provides pretty decent performances: > - ath10k: 110Mbit/s > - qcacld-2.0: 125Mbit/s > > Here are some details about the setup: > - TPLink AC router > - Nitrogen7 (i.MX7) with BD-SDMAC > - Kernel 4.9.68 (NXP fork [1]) > - FW 0.0.0.61 from ath10k-firmware repo Nice, thanks for the report. This is always helpful. -- Kalle Valo
Re: [PATCH 00/11] SDIO support for ath10k
Hi Alagu, On Fri, Oct 06, 2017 at 01:16:13PM +0200, Gary Bisson wrote: > Hi Alagu, > > On Thu, Oct 05, 2017 at 10:54:26PM +0530, Alagu Sankar wrote: > > Hi Gary, > > > > On 05-10-2017 20:42, Gary Bisson wrote: > > > Hi Alagu, > > > > > > First of all, thank you for sharing your patches, this will be a very > > > nice improvement to have SDIO QCA9377 working with ath10k. > > > > > > I've tried your series with Nitrogen7 [1] platform which is supported in > > > mainline already. It uses BD-SDMAC [2] which uses the same module as the > > > SX-SDMAC. > > > > > > Below are some questions/remarks I have after the testing. > > > > > > On Sat, Sep 30, 2017 at 11:07:37PM +0530, silexcommon at gmail.com wrote: > > > > From: Alagu Sankar > > > > > > > > This patchset, generated against master-pending branch, enables a fully > > > > functional SDIO interface driver for ath10k. Patches have been > > > > verified on > > > > QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, > > > > Access Point > > > > and P2P modes. > > > > > > > > The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1 > > > Quick question on the firmware, is it the one from Kalle's repository?[3] > > > > > > If so, where does this firmware comes from? Is 00061 the firmware > > > version? So far I've only seen up to v0.0.0.60, see qcacld-2.0 output: > > > Host SW:4.5.20.037, FW:0.0.0.60, HW:QCA9377_REV1_1 > > Yes, it is from > > https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested. > > I have also used custom firmware from QCA/Silex as used in qcacld-2.0 driver > > without any issue. You need to use the firmware merger tool from > > https://github.com/erstrom/linux-ath/wiki/Firmware to combine the > > qwlan30.bin and otp30.bin to generate the firmware-sdio.bin. > > Good to know, thanks. Maybe Kalle can tell us more about the firmware > itself, what's the difference between the version 0.0.0.60 and 0.0.0.61? Any update on this, is there a release notes for this 0.0.0.61 firmware? > > > > with the board data from respective SDIO card vendors. > > > About the board-sdio.bin, is it just a copy of your bdwlan30.bin? > > Yes board-sdio.bin is a copy of bdwlan30.bin > > Thanks for confirming it. > > > > > Receive performance > > > > matches the QCA reference driver when used with SDIO3.0 enabled > > > > platforms. > > > > iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s > > > Nice performances. Unfortunately I don't get better than 30Mbits/s in TX > > > and 50Mbits/s in RX: > > > # iperf -c 192.168.1.1 > > > > > > Client connecting to 192.168.1.1, TCP port 5001 > > > TCP window size: 43.8 KByte (default) > > > > > > [ 3] local 192.168.1.115 port 41354 connected with 192.168.1.1 port > > > 5001 > > > [ ID] Interval Transfer Bandwidth > > > [ 3] 0.0-10.0 sec 34.9 MBytes 29.2 Mbits/sec > > > # iperf -s > > > > > > Server listening on TCP port 5001 > > > TCP window size: 85.3 KByte (default) > > > > > > [ 4] local 192.168.1.115 port 5001 connected with 192.168.1.1 port > > > 50646 > > > [ ID] Interval Transfer Bandwidth > > > [ 4] 0.0-10.0 sec 63.1 MBytes 52.7 Mbits/sec > > > > > > Do you have any idea why? Note that qcacld-2.0 driver on that same > > > platform (same OS) gives the performances you advertize (150Mbits/s). > > For some reason, if I use the imx_v6_v7_defconfig as is, performance is very > > poor. In fact, the firmware download itself will take about 6 seconds. This > > can also be seen when you up/down the wlan0 interface. For the i.MX6 SoloX > > board, I used the configuration of 4.1.15 as provided by the BSP from > > NXP/Freescale. > > Do you mean that you've used 4.1.15 kernel or just the 4.1.15 > configuration on latest 4.14? As a FYI, I've tried your ath10k patches (along with a few backported patches from Erik) on the NXP-fork of 4.9 kernel [1]. I confirm that it provides pretty decent performances: - ath10k: 110Mbit/s - qcacld-2.0: 125Mbit/s Here are some details about the setup: - TPLink AC router - Nitrogen7 (i.MX7) with BD-SDMAC - Kernel 4.9.68 (NXP fork [1]) - FW 0.0.0.61 from ath10k-firmware repo It is definitely a nice alternative to qcacld driver. When do you plan on sending a v2 out? Regards, Gary [1] https://github.com/boundarydevices/linux-imx6/commits/test-ath10k
Re: [PATCH 00/11] SDIO support for ath10k
Hi Alagu, On Thu, Oct 05, 2017 at 10:54:26PM +0530, Alagu Sankar wrote: > Hi Gary, > > On 05-10-2017 20:42, Gary Bisson wrote: > > Hi Alagu, > > > > First of all, thank you for sharing your patches, this will be a very > > nice improvement to have SDIO QCA9377 working with ath10k. > > > > I've tried your series with Nitrogen7 [1] platform which is supported in > > mainline already. It uses BD-SDMAC [2] which uses the same module as the > > SX-SDMAC. > > > > Below are some questions/remarks I have after the testing. > > > > On Sat, Sep 30, 2017 at 11:07:37PM +0530, silexcommon at gmail.com wrote: > > > From: Alagu Sankar > > > > > > This patchset, generated against master-pending branch, enables a fully > > > functional SDIO interface driver for ath10k. Patches have been verified > > > on > > > QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, Access > > > Point > > > and P2P modes. > > > > > > The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1 > > Quick question on the firmware, is it the one from Kalle's repository?[3] > > > > If so, where does this firmware comes from? Is 00061 the firmware > > version? So far I've only seen up to v0.0.0.60, see qcacld-2.0 output: > > Host SW:4.5.20.037, FW:0.0.0.60, HW:QCA9377_REV1_1 > Yes, it is from > https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested. > I have also used custom firmware from QCA/Silex as used in qcacld-2.0 driver > without any issue. You need to use the firmware merger tool from > https://github.com/erstrom/linux-ath/wiki/Firmware to combine the > qwlan30.bin and otp30.bin to generate the firmware-sdio.bin. Good to know, thanks. Maybe Kalle can tell us more about the firmware itself, what's the difference between the version 0.0.0.60 and 0.0.0.61? > > > with the board data from respective SDIO card vendors. > > About the board-sdio.bin, is it just a copy of your bdwlan30.bin? > Yes board-sdio.bin is a copy of bdwlan30.bin Thanks for confirming it. > > > Receive performance > > > matches the QCA reference driver when used with SDIO3.0 enabled platforms. > > > iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s > > Nice performances. Unfortunately I don't get better than 30Mbits/s in TX > > and 50Mbits/s in RX: > > # iperf -c 192.168.1.1 > > > > Client connecting to 192.168.1.1, TCP port 5001 > > TCP window size: 43.8 KByte (default) > > > > [ 3] local 192.168.1.115 port 41354 connected with 192.168.1.1 port > > 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 34.9 MBytes 29.2 Mbits/sec > > # iperf -s > > > > Server listening on TCP port 5001 > > TCP window size: 85.3 KByte (default) > > > > [ 4] local 192.168.1.115 port 5001 connected with 192.168.1.1 port > > 50646 > > [ ID] Interval Transfer Bandwidth > > [ 4] 0.0-10.0 sec 63.1 MBytes 52.7 Mbits/sec > > > > Do you have any idea why? Note that qcacld-2.0 driver on that same > > platform (same OS) gives the performances you advertize (150Mbits/s). > For some reason, if I use the imx_v6_v7_defconfig as is, performance is very > poor. In fact, the firmware download itself will take about 6 seconds. This > can also be seen when you up/down the wlan0 interface. For the i.MX6 SoloX > board, I used the configuration of 4.1.15 as provided by the BSP from > NXP/Freescale. Do you mean that you've used 4.1.15 kernel or just the 4.1.15 configuration on latest 4.14? > This improved the performance quite a bit. I haven't had a > chance to spend time on this to figure out the difference and reason. > Another difference is that the default device tree for SoloX did not have > the correct settings to support SDIO3.x. Had to modify them, but did not > include the device tree patches here as it is not meant for this group. Doh! That's why I don't get better performances, my platform limits the SDIO bus to 50MHz right now. Unfortunately SDIO3.0 doesn't seem stable on i.MX7, it is missing a few patches, I'll start a thread with Shawn/Fabio about it. > > > This patchset differs from the previous high latency patches, specific to > > > SDIO. > > > HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET is enabled for HI_ACS. This > > > instructs the > > > firmware to use HTT_T2H_MSG_TYPE_TX_COMPL_IND for outgoing packets. > > > Without > > > this flag, the management frames are not sent out by the firmware. > > > Possibility > > > of management frames being sent via WMI and data frames through the > > > reduced Tx > > > completion needs to be probed further. > > > > > > Further improvements can be done on the transmit path by implementing > > > packet > > > bundle. Scatter Gather is another area of improvement for both Transmit > > > and > > > R
Re: [PATCH 00/11] SDIO support for ath10k
Hi Gary, On 05-10-2017 20:42, Gary Bisson wrote: Hi Alagu, First of all, thank you for sharing your patches, this will be a very nice improvement to have SDIO QCA9377 working with ath10k. I've tried your series with Nitrogen7 [1] platform which is supported in mainline already. It uses BD-SDMAC [2] which uses the same module as the SX-SDMAC. Below are some questions/remarks I have after the testing. On Sat, Sep 30, 2017 at 11:07:37PM +0530, silexcommon at gmail.com wrote: From: Alagu Sankar This patchset, generated against master-pending branch, enables a fully functional SDIO interface driver for ath10k. Patches have been verified on QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, Access Point and P2P modes. The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1 Quick question on the firmware, is it the one from Kalle's repository?[3] If so, where does this firmware comes from? Is 00061 the firmware version? So far I've only seen up to v0.0.0.60, see qcacld-2.0 output: Host SW:4.5.20.037, FW:0.0.0.60, HW:QCA9377_REV1_1 Yes, it is from https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested. I have also used custom firmware from QCA/Silex as used in qcacld-2.0 driver without any issue. You need to use the firmware merger tool from https://github.com/erstrom/linux-ath/wiki/Firmware to combine the qwlan30.bin and otp30.bin to generate the firmware-sdio.bin. with the board data from respective SDIO card vendors. About the board-sdio.bin, is it just a copy of your bdwlan30.bin? Yes board-sdio.bin is a copy of bdwlan30.bin Receive performance matches the QCA reference driver when used with SDIO3.0 enabled platforms. iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s Nice performances. Unfortunately I don't get better than 30Mbits/s in TX and 50Mbits/s in RX: # iperf -c 192.168.1.1 Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 43.8 KByte (default) [ 3] local 192.168.1.115 port 41354 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 34.9 MBytes 29.2 Mbits/sec # iperf -s Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) [ 4] local 192.168.1.115 port 5001 connected with 192.168.1.1 port 50646 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 63.1 MBytes 52.7 Mbits/sec Do you have any idea why? Note that qcacld-2.0 driver on that same platform (same OS) gives the performances you advertize (150Mbits/s). For some reason, if I use the imx_v6_v7_defconfig as is, performance is very poor. In fact, the firmware download itself will take about 6 seconds. This can also be seen when you up/down the wlan0 interface. For the i.MX6 SoloX board, I used the configuration of 4.1.15 as provided by the BSP from NXP/Freescale. This improved the performance quite a bit. I haven't had a chance to spend time on this to figure out the difference and reason. Another difference is that the default device tree for SoloX did not have the correct settings to support SDIO3.x. Had to modify them, but did not include the device tree patches here as it is not meant for this group. This patchset differs from the previous high latency patches, specific to SDIO. HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET is enabled for HI_ACS. This instructs the firmware to use HTT_T2H_MSG_TYPE_TX_COMPL_IND for outgoing packets. Without this flag, the management frames are not sent out by the firmware. Possibility of management frames being sent via WMI and data frames through the reduced Tx completion needs to be probed further. Further improvements can be done on the transmit path by implementing packet bundle. Scatter Gather is another area of improvement for both Transmit and Receive, but may not work on all platforms Known issues: Surprise removal of the card, when the device is in connected state, delays sdio function remove due to delayed WMI command failures. Existing ath10k framework can not differentiate between a kernel module removae and the surprise removal of teh card. Here are some questions: - Is it normal to see a warning about board-2.bin, shouldn't it look for board-sdio.bin only? [ 14.696704] ath10k_sdio mmc1:0001:1: Direct firmware load for ath10k/QCA9377/hw1.0/board-2.bin failed with error -2 This was only noticed in the latest update. Like the different firmware versions, the driver also looks for the board-2.bin now. I have only tested with the board-sdio.bin - Did you have pre-cal and/or cal binaries for your testing? [ 14.067159] ath10k_sdio mmc1:0001:1: Direct firmware load for ath10k/pre-cal-sdio-mmc1:0001:1.bin failed with error -2 [ 14.149257] ath10k_sdio mmc1:0001:
Re: [PATCH 00/11] SDIO support for ath10k
Hi Alagu, First of all, thank you for sharing your patches, this will be a very nice improvement to have SDIO QCA9377 working with ath10k. I've tried your series with Nitrogen7 [1] platform which is supported in mainline already. It uses BD-SDMAC [2] which uses the same module as the SX-SDMAC. Below are some questions/remarks I have after the testing. On Sat, Sep 30, 2017 at 11:07:37PM +0530, silexcommon at gmail.com wrote: > From: Alagu Sankar > > This patchset, generated against master-pending branch, enables a fully > functional SDIO interface driver for ath10k. Patches have been verified on > QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, Access > Point > and P2P modes. > > The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1 Quick question on the firmware, is it the one from Kalle's repository?[3] If so, where does this firmware comes from? Is 00061 the firmware version? So far I've only seen up to v0.0.0.60, see qcacld-2.0 output: Host SW:4.5.20.037, FW:0.0.0.60, HW:QCA9377_REV1_1 > with the board data from respective SDIO card vendors. About the board-sdio.bin, is it just a copy of your bdwlan30.bin? > Receive performance > matches the QCA reference driver when used with SDIO3.0 enabled platforms. > iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s Nice performances. Unfortunately I don't get better than 30Mbits/s in TX and 50Mbits/s in RX: # iperf -c 192.168.1.1 Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 43.8 KByte (default) [ 3] local 192.168.1.115 port 41354 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 34.9 MBytes 29.2 Mbits/sec # iperf -s Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) [ 4] local 192.168.1.115 port 5001 connected with 192.168.1.1 port 50646 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 63.1 MBytes 52.7 Mbits/sec Do you have any idea why? Note that qcacld-2.0 driver on that same platform (same OS) gives the performances you advertize (150Mbits/s). > This patchset differs from the previous high latency patches, specific to > SDIO. > HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET is enabled for HI_ACS. This instructs > the > firmware to use HTT_T2H_MSG_TYPE_TX_COMPL_IND for outgoing packets. Without > this flag, the management frames are not sent out by the firmware. Possibility > of management frames being sent via WMI and data frames through the reduced Tx > completion needs to be probed further. > > Further improvements can be done on the transmit path by implementing packet > bundle. Scatter Gather is another area of improvement for both Transmit and > Receive, but may not work on all platforms > > Known issues: Surprise removal of the card, when the device is in connected > state, delays sdio function remove due to delayed WMI command failures. > Existing ath10k framework can not differentiate between a kernel module > removae and the surprise removal of teh card. Here are some questions: - Is it normal to see a warning about board-2.bin, shouldn't it look for board-sdio.bin only? [ 14.696704] ath10k_sdio mmc1:0001:1: Direct firmware load for ath10k/QCA9377/hw1.0/board-2.bin failed with error -2 - Did you have pre-cal and/or cal binaries for your testing? [ 14.067159] ath10k_sdio mmc1:0001:1: Direct firmware load for ath10k/pre-cal-sdio-mmc1:0001:1.bin failed with error -2 [ 14.149257] ath10k_sdio mmc1:0001:1: Direct firmware load for ath10k/cal-sdio-mmc1:0001:1.bin failed with error -2 Also noticed that the "tx bitrate" output of 'iw link' is wrong in my case: # iw wlan0 link Connected to 00:00:00:00:00:b0 (on wlan0) SSID: TPLINK_AC_5G freq: 5180 RX: 72072365 bytes (67934 packets) TX: 79084128 bytes (73649 packets) signal: -35 dBm tx bitrate: 6.0 MBit/s bss flags: short-slot-time dtim period:2 beacon int: 100 When connecting using qcacld driver it shows 433MBit/s as expected. Is it working properly in your case? As a FYI, I've built Erik's tree[4] for this testing, should I use another tree instead? Let me know your thoughts. Regards, Gary [1] https://boundarydevices.com/product/nitrogen7/ [2] https://boundarydevices.com/product/bd_sdmac_wifi/ [3] https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested [4] https://github.com/erstrom/linux-ath
Re: [PATCH 00/11] SDIO support for ath10k
On 2017-10-04 08:22, Alagu Sankar wrote: Hi Erik, We will work to have this support mainlined as soon as possible. Would appreciate your support in making sure that the patches do not affect the USB high latency path. I have added the patches in my own ath-repo and I have tested with the WUSB6100M without any problems. On 02-10-2017 14:32, Erik Stromdahl wrote: Hi Alagu, It is great to see that we are finally about have fully working mainline support for QCA9377 SDIO chipsets! Great job! On 2017-09-30 19:37, silexcom...@gmail.com wrote: From: Alagu Sankar This patchset, generated against master-pending branch, enables a fully functional SDIO interface driver for ath10k. Patches have been verified on QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, Access Point and P2P modes. The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1 with the board data from respective SDIO card vendors. Receive performance matches the QCA reference driver when used with SDIO3.0 enabled platforms. iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s Can you share any scripts etc. (wrapping hostapd and wpa_supplicant stuff) or provide some more info about you test setup? I am not using any specific scripts for this. The standard ones from the ath10k configuration page https://wireless.wiki.kernel.org/en/users/drivers/ath10k/configuration works just fine with the NL80211 path. I made a quick socat based test on an old laptop (I don't think it has SDIO 3.0 support) and I did unfortunately not get the same figures as you did :( If it is SDIO v1.x, then the max bus speed is only 100Mbit/s. With v2.x it is 200Mbit/s and 3.x it is 832 Mbit/s. Throughput primarily depends on it. We used i.MX6 SoloX Sabre SDB platform which supports SDIO3.x and could see the maximum performance. This patchset differs from the previous high latency patches, specific to SDIO. HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET is enabled for HI_ACS. This instructs the firmware to use HTT_T2H_MSG_TYPE_TX_COMPL_IND for outgoing packets. Without this flag, the management frames are not sent out by the firmware. Possibility of management frames being sent via WMI and data frames through the reduced Tx completion needs to be probed further. Ah, so that explains why I couldn't see any messages in the air. Further improvements can be done on the transmit path by implementing packet bundle. Scatter Gather is another area of improvement for both Transmit and Receive, but may not work on all platforms Known issues: Surprise removal of the card, when the device is in connected state, delays sdio function remove due to delayed WMI command failures. Existing ath10k framework can not differentiate between a kernel module removal and the surprise removal of teh card. Alagu Sankar (11): ath10k_sdio: sdio htt data transfer fixes ath10k_sdio: wb396 reference card fix ath10k_sdio: DMA bounce buffers for read write ath10k_sdio: reduce transmit msdu count ath10k_sdio: use clean packet headers ath10k_sdio: high latency fixes for beacon buffer ath10k_sdio: fix rssi indication ath10k_sdio: common read write ath10k_sdio: virtual scatter gather for receive ath10k_sdio: enable firmware crash dump ath10k_sdio: hif start once addition drivers/net/wireless/ath/ath10k/core.c | 35 ++- drivers/net/wireless/ath/ath10k/debug.c | 3 + drivers/net/wireless/ath/ath10k/htc.c | 4 +- drivers/net/wireless/ath/ath10k/htc.h | 1 + drivers/net/wireless/ath/ath10k/htt_rx.c | 19 +- drivers/net/wireless/ath/ath10k/htt_tx.c | 24 +- drivers/net/wireless/ath/ath10k/hw.c | 2 + drivers/net/wireless/ath/ath10k/hw.h | 1 + drivers/net/wireless/ath/ath10k/mac.c | 31 ++- drivers/net/wireless/ath/ath10k/sdio.c | 398 ++ drivers/net/wireless/ath/ath10k/sdio.h | 10 +- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +- 12 files changed, 403 insertions(+), 127 deletions(-)
Re: [PATCH 00/11] SDIO support for ath10k
Hi Erik, We will work to have this support mainlined as soon as possible. Would appreciate your support in making sure that the patches do not affect the USB high latency path. On 02-10-2017 14:32, Erik Stromdahl wrote: Hi Alagu, It is great to see that we are finally about have fully working mainline support for QCA9377 SDIO chipsets! Great job! On 2017-09-30 19:37, silexcom...@gmail.com wrote: From: Alagu Sankar This patchset, generated against master-pending branch, enables a fully functional SDIO interface driver for ath10k. Patches have been verified on QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, Access Point and P2P modes. The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1 with the board data from respective SDIO card vendors. Receive performance matches the QCA reference driver when used with SDIO3.0 enabled platforms. iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s Can you share any scripts etc. (wrapping hostapd and wpa_supplicant stuff) or provide some more info about you test setup? I am not using any specific scripts for this. The standard ones from the ath10k configuration page https://wireless.wiki.kernel.org/en/users/drivers/ath10k/configuration works just fine with the NL80211 path. I made a quick socat based test on an old laptop (I don't think it has SDIO 3.0 support) and I did unfortunately not get the same figures as you did :( If it is SDIO v1.x, then the max bus speed is only 100Mbit/s. With v2.x it is 200Mbit/s and 3.x it is 832 Mbit/s. Throughput primarily depends on it. We used i.MX6 SoloX Sabre SDB platform which supports SDIO3.x and could see the maximum performance. This patchset differs from the previous high latency patches, specific to SDIO. HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET is enabled for HI_ACS. This instructs the firmware to use HTT_T2H_MSG_TYPE_TX_COMPL_IND for outgoing packets. Without this flag, the management frames are not sent out by the firmware. Possibility of management frames being sent via WMI and data frames through the reduced Tx completion needs to be probed further. Ah, so that explains why I couldn't see any messages in the air. Further improvements can be done on the transmit path by implementing packet bundle. Scatter Gather is another area of improvement for both Transmit and Receive, but may not work on all platforms Known issues: Surprise removal of the card, when the device is in connected state, delays sdio function remove due to delayed WMI command failures. Existing ath10k framework can not differentiate between a kernel module removal and the surprise removal of teh card. Alagu Sankar (11): ath10k_sdio: sdio htt data transfer fixes ath10k_sdio: wb396 reference card fix ath10k_sdio: DMA bounce buffers for read write ath10k_sdio: reduce transmit msdu count ath10k_sdio: use clean packet headers ath10k_sdio: high latency fixes for beacon buffer ath10k_sdio: fix rssi indication ath10k_sdio: common read write ath10k_sdio: virtual scatter gather for receive ath10k_sdio: enable firmware crash dump ath10k_sdio: hif start once addition drivers/net/wireless/ath/ath10k/core.c| 35 ++- drivers/net/wireless/ath/ath10k/debug.c | 3 + drivers/net/wireless/ath/ath10k/htc.c | 4 +- drivers/net/wireless/ath/ath10k/htc.h | 1 + drivers/net/wireless/ath/ath10k/htt_rx.c | 19 +- drivers/net/wireless/ath/ath10k/htt_tx.c | 24 +- drivers/net/wireless/ath/ath10k/hw.c | 2 + drivers/net/wireless/ath/ath10k/hw.h | 1 + drivers/net/wireless/ath/ath10k/mac.c | 31 ++- drivers/net/wireless/ath/ath10k/sdio.c| 398 ++ drivers/net/wireless/ath/ath10k/sdio.h| 10 +- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +- 12 files changed, 403 insertions(+), 127 deletions(-)
Re: [PATCH 00/11] SDIO support for ath10k
Hi Alagu, It is great to see that we are finally about have fully working mainline support for QCA9377 SDIO chipsets! Great job! On 2017-09-30 19:37, silexcom...@gmail.com wrote: From: Alagu Sankar This patchset, generated against master-pending branch, enables a fully functional SDIO interface driver for ath10k. Patches have been verified on QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, Access Point and P2P modes. The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1 with the board data from respective SDIO card vendors. Receive performance matches the QCA reference driver when used with SDIO3.0 enabled platforms. iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s Can you share any scripts etc. (wrapping hostapd and wpa_supplicant stuff) or provide some more info about you test setup? I made a quick socat based test on an old laptop (I don't think it has SDIO 3.0 support) and I did unfortunately not get the same figures as you did :( This patchset differs from the previous high latency patches, specific to SDIO. HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET is enabled for HI_ACS. This instructs the firmware to use HTT_T2H_MSG_TYPE_TX_COMPL_IND for outgoing packets. Without this flag, the management frames are not sent out by the firmware. Possibility of management frames being sent via WMI and data frames through the reduced Tx completion needs to be probed further. Ah, so that explains why I couldn't see any messages in the air. Further improvements can be done on the transmit path by implementing packet bundle. Scatter Gather is another area of improvement for both Transmit and Receive, but may not work on all platforms Known issues: Surprise removal of the card, when the device is in connected state, delays sdio function remove due to delayed WMI command failures. Existing ath10k framework can not differentiate between a kernel module removal and the surprise removal of teh card. Alagu Sankar (11): ath10k_sdio: sdio htt data transfer fixes ath10k_sdio: wb396 reference card fix ath10k_sdio: DMA bounce buffers for read write ath10k_sdio: reduce transmit msdu count ath10k_sdio: use clean packet headers ath10k_sdio: high latency fixes for beacon buffer ath10k_sdio: fix rssi indication ath10k_sdio: common read write ath10k_sdio: virtual scatter gather for receive ath10k_sdio: enable firmware crash dump ath10k_sdio: hif start once addition drivers/net/wireless/ath/ath10k/core.c| 35 ++- drivers/net/wireless/ath/ath10k/debug.c | 3 + drivers/net/wireless/ath/ath10k/htc.c | 4 +- drivers/net/wireless/ath/ath10k/htc.h | 1 + drivers/net/wireless/ath/ath10k/htt_rx.c | 19 +- drivers/net/wireless/ath/ath10k/htt_tx.c | 24 +- drivers/net/wireless/ath/ath10k/hw.c | 2 + drivers/net/wireless/ath/ath10k/hw.h | 1 + drivers/net/wireless/ath/ath10k/mac.c | 31 ++- drivers/net/wireless/ath/ath10k/sdio.c| 398 ++ drivers/net/wireless/ath/ath10k/sdio.h| 10 +- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +- 12 files changed, 403 insertions(+), 127 deletions(-)