On Sun, Aug 28, 2011 at 01:28:15AM +0200, Felix Fietkau wrote:
> On 2011-08-27 11:16 AM, Rajkumar Manoharan wrote:
> >Configure IFS parameters read from chip in case of
> >full rate channel and non-AR9287 v1.3+. And also
> >read the ack and cts timeouts from chip and increase the
> >timeout when coverage class is defined. For half/Quarter
> >rate channel, IFS values needs to be reconfigured.
> >This patch removes the 2GHz workaround done for
> >acktimeout(64 us) because of reading acktime from chip.
> >The mentioned IFS parameters for AR9287 v1.3+ was
> >verified in HT40 2-chanin mode.
> >
> >Signed-off-by: Rajkumar Manoharan<rmanohar@xxxxxxxxxxxxxxxx>
> >---
> > drivers/net/wireless/ath/ath9k/hw.c | 30 +++++++++++++++++-------------
> > 1 files changed, 17 insertions(+), 13 deletions(-)
> >
> >diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
> >index 284d2a4..de31f2b 100644
> >--- a/drivers/net/wireless/ath/ath9k/hw.c
> >+++ b/drivers/net/wireless/ath/ath9k/hw.c
> >@@ -958,11 +958,11 @@ static bool ath9k_hw_set_global_txtimeout(struct ath_hw *ah, u32 tu)
> > void ath9k_hw_init_global_settings(struct ath_hw *ah)
> > {
> > struct ath_common *common = ath9k_hw_common(ah);
> >- struct ieee80211_conf *conf =&common->hw->conf;
> > const struct ath9k_channel *chan = ah->curchan;
> > int acktimeout;
> > int slottime;
> > int sifstime;
> >+ u32 ctstimeout;
> > int rx_lat = 0, tx_lat = 0, eifs = 0;
> > u32 reg;
> >
> >@@ -1018,23 +1018,27 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
> > sifstime = 10;
> > }
> >
> >- /* As defined by IEEE 802.11-2007 17.3.8.6 */
> >- acktimeout = slottime + sifstime + 3 * ah->coverage_class;
> >+ if (AR_SREV_9287(ah)&& AR_SREV_9287_13_OR_LATER(ah)) {
> >+ /* Verified values (us) in 2chanin HT40 mode */
> >+ acktimeout = 64;
> >+ ctstimeout = 48;
> >+ } else {
> >+ acktimeout = MS(REG_READ(ah, AR_TIME_OUT), AR_TIME_OUT_ACK)/
> >+ common->clockrate;
> >+ ctstimeout = MS(REG_READ(ah, AR_TIME_OUT), AR_TIME_OUT_CTS)/
> >+ common->clockrate;
> >+ }
> Why this mess of partially reused values from initvals? I think it's
> much better to just override these based on the standard 802.11
> values, and selectively add the 64-usec-minimum workaround for 2.4
> ghz as needed
As per the 802.11 spec, the ack/cts timeout calculation does not include
start delay factor. And also the current ctstimeout in 2.4 GHz is 30us (sifs+long slottime)
which is always lesser than the INI values. What is the point in reducing
cts timeouts and having workaround that again matches with INI values.
--
Rajkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
