Otus uses slightly different set of "Minimum MPDU Start Spacing" values
than the 802.11n D2.0 specifies. (the whole table is shifted by one and
therefore the 16us spacing is not officially available!)
And while we're at it, we also initialize our MAC's density register.
So, this annoying _feature_ will not break TX A-MPDU later.
Signed-off-by: Christian Lamparter <[email protected]>
---
diff --git a/drivers/net/wireless/ath/ar9170/hw.h b/drivers/net/wireless/ath/ar9170/hw.h
index 95bf812..3293e0f 100644
--- a/drivers/net/wireless/ath/ar9170/hw.h
+++ b/drivers/net/wireless/ath/ar9170/hw.h
@@ -207,6 +207,8 @@ enum ar9170_cmd {
#define AR9170_MAC_REG_AC1_AC0_TXOP (AR9170_MAC_REG_BASE + 0xB44)
#define AR9170_MAC_REG_AC3_AC2_TXOP (AR9170_MAC_REG_BASE + 0xB48)
+#define AR9170_MAC_REG_AMPDU_SET (AR9170_MAC_REG_BASE + 0xba0)
+
#define AR9170_MAC_REG_ACK_TABLE (AR9170_MAC_REG_BASE + 0xC00)
#define AR9170_MAC_REG_AMPDU_RX_THRESH (AR9170_MAC_REG_BASE + 0xC50)
diff --git a/drivers/net/wireless/ath/ar9170/mac.c b/drivers/net/wireless/ath/ar9170/mac.c
index c8fa307..3332f6e 100644
--- a/drivers/net/wireless/ath/ar9170/mac.c
+++ b/drivers/net/wireless/ath/ar9170/mac.c
@@ -72,6 +72,24 @@ int ar9170_set_qos(struct ar9170 *ar)
return ar9170_regwrite_result();
}
+static int ar9170_set_ampdu_density(struct ar9170 *ar, u8 mpdudensity)
+{
+ u32 val;
+
+ /* don't allow AMPDU density > 8us */
+ if (mpdudensity > 6)
+ return -EINVAL;
+
+ /* Watch out! Otus uses slightly different density values. */
+ val = 0x140a00 | (mpdudensity ? (mpdudensity + 1) : 0);
+
+ ar9170_regwrite_begin(ar);
+ ar9170_regwrite(AR9170_MAC_REG_AMPDU_SET, val);
+ ar9170_regwrite_finish();
+
+ return ar9170_regwrite_result();
+}
+
int ar9170_init_mac(struct ar9170 *ar)
{
ar9170_regwrite_begin(ar);
@@ -296,6 +314,11 @@ int ar9170_set_operating_mode(struct ar9170 *ar)
if (err)
return err;
+ /* set AMPDU density to 8us. */
+ err = ar9170_set_ampdu_density(ar, 6);
+ if (err)
+ return err;
+
ar9170_regwrite_begin(ar);
ar9170_regwrite(AR9170_MAC_REG_POWERMANAGEMENT, pm_mode);
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index 1b60906..f297a6d 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -151,8 +151,8 @@ static struct ieee80211_channel ar9170_5ghz_chantable[] = {
IEEE80211_HT_CAP_SGI_40 | \
IEEE80211_HT_CAP_DSSSCCK40 | \
IEEE80211_HT_CAP_SM_PS, \
- .ampdu_factor = 3, /* ?? */ \
- .ampdu_density = 7, /* ?? */ \
+ .ampdu_factor = 3, \
+ .ampdu_density = 6, \
.mcs = { \
.rx_mask = { 0xFF, 0xFF, 0, 0, 0, 0, 0, 0, 0, 0, }, \
}, \
On Fri, 2009-04-24 at 21:35 +0200, Christian Lamparter wrote:
> Otus uses slightly different set of "Minimum MPDU Start Spacing" values
> than the 802.11n D2.0 specifies. (the whole table is shifted by one and
> therefore the 16us spacing is not officially available!)
>
> And while we're at it, we also initialize our MAC's density register.
> So, this annoying _feature_ will not break TX A-MPDU later.
Cute.
> + .ampdu_factor = 3, \
> + .ampdu_density = 6, \
FWIW, I also tried some varying values. This should indicate what you're
able to receive though, not what you're able to transmit since you
control that anyway. I think we currently don't have a setting though
for what to transmit with... this might need to be added somewhere
depending on the RA.
johannes
On Saturday 25 April 2009 09:42:29 Johannes Berg wrote:
> On Fri, 2009-04-24 at 21:35 +0200, Christian Lamparter wrote:
> > + .ampdu_factor = 3, \
> > + .ampdu_density = 6, \
>
> FWIW, I also tried some varying values. This should indicate what you're
> able to receive though, not what you're able to transmit since you
> control that anyway.
yeah... in fact the _correct_ value according to otus is 0 (unrestricted),
however that's a bit hard to believe... and ath9k's (not the same
mac... I know) default works rather well.
[I see about 65 Mbits sustainable throughput and peaks in the lower 80.]
> I think we currently don't have a setting though for what to transmit with...
> this might need to be added somewhere depending on the RA.
well, there should be a table or some bits in phy_control for this purpose...
But it looks like otus only has this single MAC knob and the safest setting
otus allows is 7 = 8us...
of course it would be nice if ieee80211_bss_ht_conf in bss_conf, could be
replaced by ieee80211_sta_ht_cap which has the necessary elements.
after all this chip was designed as a client adapter, so there's no need
to handle multiple a-mpdu density at the same time...
Regards,
Chr