date:20100427

[ath9k-devel] [PATCH] ath9k: Avoid acktimeout wraps around at bootstrap

2010-04-27 Thread Lorenzo Bianconi

Hi all,

I am using ath9k/mac80211 on a PC Engines Alix with a Mikrotik R52n
card (AR9280 chipset), OpenWrt r21030 (kernel 2.6.32.10) and
compat-wireless-2010-04-21. I am injecting packets using a VAP in
monitor mode.
I have a doubt on ath9k_hw_init_defaults() in hw.c. In particular
during the bootstrap ah-slottime in ath9k_hw_init_defaults() is set
to  (u32) -1, so after a HW reset (for example as a result of a
channel change) in the function ath9k_hw_init_global_settings() the
acktimeout variable wraps around as ah-slottime is 0x and

acktimeout = sifstime + ah-slottime + 3 * ah-coverage_class

In this way we obtain that acktimout is set to 15 us (assuming
ah-coverage_class set to 0) in the 5GHZ band so less than one of its
summands (sifstime = 16).
I wrote this simple patch in order to set ah-slottime to standard
value for OFDM PHY layer during bootstrap.

Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com
---
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -425,7 +425,7 @@
ah-sta_id1_defaults = AR_STA_ID1_CRPT_MIC_ENABLE;
ah-beacon_interval = 100;
ah-enable_32kHz_clock = DONT_USE_32KHZ;
-   ah-slottime = (u32) -1;
+   ah-slottime = 20;
ah-globaltxtimeout = (u32) -1;
ah-power_mode = ATH9K_PM_UNDEFINED;
 }
--

Regards

Lorenzo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Avoid acktimeout wraps around at bootstrap

2010-04-27 Thread Benoit PAPILLAULT

Lorenzo Bianconi a écrit :
 Hi all,

 I am using ath9k/mac80211 on a PC Engines Alix with a Mikrotik R52n
 card (AR9280 chipset), OpenWrt r21030 (kernel 2.6.32.10) and
 compat-wireless-2010-04-21. I am injecting packets using a VAP in
 monitor mode.
 I have a doubt on ath9k_hw_init_defaults() in hw.c. In particular
 during the bootstrap ah-slottime in ath9k_hw_init_defaults() is set
 to  (u32) -1, so after a HW reset (for example as a result of a
 channel change) in the function ath9k_hw_init_global_settings() the
 acktimeout variable wraps around as ah-slottime is 0x and

 acktimeout = sifstime + ah-slottime + 3 * ah-coverage_class

 In this way we obtain that acktimout is set to 15 us (assuming
 ah-coverage_class set to 0) in the 5GHZ band so less than one of its
 summands (sifstime = 16).
 I wrote this simple patch in order to set ah-slottime to standard
 value for OFDM PHY layer during bootstrap.
   
Does this have any visible effect or is this patch for strict 
compliance? I am asking this since I see very strange stuff regarding 
ACK (delayed, missing, out of order, ...)

Regards,
Benoit
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] wireless: ath9k: Fix most coding style issues in ath9k This patch fixed up almost all coding style issues in the ath9k driver found by the ceckpatch.pl tool. Signed-off-by: M

2010-04-27 Thread Michael Sprecher

Yes, i'm still intrested in fixing your coding style issues ;)
If it's now safe to check it again, i will find some time to look at it this
week.
Michael

Am 08.04.2010 21:13 schrieb Luis R. Rodriguez lrodrig...@atheros.com:

On Thu, Apr 8, 2010 at 11:41 AM, John W. Linville
linvi...@tuxdriver.com wrote:
 On Tue, Mar 09, ...
No wait, going to shoot out our massive series now :)

 Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] ath9k: noise floor calibration process

2010-04-27 Thread Benoit PAPILLAULT

Hello,

In order to move forward with noise  signal reporting, I'd like to 
share my current understanding of the way  ath9k HW is working before 
sending patches (unfortunately, I did the work before the introduction 
of ar9003... so I need to redo the work).

The ultimate purpose of this work is to be able to measure signal levels 
(and noise if possible) as accurately as a spectrum analyzer or power meter.

First, signal level reporting. It is reported in a per packet basis in 
RX descriptors. There are 7 fields:
AR_RxRSSIAnt000x00ffrs_rssi_ctl0
AR_RxRSSIAnt010xff00rs_rssi_ctl1
AR_RxRSSIAnt020x00ffrs_rssi_ctl2
AR_RxRSSIAnt100x00ffrs_rssi_ext0
AR_RxRSSIAnt110xff00rs_rssi_ext1
AR_RxRSSIAnt120x00ffrs_rssi_ext2
AR_RxRSSICombined0xff00rs_rssi

Each value is for a 20 MHz wide channel, on the 3 RX chains. ctl is 
for the primary channel and ext is for the secondary channel (using 
the 802.11n words). The latter rs_rssi is the sum of the 6 previous 
value. However, since each value is dB, the sum is not an arithmetic 
sum. Each field is a signed value and the value -128 means that no 
measurement has been done  (no RX chain, RX chain disabled, no secondary 
channel, ...). It seems that in some cases, the combined value is just 
plain wrong. Here are few examples:

  RSSI: ctl=(10,7,-128) ext=(-128,-128,-128) = 12 (11.76)correct

  RSSI: ctl=(38,29,-128) ext=(69,-84,-101) = -22incorrect!!!


Next, noise floor calibration. From what I understand, signal levels is 
measured using the AGC + RX amplifiers gain (RF, IF and BB). However, 
the various gains are not really accurate, only the relative gain are 
accurate. This means that reading a signal value of -100dBm might not 
exactly means -100dBm. There is a delta between real signal and measured 
value. In order to know this value, we need a calibration process with a 
known signal.

One know signal is thermal noise. Thermal noise is generated in any 
resistor and can be computed using the well know value N = kTB. For a 20 
MHz bandwidth, this gives -101dBm. If the HW tries to measure signal 
strength when the network is supposed to be idle (during SIFS) and with 
RX/TX switch disabled (?), then it will in fact measure the thermal 
noise at the RX input.

So, we have :

Real noise (-101dBm) = Measured noise + delta

There are type of registers to control noise floor calibration :

- control register at 0x9860(AR_PHY_AGC_CONTROL)

This register allows 3 differents operations :

1. start noise floor measurement

  write AR_PHY_MAXCCA_PWR (AR_PHY_CCA  0x01ff) : this is apparently 
a max value
for noise floor
  REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_ENABLE_NF);
  REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
  REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);

  When channel has been changed however, the noise floor needs to be 
updated immediately, so AR_PHY_AGC_CONTROL_NO_UPDATE_NF should be 
cleared in this particular case. Otherwise, the chip is no longer 
receiving (problem since CCA is defined with noise floor as reference).

2. read noise floor measurement result

check REG_READ(ah, AR_PHY_AGC_CONTROL)  AR_PHY_AGC_CONTROL_NF
if 0 (noise floor calibration is finished), read AR_PHY_MINCCA_PWR :
  nf = MS(REG_READ(ah, AR_PHY_CCA), AR_PHY_MINCCA_PWR = 0x0ff8)

3. write noise floor reference

  write AR_PHY_MAXCCA_PWR (the value has not the same meaning as 
operation 1!)
  REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_ENABLE_NF);
  REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
  REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);

- data register at 0x9864 (AR_PHY_CCA, + more location for other RX chains)

  The fields are different for AR9280+ chipsets, but the mechanism is 
the same.

AR_PHY_MAXCCA_PWR0x01ff (half dBm unit!)
AR_PHY_CCA_THRESH620x0007f000
AR_PHY_MINCCA_PWR0x0ff8

Now, we have :

Real signal = Measured signal + delta
= RSSI + Noise floor + delta
= RSSI + (-101 dBm)

Real noise is not thermal noise. There are a lot of definition for noise 
since noise is NOT signal. Of course, noise includes thermal noise. 
Since the noise measured by the chip is variable, I think we could do :

- Noise floor = minimum (Noise floor measures)
- Noise = moving average (Noise floor measures) + delta
  with delta = (-101 dBm) - Noise floor

I'd like to get comments before sending patches. Since ath5k and ath9k 
are quite close, I'm pretty sure a similar (if not same) process is used 
on ath5k.

Regards,
Benoit

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] wireless: ath9k: Fix most coding style issues in ath9k This patch fixed up almost all coding style issues in the ath9k driver found by the ceckpatch.pl tool. Signed-off-by: M

2010-04-27 Thread Luis R. Rodriguez

On Tue, Apr 27, 2010 at 01:21:21PM -0700, Michael Sprecher wrote:
 Yes, i'm still intrested in fixing your coding style issues ;)
 If it's now safe to check it again, i will find some time to look at it this 
 week.
 Michael

Go for it, after John merges our latest batch you should be good to go

  Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH] ath9k: Added get_survey callback in order to get channel noise

2010-04-27 Thread Benoit Papillault


Signed-off-by: Benoit Papillault benoit.papilla...@free.fr
---
 drivers/net/wireless/ath/ath9k/main.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index c03821e..f0b2aa2 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2047,6 +2047,25 @@ static int ath9k_ampdu_action(struct ieee80211_hw *hw,
return ret;
 }
 
+static int ath9k_get_survey(struct ieee80211_hw *hw, int idx,
+struct survey_info *survey)
+{
+   struct ath_wiphy *aphy = hw-priv;
+   struct ath_softc *sc = aphy-sc;
+   struct ath_hw *ah = sc-sc_ah;
+   struct ath_common *common = ath9k_hw_common(ah);
+   struct ieee80211_conf *conf = hw-conf;
+
+if (idx != 0)
+   return -ENOENT;
+
+   survey-channel = conf-channel;
+   survey-filled = SURVEY_INFO_NOISE_DBM;
+   survey-noise = common-ani.noise_floor;
+
+   return 0;
+}
+
 static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
 {
struct ath_wiphy *aphy = hw-priv;
@@ -2122,6 +2141,7 @@ struct ieee80211_ops ath9k_ops = {
.set_tsf= ath9k_set_tsf,
.reset_tsf  = ath9k_reset_tsf,
.ampdu_action   = ath9k_ampdu_action,
+   .get_survey = ath9k_get_survey,
.sw_scan_start  = ath9k_sw_scan_start,
.sw_scan_complete   = ath9k_sw_scan_complete,
.rfkill_poll= ath9k_rfkill_poll_state,
-- 
1.5.6.5

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Added get_survey callback in order to get channel noise

2010-04-27 Thread Luis R. Rodriguez

On Tue, Apr 27, 2010 at 03:08:24PM -0700, Benoit Papillault wrote:
 
 Signed-off-by: Benoit Papillault benoit.papilla...@free.fr

Looks good, thanks for this work.

  Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k: noise floor calibration process

2010-04-27 Thread RHS Linux User


Hi All,

   preaching

   The chip *FOR SURE* *CANNOT* measure the thermal noise level!! It isn't
that sensitive. That said under some conditions it CAN measure the
local interference level which IS useful.

   I am *VERY MUCH* in favor of making real time level measurements of
various parts of real packets easy to use!  Troubleshooting becomes so
much easier :).

   /preaching

   Great ideas !!

   FWIW - I have on occasion used a low noise preamp to feed the chip. 
Many more signals are detectable which proves the chip by itself *IS
NOT* that sensitive. Try it yourself !

   Have fun,

   Wiz


On Tue, 27 Apr 2010, Benoit PAPILLAULT wrote:

 Hello,
 
 In order to move forward with noise  signal reporting, I'd like to 
 share my current understanding of the way  ath9k HW is working before 
 sending patches (unfortunately, I did the work before the introduction 
 of ar9003... so I need to redo the work).
 
 The ultimate purpose of this work is to be able to measure signal levels 
 (and noise if possible) as accurately as a spectrum analyzer or power meter.
 
 First, signal level reporting. It is reported in a per packet basis in 
 RX descriptors. There are 7 fields:
 AR_RxRSSIAnt000x00ffrs_rssi_ctl0
 AR_RxRSSIAnt010xff00rs_rssi_ctl1
 AR_RxRSSIAnt020x00ffrs_rssi_ctl2
 AR_RxRSSIAnt100x00ffrs_rssi_ext0
 AR_RxRSSIAnt110xff00rs_rssi_ext1
 AR_RxRSSIAnt120x00ffrs_rssi_ext2
 AR_RxRSSICombined0xff00rs_rssi
 
 Each value is for a 20 MHz wide channel, on the 3 RX chains. ctl is 
 for the primary channel and ext is for the secondary channel (using 
 the 802.11n words). The latter rs_rssi is the sum of the 6 previous 
 value. However, since each value is dB, the sum is not an arithmetic 
 sum. Each field is a signed value and the value -128 means that no 
 measurement has been done  (no RX chain, RX chain disabled, no secondary 
 channel, ...). It seems that in some cases, the combined value is just 
 plain wrong. Here are few examples:
 
   RSSI: ctl=(10,7,-128) ext=(-128,-128,-128) = 12 (11.76)correct
 
   RSSI: ctl=(38,29,-128) ext=(69,-84,-101) = -22incorrect!!!
 
 
 Next, noise floor calibration. From what I understand, signal levels is 
 measured using the AGC + RX amplifiers gain (RF, IF and BB). However, 
 the various gains are not really accurate, only the relative gain are 
 accurate. This means that reading a signal value of -100dBm might not 
 exactly means -100dBm. There is a delta between real signal and measured 
 value. In order to know this value, we need a calibration process with a 
 known signal.
 
 One know signal is thermal noise. Thermal noise is generated in any 
 resistor and can be computed using the well know value N = kTB. For a 20 
 MHz bandwidth, this gives -101dBm. If the HW tries to measure signal 
 strength when the network is supposed to be idle (during SIFS) and with 
 RX/TX switch disabled (?), then it will in fact measure the thermal 
 noise at the RX input.
 
 So, we have :
 
 Real noise (-101dBm) = Measured noise + delta
 
 There are type of registers to control noise floor calibration :
 
 - control register at 0x9860(AR_PHY_AGC_CONTROL)
 
 This register allows 3 differents operations :
 
 1. start noise floor measurement
 
   write AR_PHY_MAXCCA_PWR (AR_PHY_CCA  0x01ff) : this is apparently 
 a max value
 for noise floor
   REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_ENABLE_NF);
   REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
   REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
 
   When channel has been changed however, the noise floor needs to be 
 updated immediately, so AR_PHY_AGC_CONTROL_NO_UPDATE_NF should be 
 cleared in this particular case. Otherwise, the chip is no longer 
 receiving (problem since CCA is defined with noise floor as reference).
 
 2. read noise floor measurement result
 
 check REG_READ(ah, AR_PHY_AGC_CONTROL)  AR_PHY_AGC_CONTROL_NF
 if 0 (noise floor calibration is finished), read AR_PHY_MINCCA_PWR :
   nf = MS(REG_READ(ah, AR_PHY_CCA), AR_PHY_MINCCA_PWR = 0x0ff8)
 
 3. write noise floor reference
 
   write AR_PHY_MAXCCA_PWR (the value has not the same meaning as 
 operation 1!)
   REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_ENABLE_NF);
   REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
   REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
 
 - data register at 0x9864 (AR_PHY_CCA, + more location for other RX chains)
 
   The fields are different for AR9280+ chipsets, but the mechanism is 
 the same.
 
 AR_PHY_MAXCCA_PWR0x01ff (half dBm unit!)
 AR_PHY_CCA_THRESH620x0007f000
 AR_PHY_MINCCA_PWR0x0ff8
 
 Now, we have :
 
 Real signal = Measured signal + delta
 = RSSI + Noise floor + delta
 = RSSI + (-101 dBm)
 
 Real noise is not thermal noise. There are a

[ath9k-devel] [PATCH] ath9k: Avoid acktimeout wraps around at bootstrap

Re: [ath9k-devel] [PATCH] ath9k: Avoid acktimeout wraps around at bootstrap

Re: [ath9k-devel] [PATCH] wireless: ath9k: Fix most coding style issues in ath9k This patch fixed up almost all coding style issues in the ath9k driver found by the ceckpatch.pl tool. Signed-off-by: M

[ath9k-devel] ath9k: noise floor calibration process

Re: [ath9k-devel] [PATCH] wireless: ath9k: Fix most coding style issues in ath9k This patch fixed up almost all coding style issues in the ath9k driver found by the ceckpatch.pl tool. Signed-off-by: M

[ath9k-devel] [PATCH] ath9k: Added get_survey callback in order to get channel noise

Re: [ath9k-devel] [PATCH] ath9k: Added get_survey callback in order to get channel noise

Re: [ath9k-devel] ath9k: noise floor calibration process

8 matches

Site Navigation

Mail list logo

Footer information