Re: [PATCH 00/11] SDIO support for ath10k

[Kalle Valo]

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

[Kalle Valo]

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

[Gary Bisson]

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

[Gary Bisson]

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
> > > 

Re: [PATCH 00/11] SDIO support for ath10k

[Gary Bisson]

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

[Erik Stromdahl]

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

[Alagu Sankar]

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

[Erik Stromdahl]

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(-)

[PATCH 00/11] SDIO support for ath10k

[silexcommon]

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

 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(-)

-- 
1.9.1