2014-12-29 06:18:46

by Sujith Manoharan

[permalink] [raw]
Subject: [PATCH] ath10k: Fix DMA burst size

From: Sujith Manoharan <[email protected]>

A value of zero indicates that 128B is the maximum
DMA request size for read/writes. But PCI cards based
on AR9880 can support 256B, so enable this for
the 10.2 firmware.

Signed-off-by: Sujith Manoharan <[email protected]>
---
drivers/net/wireless/ath/ath10k/hw.h | 3 +++
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 5729901..7b771ae 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -183,6 +183,9 @@ struct ath10k_pktlog_hdr {
#define TARGET_10X_NUM_MSDU_DESC (1024 + 400)
#define TARGET_10X_MAX_FRAG_ENTRIES 0

+/* 10.2 parameters */
+#define TARGET_10_2_DMA_BURST_SIZE 1
+
/* Target specific defines for WMI-TLV firmware */
#define TARGET_TLV_NUM_VDEVS 3
#define TARGET_TLV_NUM_STATIONS 32
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index ac74290..b103122 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3744,7 +3744,7 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct ath10k *ar)
config.mcast2ucast_mode = __cpu_to_le32(TARGET_10X_MCAST2UCAST_MODE);
config.tx_dbg_log_size = __cpu_to_le32(TARGET_10X_TX_DBG_LOG_SIZE);
config.num_wds_entries = __cpu_to_le32(TARGET_10X_NUM_WDS_ENTRIES);
- config.dma_burst_size = __cpu_to_le32(TARGET_10X_DMA_BURST_SIZE);
+ config.dma_burst_size = __cpu_to_le32(TARGET_10_2_DMA_BURST_SIZE);
config.mac_aggr_delim = __cpu_to_le32(TARGET_10X_MAC_AGGR_DELIM);

val = TARGET_10X_RX_SKIP_DEFRAG_TIMEOUT_DUP_DETECTION_CHECK;
--
2.2.1



2015-01-07 10:23:39

by Sujith Manoharan

[permalink] [raw]
Subject: Re: [PATCH] ath10k: Fix DMA burst size

Michal Kazior wrote:
> Since it's for cards/chips why do you enable it for 10.2 only? There's
> 10.1, main and tlv as well which could possibly benefit from this.

I've not tested it with any of the FW versions other than 10.2 and
am not sure if older FW support this properly. We could try it
with 10.1, I guess - but even that is in 'maintenance mode'
internally.

Sujith

2015-01-07 10:04:20

by Michal Kazior

[permalink] [raw]
Subject: Re: [PATCH] ath10k: Fix DMA burst size

On 29 December 2014 at 07:21, Sujith Manoharan <[email protected]> wrote:
> From: Sujith Manoharan <[email protected]>
>
> A value of zero indicates that 128B is the maximum
> DMA request size for read/writes. But PCI cards based
> on AR9880 can support 256B, so enable this for
> the 10.2 firmware.

Since it's for cards/chips why do you enable it for 10.2 only? There's
10.1, main and tlv as well which could possibly benefit from this.


MichaƂ

2015-01-02 07:41:18

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH] ath10k: Fix DMA burst size

Sujith Manoharan <[email protected]> writes:

> From: Sujith Manoharan <[email protected]>
>
> A value of zero indicates that 128B is the maximum
> DMA request size for read/writes. But PCI cards based
> on AR9880 can support 256B, so enable this for
> the 10.2 firmware.
>
> Signed-off-by: Sujith Manoharan <[email protected]>

Did you see any throughput improvements with this?

--
Kalle Valo

2015-01-12 11:53:32

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH] ath10k: Fix DMA burst size

Sujith Manoharan <[email protected]> writes:

> From: Sujith Manoharan <[email protected]>
>
> A value of zero indicates that 128B is the maximum
> DMA request size for read/writes. But PCI cards based
> on AR9880 can support 256B, so enable this for
> the 10.2 firmware.
>
> Signed-off-by: Sujith Manoharan <[email protected]>

Thanks, applied.

--
Kalle Valo

2015-01-12 11:52:01

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH] ath10k: Fix DMA burst size

Sujith Manoharan <[email protected]> writes:

> Michal Kazior wrote:
>> Since it's for cards/chips why do you enable it for 10.2 only? There's
>> 10.1, main and tlv as well which could possibly benefit from this.
>
> I've not tested it with any of the FW versions other than 10.2 and
> am not sure if older FW support this properly. We could try it
> with 10.1, I guess - but even that is in 'maintenance mode'
> internally.

Yeah, I don't see much point of trying to improve our 10.1 support as
all the new development happens on 10.2 branch. Most important is that
we don't break 10.1 support ("no regressions" rule), but it in no way
does 10.1 need to be in feature parity with 10.2.

--
Kalle Valo