ath5k: Remove opaque pointers from ath5k_hw_attach()
PATCH 2/7 ath5k: Remove opaque pointers from ath5k_hw_attach()
Since we don't have a HAL anymore there is no point to use opaque pointers in ath5k_hw_attach(). This will also give hw.c access to ath5k_softc structure now when needed. While we're at it, lets also give some ah_sh a reasonable name, ah_sh --> ah_iobase.
Changes to base.c
Changes-licensed-under: 3-clause-BSD
Changes to ath5k.h, hw.c
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/ath5k.h | 10 +++++----- drivers/net/wireless/ath5k/base.c | 2 +- drivers/net/wireless/ath5k/hw.c | 11 +++++------ 3 files changed, 11 insertions(+), 12 deletions(-)
drivers/net/wireless/ath5k/ath5k.h +5 -5
@@ -943,8 +943,8 @@ struct ath5k_capabilities {struct ath5k_hw {u32 ah_magic; -void *ah_sc; -void __iomem *ah_sh; +struct ath5k_softc *ah_sc; +void __iomem *ah_iobase;enum ath5k_int ah_imr;
@@ -1042,7 +1042,7 @@ struct ath5k_hw {/* General Functions */ extern int ath5k_hw_register_timeout (struct ath5k_hw *ah,u32 reg,u32 flag,u32 val,bool is_set);/* Attach/Detach Functions */ -extern struct ath5k_hw *ath5k_hw_attach (u16 device,u8 mac_version,void *sc,void __iomem *sh); +extern struct ath5k_hw *ath5k_hw_attach (struct ath5k_softc *sc,u8 mac_version);extern const struct ath5k_rate_table *ath5k_hw_get_rate_table (struct ath5k_hw *ah,unsigned int mode);extern void ath5k_hw_detach (struct ath5k_hw *ah);/* Reset Functions */
@@ -1151,12 +1151,12 @@ extern int ath5k_hw_set_txpower_limit(struct ath5k_hw *ah, unsigned int power);static inline u32 ath5k_hw_reg_read (struct ath5k_hw *ah,u16 reg) { -return ioread32 (ah->ah_sh + reg); +return ioread32 (ah->ah_iobase + reg); }static inline void ath5k_hw_reg_write (struct ath5k_hw *ah,u32 val,u16 reg) { -iowrite32 (val, ah->ah_sh + reg); +iowrite32 (val, ah->ah_iobase + reg); }#endif
drivers/net/wireless/ath5k/base.c +1 -1
@@ -559,7 +559,7 @@ ath5k_pci_probe(struct pci_dev *pdev, }/* Initialize device */ - sc->ah =ath5k_hw_attach (pdev->device, id->driver_data, sc, sc->iobase); + sc->ah =ath5k_hw_attach (sc, id->driver_data);if (IS_ERR (sc->ah)) { ret =PTR_ERR (sc->ah); goto err_irq;
drivers/net/wireless/ath5k/hw.c +5 -6
@@ -27,8 +27,8 @@#include <linux/pci.h> #include <linux/delay.h> -#include "ath5k.h" #include "reg.h" +#include "base.h" /*Rate tables*/ static const struct ath5k_rate_table ath5k_rt_11a =AR5K_RATES_11A ;
@@ -187,8 +187,7 @@ int ath5k_hw_register_timeout(struct ath5k_hw *ah, u32 reg, u32 flag, u32 val,/* * Check if the device is supported and initialize the needed structs */ -struct ath5k_hw *ath5k_hw_attach (u16 device,u8 mac_version,void *sc, -void __iomem *sh) +struct ath5k_hw *ath5k_hw_attach (struct ath5k_softc *sc,u8 mac_version) {struct ath5k_hw *ah;u8 mac[ETH_ALEN ];
@@ -204,7 +203,7 @@ struct ath5k_hw *ath5k_hw_attach(u16 device, u8 mac_version, void *sc, } ah->ah_sc = sc; - ah->ah_sh = sh; + ah->ah_iobase = sc->iobase;/* * HW information
@@ -323,7 +322,7 @@ struct ath5k_hw *ath5k_hw_attach(u16 device, u8 mac_version, void *sc, ret =ath5k_hw_get_capabilities (ah);if (ret) {AR5K_PRINTF ("unable to get device capabilities: 0x%04x\n" , - device); + sc->pdev->device); goto err_free; }
@@ -331,7 +330,7 @@ struct ath5k_hw *ath5k_hw_attach(u16 device, u8 mac_version, void *sc, ret =ath5k_eeprom_read_mac (ah, mac);if (ret) {AR5K_PRINTF ("unable to read address from EEPROM: 0x%04x\n" , - device); + sc->pdev->device); goto err_free; }
Signature · 1 line
1.5.2.5
PATCH 3/7 ath5k: Clean up ath5k rate duration settings
Replace ath5k's rate duration computations for one using mac80211's internals. Another consideration here is to simply remove these and put them into initval values. They seem to be static values based only on mode. We can do this later though once we can physically confirm by trial and error these are indeed just used for ACK timeout. The next puzzle is figuring out which registers are actually setting the control rates.
Changes to ath5k.h, hw.c
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/ath5k.h | 80 -------------- drivers/net/wireless/ath5k/hw.c | 201 ++++++++++++++---------------------- 2 files changed, 76 insertions(+), 205 deletions(-)
drivers/net/wireless/ath5k/ath5k.h +0 -80
@@ -374,86 +374,6 @@ enum ath5k_pkt_type { )/* -* Used to compute TX times -*/ -#define AR5K_CCK_SIFS_TIME 10 -#define AR5K_CCK_PREAMBLE_BITS 144 -#define AR5K_CCK_PLCP_BITS 48 - -#define AR5K_OFDM_SIFS_TIME 16 -#define AR5K_OFDM_PREAMBLE_TIME 20 -#define AR5K_OFDM_PLCP_BITS 22 -#define AR5K_OFDM_SYMBOL_TIME 4 - -#define AR5K_TURBO_SIFS_TIME 8 -#define AR5K_TURBO_PREAMBLE_TIME 14 -#define AR5K_TURBO_PLCP_BITS 22 -#define AR5K_TURBO_SYMBOL_TIME 4 - -#define AR5K_XR_SIFS_TIME 16 -#define AR5K_XR_PLCP_BITS 22 -#define AR5K_XR_SYMBOL_TIME 4 - -/* CCK */ -#define AR5K_CCK_NUM_BITS (_frmlen) (_frmlen << 3) - -#define AR5K_CCK_PHY_TIME (_sp) (_sp ? \ - ((AR5K_CCK_PREAMBLE_BITS + AR5K_CCK_PLCP_BITS) >> 1) : \ - (AR5K_CCK_PREAMBLE_BITS + AR5K_CCK_PLCP_BITS)) - -#define AR5K_CCK_TX_TIME (_kbps, _frmlen, _sp) \ - (AR5K_CCK_PHY_TIME(_sp) + \ - ((AR5K_CCK_NUM_BITS(_frmlen) * 1000) / _kbps) + \ - AR5K_CCK_SIFS_TIME) - -/* OFDM */ -#define AR5K_OFDM_NUM_BITS (_frmlen) (AR5K_OFDM_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_OFDM_NUM_BITS_PER_SYM (_kbps) ((_kbps * \ - AR5K_OFDM_SYMBOL_TIME) / 1000) - -#define AR5K_OFDM_NUM_BITS (_frmlen) (AR5K_OFDM_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_OFDM_NUM_SYMBOLS (_kbps, _frmlen) \ - DIV_ROUND_UP(AR5K_OFDM_NUM_BITS(_frmlen), \ - AR5K_OFDM_NUM_BITS_PER_SYM(_kbps)) - -#define AR5K_OFDM_TX_TIME (_kbps, _frmlen) \ - (AR5K_OFDM_PREAMBLE_TIME + AR5K_OFDM_SIFS_TIME + \ - (AR5K_OFDM_NUM_SYMBOLS(_kbps, _frmlen) * AR5K_OFDM_SYMBOL_TIME)) - -/* TURBO */ -#define AR5K_TURBO_NUM_BITS (_frmlen) (AR5K_TURBO_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_TURBO_NUM_BITS_PER_SYM (_kbps) (((_kbps << 1) * \ - AR5K_TURBO_SYMBOL_TIME) / 1000) - -#define AR5K_TURBO_NUM_BITS (_frmlen) (AR5K_TURBO_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_TURBO_NUM_SYMBOLS (_kbps, _frmlen) \ - DIV_ROUND_UP(AR5K_TURBO_NUM_BITS(_frmlen), \ - AR5K_TURBO_NUM_BITS_PER_SYM(_kbps)) - -#define AR5K_TURBO_TX_TIME (_kbps, _frmlen) \ - (AR5K_TURBO_PREAMBLE_TIME + AR5K_TURBO_SIFS_TIME + \ - (AR5K_TURBO_NUM_SYMBOLS(_kbps, _frmlen) * AR5K_TURBO_SYMBOL_TIME)) - -/* eXtendent Range (?)*/ -#define AR5K_XR_PREAMBLE_TIME (_kbps) (((_kbps) < 1000) ? 173 : 76) - -#define AR5K_XR_NUM_BITS_PER_SYM (_kbps) ((_kbps * \ - AR5K_XR_SYMBOL_TIME) / 1000) - -#define AR5K_XR_NUM_BITS (_frmlen) (AR5K_XR_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_XR_NUM_SYMBOLS (_kbps, _frmlen) \ - DIV_ROUND_UP(AR5K_XR_NUM_BITS(_frmlen), AR5K_XR_NUM_BITS_PER_SYM(_kbps)) - -#define AR5K_XR_TX_TIME (_kbps, _frmlen) \ - (AR5K_XR_PREAMBLE_TIME(_kbps) + AR5K_XR_SIFS_TIME + \ - (AR5K_XR_NUM_SYMBOLS(_kbps, _frmlen) * AR5K_XR_SYMBOL_TIME)) - -/* * DMA size definitions (2^n+2) */ enum ath5k_dmasize {
drivers/net/wireless/ath5k/hw.c +76 -125
225 lines not on this page · raw message
Signature · 1 line
1.5.2.5
PATCH 4/7 ath5k: Fix clock on OFDM timing computation
We were setting the clock to the turbo sampling rate always, lets fix this for plain OFDM sampling rate at 40 MHz. I believe this tunes the PLL to the desired frequency, by setting the mantissa and the exponent.
Changes to hw.c
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/hw.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
drivers/net/wireless/ath5k/hw.c +2 -1
@@ -698,10 +698,11 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,/* Write OFDM timings on 5212*/ if (ah->ah_version ==AR5K_AR5212 ) {if (channel->val &CHANNEL_OFDM ) { +/* Get exponent and mantissa and set it */ u32 coef_scaled, coef_exp, coef_man, ds_coef_exp, ds_coef_man, clock; - clock = channel->val &CHANNEL_T ?80 :40 ; + clock = channel->val &CHANNEL_TURBO ?80 :40 ; coef_scaled = ((5 * (clock <<24 )) /2 ) / channel->freq;
Signature · 1 line
1.5.2.5
PATCH 5/7 ath5k: Move OFDM timings into a helper routine
This move the OFDM timings on ath5k_hw_reset() onto a helper, ath5k_hw_write_ofdm_timings() to make code cleaner.
Changes to ath5k.h, hw.c
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/hw.c | 83 ++++++++++++++++++++++++++------------- 1 files changed, 55 insertions(+), 28 deletions(-)
drivers/net/wireless/ath5k/hw.c +55 -28
@@ -458,6 +458,56 @@ void ath5k_hw_detach(struct ath5k_hw *ah)*/ /** +* ath5k_hw_write_ofdm_timings - set OFDM timings on AR5212 +* +* @ah: the &struct ath5k_hw +* @channel: the currently set channel upon reset +* +* Write the OFDM timings for the AR5212 upon reset. This is a helper for +* ath5k_hw_reset(). This seems to tune the PLL a specified frequency +* depending on the bandwidth of the channel. +* +*/ +static inline int ath5k_hw_write_ofdm_timings (struct ath5k_hw *ah, +struct ieee80211_channel *channel) +{ +/* Get exponent and mantissa and set it */ +u32 coef_scaled, coef_exp, coef_man, + ds_coef_exp, ds_coef_man, clock; + +if (! (ah->ah_version ==AR5K_AR5212 ) || + ! (channel->val &CHANNEL_OFDM )) +BUG (); + +/* Seems there are two PLLs, one for baseband sampling and one +* for tuning. Tuning basebands are 40 MHz or 80MHz when in +* turbo. */ + clock = channel->val &CHANNEL_TURBO ?80 :40 ; + coef_scaled = ((5 * (clock <<24 )) /2 ) / + channel->freq; + +for (coef_exp =31 ; coef_exp >0 ; coef_exp--) +if ((coef_scaled >> coef_exp) &0x1 ) +break ; + +if (!coef_exp) +return -EINVAL ; + + coef_exp =14 - (coef_exp -24 ); + coef_man = coef_scaled + + (1 << (24 - coef_exp -1 )); + ds_coef_man = coef_man >> (24 - coef_exp); + ds_coef_exp = coef_exp -16 ; + +AR5K_REG_WRITE_BITS (ah,AR5K_PHY_TIMING_3 , +AR5K_PHY_TIMING_3_DSC_MAN , ds_coef_man); +AR5K_REG_WRITE_BITS (ah,AR5K_PHY_TIMING_3 , +AR5K_PHY_TIMING_3_DSC_EXP , ds_coef_exp); + +return 0 ; +} + +/** * ath5k_hw_write_rate_duration - set rate duration during hw resets * * @ah: the &struct ath5k_hw
@@ -696,34 +746,11 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,*/ /* Write OFDM timings on 5212*/ -if (ah->ah_version ==AR5K_AR5212 ) { -if (channel->val &CHANNEL_OFDM ) { -/* Get exponent and mantissa and set it */ -u32 coef_scaled, coef_exp, coef_man, - ds_coef_exp, ds_coef_man, clock; - - clock = channel->val &CHANNEL_TURBO ?80 :40 ; - coef_scaled = ((5 * (clock <<24 )) /2 ) / - channel->freq; - -for (coef_exp =31 ; coef_exp >0 ; coef_exp--) -if ((coef_scaled >> coef_exp) &0x1 ) -break ; - -if (!coef_exp) -return -EINVAL ; - - coef_exp =14 - (coef_exp -24 ); - coef_man = coef_scaled + - (1 << (24 - coef_exp -1 )); - ds_coef_man = coef_man >> (24 - coef_exp); - ds_coef_exp = coef_exp -16 ; - -AR5K_REG_WRITE_BITS (ah,AR5K_PHY_TIMING_3 , -AR5K_PHY_TIMING_3_DSC_MAN , ds_coef_man); -AR5K_REG_WRITE_BITS (ah,AR5K_PHY_TIMING_3 , -AR5K_PHY_TIMING_3_DSC_EXP , ds_coef_exp); - } +if (ah->ah_version ==AR5K_AR5212 && + channel->val &CHANNEL_OFDM ) { + ret =ath5k_hw_write_ofdm_timings (ah, channel); +if (ret) +return ret; }/*Enable/disable 802.11b mode on 5111
Signature · 1 line
1.5.2.5
PATCH 6/7 ath5k: Clear up settings of AR5K_RSSI_THR register settings
Clear up settings of AR5K_RSSI_THR register settings. These are split between AR5K_TUNE_BMISS_THRES and AR5K_TUNE_RSSI_THRES.
Changes to ath5k.h, hw.c
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/ath5k.h | 10 +++++++++- drivers/net/wireless/ath5k/hw.c | 11 ++++------- 2 files changed, 13 insertions(+), 8 deletions(-)
drivers/net/wireless/ath5k/ath5k.h +9 -1
@@ -86,8 +86,16 @@#define AR5K_TUNE_RADAR_ALERT false#define AR5K_TUNE_MIN_TX_FIFO_THRES 1#define AR5K_TUNE_MAX_TX_FIFO_THRES ((IEEE80211_MAX_LEN / 64) + 1) -#define AR5K_TUNE_RSSI_THRES 1792#define AR5K_TUNE_REGISTER_TIMEOUT 20000 +/* Register for RSSI threshold has a mask of 0xff, so 255 seems to +* be the max value. */ +#define AR5K_TUNE_RSSI_THRES 129 +/* This must be set when setting the RSSI threshold otherwise it can +* prevent a reset. If AR5K_RSSI_THR is read after writing to it +* the BMISS_THRES will be seen as 0, seems harware doesn't keep +* track of it. Max value depends on harware. For AR5210 this is just 7. +* For AR5211+ this seems to be up to 255. */ +#define AR5K_TUNE_BMISS_THRES 7#define AR5K_TUNE_REGISTER_DWELL_TIME 20000#define AR5K_TUNE_BEACON_INTERVAL 100#define AR5K_TUNE_AIFS 2
drivers/net/wireless/ath5k/hw.c +4 -7
@@ -849,13 +849,10 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,/*PISR/SISR Not available on 5210*/ if (ah->ah_version !=AR5K_AR5210 ) {ath5k_hw_reg_write (ah,0xffffffff ,AR5K_PISR ); -/* XXX: AR5K_RSSI_THR has masks and shifts defined for it, so -* direct write using ath5k_hw_reg_write seems wrong. Test with: -* AR5K_REG_WRITE_BITS(ah, AR5K_RSSI_THR, -* AR5K_RSSI_THR_BMISS, AR5K_TUNE_RSSI_THRES); -* with different variables and check results compared -* to ath5k_hw_reg_write(ah, ) */ -ath5k_hw_reg_write (ah,AR5K_TUNE_RSSI_THRES ,AR5K_RSSI_THR ); +/* If we later allow tuning for this, store into sc structure */ + data =AR5K_TUNE_RSSI_THRES | +AR5K_TUNE_BMISS_THRES <<AR5K_RSSI_THR_BMISS_S ; +ath5k_hw_reg_write (ah, data,AR5K_RSSI_THR ); }/*
Signature · 1 line
1.5.2.5
PATCH 7/7 ath5k: Add documentation for struct ath5k_rate
This adds documentation for struct ath5k_rate. This also removes some unused variables, lp_ack_duration and sp_ack_duration which are simply unnecessary. We obviously have information about the rest of the rate values, we can add more as we go, this just starts this up. I'll next target cleaning up the RATE macros, think that may be there the other G mode issues are in.
Changes to ath5k.h
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/ath5k.h | 58 +++++++++++++++++++++++++++++++---- 1 files changed, 51 insertions(+), 7 deletions(-)
drivers/net/wireless/ath5k/ath5k.h +51 -7
@@ -549,17 +549,61 @@ struct ath5k_athchan_2ghz {* used by the rate control algorytm on MadWiFi. */ -#define AR5K_MAX_RATES 32/*max number of rates on the rate table*/ +/* Max number of rates on the rate table and what it seems +* Atheros hardware supports */ +#define AR5K_MAX_RATES 32 +/** +* struct ath5k_rate - rate structure +* +* This structure is used to get the RX rate or set the TX rate on the +* hardware descriptors. It is also used for internal modulation control +* and settings. +* +* @valid: is this a valid rate for the current mode +* @modulation: respective mac80211 modulation +* @rate_kbps: rate in kbit/s +* @rate_code: hardware rate value, used in &struct ath5k_desc, on RX on +* &struct ath5k_rx_status.rs_rate and on TX on +* &struct ath5k_tx_status.ts_rate. Seems the ar5xxx harware supports +* up to 32 rates, indexed by 1-32. This means we really only need +* 6 bits for the rate_code. +* @dot11_rate: respective IEEE-802.11 rate value +* @control_rate: index of rate assumed to be used to send control frames. +* This can be used to set override the value on the rate duration +* registers. This is only useful if we can override in the harware at +* what rate we want to send control frames at. Note that IEEE-802.11 +* Ch. 9.6 (after IEEE 802.11g changes) defines the rate at which we +* should send ACK/CTS, if we change this value we can be breaking +* the spec. +* +* On RX after the &struct ath5k_desc is parsed by the appropriate +* ah_proc_rx_desc() the respective hardware rate value is set in +* &struct ath5k_rx_status.rs_rate. On TX the desired rate is set in +* &struct ath5k_tx_status.ts_rate which is later used to setup the +* &struct ath5k_desc correctly. This is the hardware rate map we are +* aware of: +* +* rate_code 1 2 3 4 5 6 7 8 +* rate_kbps 3000 ? ? ? ? ? ? ? +* +* rate_code 9 10 11 12 13 14 15 16 +* rate_kbps ? ? ? ? ? ? ? ? +* +* rate_code 17 18 19 20 21 22 23 24 +* rate_kbps ? ? ? ? ? ? ? ? +* +* rate_code 25 26 27 28 29 30 31 32 +* rate_kbps ? ? ? ? ? ? ? ? +* +*/ struct ath5k_rate { -u8 valid;/* Valid for rate control */ +u8 valid;u32 modulation; -u16 rate_kbps;/* Rate in kbps used in computetxtime */ -u8 rate_code;/* Rate mapping for h/w descriptors */ +u16 rate_kbps; +u8 rate_code;u8 dot11_rate; -u8 control_rate;/* Rate for management frames -not used */ -u16 lp_ack_duration;/* long preamble ACK duration -not used */ -u16 sp_ack_duration;/* short preamble ACK duration -not used */ +u8 control_rate; };/* XXX: GRR all this stuff to get leds blinking ??? (check out setcurmode) */
Signature · 1 line
1.5.2.5
Re: [PATCH 7/7] ath5k: Add documentation for struct ath5k_rate
2007/11/1, Luis R. Rodriguez <[email protected]>:
Quoted 89 lines
This adds documentation for struct
ath5k_rate. This also removes some unused variables,lp_ack_durationandsp_ack_durationwhich are simply unnecessary. We obviously have information about the rest of the rate values, we can add more as we go, this just starts this up. I'll next target cleaning up the RATE macros, think that may be there the other G mode issues are in.Changes to
ath5k.h
Changes-licensed-under: ISCSigned-off-by Luis R. Rodriguez <[email protected]>--- drivers/net/wireless/ath5k/ath5k.h | 58 +++++++++++++++++++++++++++++++---- 1 files changed, 51 insertions(+), 7 deletions(-)drivers/net/wireless/ath5k/ath5k.h +51
-8@@ -549,17 +549,61 @@ struct ath5k_athchan_2ghz {* used by the rate control algorytm on MadWiFi. */ -#define AR5K_MAX_RATES 32/*max number of rates on the rate table*/ +/* Max number of rates on the rate table and what it seems +* Atheros hardware supports */ +#define AR5K_MAX_RATES 32 +/** +* struct ath5k_rate - rate structure +* +* This structure is used to get the RX rate or set the TX rate on the +* hardware descriptors. It is also used for internal modulation control +* and settings. +* +* @valid: is this a valid rate for the current mode +* @modulation: respective mac80211 modulation +* @rate_kbps: rate in kbit/s +* @rate_code: hardware rate value, used in &struct ath5k_desc, on RX on +* &struct ath5k_rx_status.rs_rate and on TX on +* &struct ath5k_tx_status.ts_rate. Seems the ar5xxx harware supports +* up to 32 rates, indexed by 1-32. This means we really only need +* 6 bits for the rate_code. +* @dot11_rate: respective IEEE-802.11 rate value +* @control_rate: index of rate assumed to be used to send control frames. +* This can be used to set override the value on the rate duration +* registers. This is only useful if we can override in the harware at +* what rate we want to send control frames at. Note that IEEE-802.11 +* Ch. 9.6 (after IEEE 802.11g changes) defines the rate at which we +* should send ACK/CTS, if we change this value we can be breaking +* the spec. +* +* On RX after the &struct ath5k_desc is parsed by the appropriate +* ah_proc_rx_desc() the respective hardware rate value is set in +* &struct ath5k_rx_status.rs_rate. On TX the desired rate is set in +* &struct ath5k_tx_status.ts_rate which is later used to setup the +* &struct ath5k_desc correctly. This is the hardware rate map we are +* aware of: +* +* rate_code 1 2 3 4 5 6 7 8 +* rate_kbps 3000 ? ? ? ? ? ? ? +* +* rate_code 9 10 11 12 13 14 15 16 +* rate_kbps ? ? ? ? ? ? ? ? +* +* rate_code 17 18 19 20 21 22 23 24 +* rate_kbps ? ? ? ? ? ? ? ? +* +* rate_code 25 26 27 28 29 30 31 32 +* rate_kbps ? ? ? ? ? ? ? ? +* +*/ struct ath5k_rate { -u8 valid;/* Valid for rate control */ +u8 valid;u32 modulation; -u16 rate_kbps;/* Rate in kbps used in computetxtime */ -u8 rate_code;/* Rate mapping for h/w descriptors */ +u16 rate_kbps; +u8 rate_code;u8 dot11_rate; -u8 control_rate;/* Rate for management frames -not used */ -u16 lp_ack_duration;/* long preamble ACK duration -not used */ -u16 sp_ack_duration;/* short preamble ACK duration -not used */ +u8 control_rate; };/* XXX: GRR all this stuff to get leds blinking ??? (check out setcurmode) */ --
Quoted 3 lines
1.5.2.5
Also checkout setcurmode function, i believe we can live without all this led-timing stuff and clean up both rate tables and related functions.
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick
Re: [PATCH 7/7] ath5k: Add documentation for struct ath5k_rate
Quoted 5 lines · Nick Kossifidis
Acked-by Nick Kossifidis <[email protected]>Also checkout setcurmode function, i believe we can live without all this led-timing stuff and clean up both rate tables and related functions.
Yeap -- that is where I am sweeping next. The documentation of the rates was added in a specific column arrangement for a good reason :)
Luis
Re: [PATCH 7/7] ath5k: Add documentation for struct ath5k_rate
In reply to Luis R. Rodriguez** Resending after checkpatch.pl
This adds documentation for struct ath5k_rate. This also removes some unused variables, lp_ack_duration and sp_ack_duration which are simply unnecessary. We obviously have information about the rest of the rate values, we can add more as we go, this just starts this up. I'll next target cleaning up the RATE macros, think that may be there the other G mode issues are in.
Changes to ath5k.h
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/ath5k.h | 58 +++++++++++++++++++++++++++++++---- 1 files changed, 51 insertions(+), 7 deletions(-)
drivers/net/wireless/ath5k/ath5k.h +51 -7
@@ -549,17 +549,61 @@ struct ath5k_athchan_2ghz {* used by the rate control algorytm on MadWiFi. */ -#define AR5K_MAX_RATES 32/*max number of rates on the rate table*/ +/* Max number of rates on the rate table and what it seems +* Atheros hardware supports */ +#define AR5K_MAX_RATES 32 +/** +* struct ath5k_rate - rate structure +* +* This structure is used to get the RX rate or set the TX rate on the +* hardware descriptors. It is also used for internal modulation control +* and settings. +* +* @valid: is this a valid rate for the current mode +* @modulation: respective mac80211 modulation +* @rate_kbps: rate in kbit/s +* @rate_code: hardware rate value, used in &struct ath5k_desc, on RX on +* &struct ath5k_rx_status.rs_rate and on TX on +* &struct ath5k_tx_status.ts_rate. Seems the ar5xxx harware supports +* up to 32 rates, indexed by 1-32. This means we really only need +* 6 bits for the rate_code. +* @dot11_rate: respective IEEE-802.11 rate value +* @control_rate: index of rate assumed to be used to send control frames. +* This can be used to set override the value on the rate duration +* registers. This is only useful if we can override in the harware at +* what rate we want to send control frames at. Note that IEEE-802.11 +* Ch. 9.6 (after IEEE 802.11g changes) defines the rate at which we +* should send ACK/CTS, if we change this value we can be breaking +* the spec. +* +* On RX after the &struct ath5k_desc is parsed by the appropriate +* ah_proc_rx_desc() the respective hardware rate value is set in +* &struct ath5k_rx_status.rs_rate. On TX the desired rate is set in +* &struct ath5k_tx_status.ts_rate which is later used to setup the +* &struct ath5k_desc correctly. This is the hardware rate map we are +* aware of: +* +* rate_code 1 2 3 4 5 6 7 8 +* rate_kbps 3000 ? ? ? ? ? ? ? +* +* rate_code 9 10 11 12 13 14 15 16 +* rate_kbps ? ? ? ? ? ? ? ? +* +* rate_code 17 18 19 20 21 22 23 24 +* rate_kbps ? ? ? ? ? ? ? ? +* +* rate_code 25 26 27 28 29 30 31 32 +* rate_kbps ? ? ? ? ? ? ? ? +* +*/ struct ath5k_rate { -u8 valid;/* Valid for rate control */ +u8 valid;u32 modulation; -u16 rate_kbps;/* Rate in kbps used in computetxtime */ -u8 rate_code;/* Rate mapping for h/w descriptors */ +u16 rate_kbps; +u8 rate_code;u8 dot11_rate; -u8 control_rate;/* Rate for management frames -not used */ -u16 lp_ack_duration;/* long preamble ACK duration -not used */ -u16 sp_ack_duration;/* short preamble ACK duration -not used */ +u8 control_rate; };/* XXX: GRR all this stuff to get leds blinking ??? (check out setcurmode) */
Signature · 1 line
1.5.2.5
Re: [PATCH 7/7] ath5k: Add documentation for struct ath5k_rate
Quoted 8 lines · On Thu, 1 Nov 2007 17:56:40 -0400 Luis R. Rodriguez wrote:
** Resending after checkpatch.pl
This adds documentation for struct
ath5k_rate. This also removes some unused variables,lp_ack_durationandsp_ack_durationwhich are simply unnecessary. We obviously have information about the rest of the rate values, we can add more as we go, this just starts this up. I'll next target cleaning up the RATE macros, think that may be there the other G mode issues are in.
Thanks for doing this... but one more change, please:
(just move lines around, see below)
Quoted 13 lines
Changes to
ath5k.h
Changes-licensed-under: ISCSigned-off-by Luis R. Rodriguez <[email protected]>--- drivers/net/wireless/ath5k/ath5k.h | 58 +++++++++++++++++++++++++++++++---- 1 files changed, 51 insertions(+), 7 deletions(-)drivers/net/wireless/ath5k/ath5k.h +0
-0
drivers/net/wireless/ath5k/ath5k.h struct ath5k_athchan_2ghz { · line 554
Quoted 7 lines
drivers/net/wireless/ath5k/ath5k.h +3
-1@@ -549,17 +549,61 @@ struct ath5k_athchan_2ghz {* used by the rate control algorytm on MadWiFi. */ -#define AR5K_MAX_RATES 32/*max number of rates on the rate table*/ +/* Max number of rates on the rate table and what it seems +* Atheros hardware supports */ +#define AR5K_MAX_RATES 32
As described in Documentation/kernel-doc-nano-HOWTO.txt, the structure fields/members should immediately follow the first line. After all of the fields/members, you can add general info, like the first paragraph that is here.
Example from that doc file:
/**
* struct my_struct - short description
* @a: first member
* @b: second member
*
* Longer description
*/
Quoted 51 lines
drivers/net/wireless/ath5k/ath5k.h +45
-3+/** +* struct ath5k_rate - rate structure +* +* This structure is used to get the RX rate or set the TX rate on the +* hardware descriptors. It is also used for internal modulation control +* and settings. +* +* @valid: is this a valid rate for the current mode +* @modulation: respective mac80211 modulation +* @rate_kbps: rate in kbit/s +* @rate_code: hardware rate value, used in &struct ath5k_desc, on RX on +* &struct ath5k_rx_status.rs_rate and on TX on +* &struct ath5k_tx_status.ts_rate. Seems the ar5xxx harware supports +* up to 32 rates, indexed by 1-32. This means we really only need +* 6 bits for the rate_code. +* @dot11_rate: respective IEEE-802.11 rate value +* @control_rate: index of rate assumed to be used to send control frames. +* This can be used to set override the value on the rate duration +* registers. This is only useful if we can override in the harware at +* what rate we want to send control frames at. Note that IEEE-802.11 +* Ch. 9.6 (after IEEE 802.11g changes) defines the rate at which we +* should send ACK/CTS, if we change this value we can be breaking +* the spec. +* +* On RX after the &struct ath5k_desc is parsed by the appropriate +* ah_proc_rx_desc() the respective hardware rate value is set in +* &struct ath5k_rx_status.rs_rate. On TX the desired rate is set in +* &struct ath5k_tx_status.ts_rate which is later used to setup the +* &struct ath5k_desc correctly. This is the hardware rate map we are +* aware of: +* +* rate_code 1 2 3 4 5 6 7 8 +* rate_kbps 3000 ? ? ? ? ? ? ? +* +* rate_code 9 10 11 12 13 14 15 16 +* rate_kbps ? ? ? ? ? ? ? ? +* +* rate_code 17 18 19 20 21 22 23 24 +* rate_kbps ? ? ? ? ? ? ? ? +* +* rate_code 25 26 27 28 29 30 31 32 +* rate_kbps ? ? ? ? ? ? ? ? +* +*/ struct ath5k_rate { -u8 valid;/* Valid for rate control */ +u8 valid;u32 modulation; -u16 rate_kbps;/* Rate in kbps used in computetxtime */ -u8 rate_code;/* Rate mapping for h/w descriptors */
drivers/net/wireless/ath5k/ath5k.h struct ath5k_athchan_2ghz { · line 609
Quoted 10 lines
drivers/net/wireless/ath5k/ath5k.h +3
-3+u16 rate_kbps; +u8 rate_code;u8 dot11_rate; -u8 control_rate;/* Rate for management frames -not used */ -u16 lp_ack_duration;/* long preamble ACK duration -not used */ -u16 sp_ack_duration;/* short preamble ACK duration -not used */ +u8 control_rate; };/* XXX: GRR all this stuff to get leds blinking ??? (check out setcurmode) */
---
~Randy
Re: [PATCH 7/7] ath5k: Add documentation for struct ath5k_rate
Quoted 43 lines · Randy Dunlap
Quoted 8 lines · On Thu, 1 Nov 2007 17:56:40 -0400 Luis R. Rodriguez wrote:
** Resending after checkpatch.pl
This adds documentation for struct
ath5k_rate. This also removes some unused variables,lp_ack_durationandsp_ack_durationwhich are simply unnecessary. We obviously have information about the rest of the rate values, we can add more as we go, this just starts this up. I'll next target cleaning up the RATE macros, think that may be there the other G mode issues are in.Thanks for doing this... but one more change, please:
(just move lines around, see below)Quoted 13 lines
Changes to
ath5k.h
Changes-licensed-under: ISCSigned-off-by Luis R. Rodriguez <[email protected]>--- drivers/net/wireless/ath5k/ath5k.h | 58 +++++++++++++++++++++++++++++++---- 1 files changed, 51 insertions(+), 7 deletions(-)drivers/net/wireless/ath5k/ath5k.h +0
-0drivers/net/wireless/ath5k/ath5k.h struct ath5k_athchan_2ghz { · line 554
Quoted 7 lines
drivers/net/wireless/ath5k/ath5k.h +3
-1@@ -549,17 +549,61 @@ struct ath5k_athchan_2ghz {* used by the rate control algorytm on MadWiFi. */ -#define AR5K_MAX_RATES 32/*max number of rates on the rate table*/ +/* Max number of rates on the rate table and what it seems +* Atheros hardware supports */ +#define AR5K_MAX_RATES 32As described in
Documentation/kernel-doc-nano-HOWTO.txt, the structure fields/members should immediately follow the first line. After all of the fields/members, you can add general info, like the first paragraph that is here.Example from that doc file:
Quoted 7 lines
/**
* structmy_struct- short description
* @a: first member
* @b: second member
*
* Longer description
*/
New patch, completes the docs and addresses Randy's points.
This adds documentation for struct ath5k_rate. This also removes some unused variables, lp_ack_duration and sp_ack_duration which are simply unnecessary.
We're now just missing information about rate hw values:
3-5
16
17-23
28-32
If anyone knows what those are, please let us know.
Changes to ath5k.h
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/ath5k.h | 58 +++++++++++++++++++++++++++++++---- 1 files changed, 51 insertions(+), 7 deletions(-)
drivers/net/wireless/ath5k/ath5k.h +50 -7
@@ -549,17 +549,60 @@ struct ath5k_athchan_2ghz {* used by the rate control algorytm on MadWiFi. */ -#define AR5K_MAX_RATES 32/*max number of rates on the rate table*/ +/* Max number of rates on the rate table and what it seems +* Atheros hardware supports */ +#define AR5K_MAX_RATES 32 +/** +* struct ath5k_rate - rate structure +* @valid: is this a valid rate for the current mode +* @modulation: respective mac80211 modulation +* @rate_kbps: rate in kbit/s +* @rate_code: hardware rate value, used in &struct ath5k_desc, on RX on +* &struct ath5k_rx_status.rs_rate and on TX on +* &struct ath5k_tx_status.ts_rate. Seems the ar5xxx harware supports +* up to 32 rates, indexed by 1-32. This means we really only need +* 6 bits for the rate_code. +* @dot11_rate: respective IEEE-802.11 rate value +* @control_rate: index of rate assumed to be used to send control frames. +* This can be used to set override the value on the rate duration +* registers. This is only useful if we can override in the harware at +* what rate we want to send control frames at. Note that IEEE-802.11 +* Ch. 9.6 (after IEEE 802.11g changes) defines the rate at which we +* should send ACK/CTS, if we change this value we can be breaking +* the spec. +* +* This structure is used to get the RX rate or set the TX rate on the +* hardware descriptors. It is also used for internal modulation control +* and settings. +* +* On RX after the &struct ath5k_desc is parsed by the appropriate +* ah_proc_rx_desc() the respective hardware rate value is set in +* &struct ath5k_rx_status.rs_rate. On TX the desired rate is set in +* &struct ath5k_tx_status.ts_rate which is later used to setup the +* &struct ath5k_desc correctly. This is the hardware rate map we are +* aware of: +* +* rate_code 1 2 3 4 5 6 7 8 +* rate_kbps 3000 1000 ? ? ? 2000 500 48000 +* +* rate_code 9 10 11 12 13 14 15 16 +* rate_kbps 24000 12000 6000 54000 36000 18000 9000 ? +* +* rate_code 17 18 19 20 21 22 23 24 +* rate_kbps ? ? ? ? ? ? ? 11000 +* +* rate_code 25 26 27 28 29 30 31 32 +* rate_kbps 5500 2000 1000 ? ? ? ? ? +* +*/ struct ath5k_rate { -u8 valid;/* Valid for rate control */ +u8 valid;u32 modulation; -u16 rate_kbps;/* Rate in kbps used in computetxtime */ -u8 rate_code;/* Rate mapping for h/w descriptors */ +u16 rate_kbps; +u8 rate_code;u8 dot11_rate; -u8 control_rate;/* Rate for management frames -not used */ -u16 lp_ack_duration;/* long preamble ACK duration -not used */ -u16 sp_ack_duration;/* short preamble ACK duration -not used */ +u8 control_rate; };/* XXX: GRR all this stuff to get leds blinking ??? (check out setcurmode) */
Re: [PATCH 6/7] ath5k: Clear up settings of AR5K_RSSI_THR register settings
In reply to Luis R. Rodriguez2007/11/1, Luis R. Rodriguez <[email protected]>:
Quoted 57 lines
Clear up settings of
AR5K_RSSI_THRregister settings. These are split betweenAR5K_TUNE_BMISS_THRESandAR5K_TUNE_RSSI_THRES.Changes to
ath5k.h,hw.c
Changes-licensed-under: ISCSigned-off-by Luis R. Rodriguez <[email protected]>--- drivers/net/wireless/ath5k/ath5k.h | 10 +++++++++- drivers/net/wireless/ath5k/hw.c | 11 ++++------- 2 files changed, 13 insertions(+), 8 deletions(-)drivers/net/wireless/ath5k/ath5k.h +9
-1@@ -86,8 +86,16 @@#define AR5K_TUNE_RADAR_ALERT false#define AR5K_TUNE_MIN_TX_FIFO_THRES 1#define AR5K_TUNE_MAX_TX_FIFO_THRES ((IEEE80211_MAX_LEN / 64) + 1) -#define AR5K_TUNE_RSSI_THRES 1792#define AR5K_TUNE_REGISTER_TIMEOUT 20000 +/* Register for RSSI threshold has a mask of 0xff, so 255 seems to +* be the max value. */ +#define AR5K_TUNE_RSSI_THRES 129 +/* This must be set when setting the RSSI threshold otherwise it can +* prevent a reset. If AR5K_RSSI_THR is read after writing to it +* the BMISS_THRES will be seen as 0, seems harware doesn't keep +* track of it. Max value depends on harware. For AR5210 this is just 7. +* For AR5211+ this seems to be up to 255. */ +#define AR5K_TUNE_BMISS_THRES 7#define AR5K_TUNE_REGISTER_DWELL_TIME 20000#define AR5K_TUNE_BEACON_INTERVAL 100#define AR5K_TUNE_AIFS 2drivers/net/wireless/ath5k/hw.c +4
-8@@ -849,13 +849,10 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,/*PISR/SISR Not available on 5210*/ if (ah->ah_version !=AR5K_AR5210 ) {ath5k_hw_reg_write (ah,0xffffffff ,AR5K_PISR ); -/* XXX: AR5K_RSSI_THR has masks and shifts defined for it, so -* direct write using ath5k_hw_reg_write seems wrong. Test with: -* AR5K_REG_WRITE_BITS(ah, AR5K_RSSI_THR, -* AR5K_RSSI_THR_BMISS, AR5K_TUNE_RSSI_THRES); -* with different variables and check results compared -* to ath5k_hw_reg_write(ah, ) */ -ath5k_hw_reg_write (ah,AR5K_TUNE_RSSI_THRES ,AR5K_RSSI_THR ); +/* If we later allow tuning for this, store into sc structure */ + data =AR5K_TUNE_RSSI_THRES | +AR5K_TUNE_BMISS_THRES <<AR5K_RSSI_THR_BMISS_S ; +ath5k_hw_reg_write (ah, data,AR5K_RSSI_THR ); }/* --
Quoted 3 lines
1.5.2.5
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick
Re: [PATCH 6/7] ath5k: Clear up settings of AR5K_RSSI_THR register settings
In reply to Luis R. Rodriguez** Resending after checkpatch.pl
Clear up settings of AR5K_RSSI_THR register settings. These are split between AR5K_TUNE_BMISS_THRES and AR5K_TUNE_RSSI_THRES.
Changes to ath5k.h, hw.c
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/ath5k.h | 10 +++++++++- drivers/net/wireless/ath5k/hw.c | 11 ++++------- 2 files changed, 13 insertions(+), 8 deletions(-)
drivers/net/wireless/ath5k/ath5k.h +9 -1
@@ -86,8 +86,16 @@#define AR5K_TUNE_RADAR_ALERT false#define AR5K_TUNE_MIN_TX_FIFO_THRES 1#define AR5K_TUNE_MAX_TX_FIFO_THRES ((IEEE80211_MAX_LEN / 64) + 1) -#define AR5K_TUNE_RSSI_THRES 1792#define AR5K_TUNE_REGISTER_TIMEOUT 20000 +/* Register for RSSI threshold has a mask of 0xff, so 255 seems to +* be the max value. */ +#define AR5K_TUNE_RSSI_THRES 129 +/* This must be set when setting the RSSI threshold otherwise it can +* prevent a reset. If AR5K_RSSI_THR is read after writing to it +* the BMISS_THRES will be seen as 0, seems harware doesn't keep +* track of it. Max value depends on harware. For AR5210 this is just 7. +* For AR5211+ this seems to be up to 255. */ +#define AR5K_TUNE_BMISS_THRES 7#define AR5K_TUNE_REGISTER_DWELL_TIME 20000#define AR5K_TUNE_BEACON_INTERVAL 100#define AR5K_TUNE_AIFS 2
drivers/net/wireless/ath5k/hw.c +4 -7
@@ -849,13 +849,10 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,/*PISR/SISR Not available on 5210*/ if (ah->ah_version !=AR5K_AR5210 ) {ath5k_hw_reg_write (ah,0xffffffff ,AR5K_PISR ); -/* XXX: AR5K_RSSI_THR has masks and shifts defined for it, so -* direct write using ath5k_hw_reg_write seems wrong. Test with: -* AR5K_REG_WRITE_BITS(ah, AR5K_RSSI_THR, -* AR5K_RSSI_THR_BMISS, AR5K_TUNE_RSSI_THRES); -* with different variables and check results compared -* to ath5k_hw_reg_write(ah, ) */ -ath5k_hw_reg_write (ah,AR5K_TUNE_RSSI_THRES ,AR5K_RSSI_THR ); +/* If we later allow tuning for this, store into sc structure */ + data =AR5K_TUNE_RSSI_THRES | +AR5K_TUNE_BMISS_THRES <<AR5K_RSSI_THR_BMISS_S ; +ath5k_hw_reg_write (ah, data,AR5K_RSSI_THR ); }/*
Signature · 1 line
1.5.2.5
Re: [PATCH 5/7] ath5k: Move OFDM timings into a helper routine
In reply to Luis R. Rodriguez** Resending after checkpatch.pl..
This move the OFDM timings on ath5k_hw_reset() onto a helper, ath5k_hw_write_ofdm_timings() to make code cleaner.
Changes to ath5k.h, hw.c
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/hw.c | 83 ++++++++++++++++++++++++++------------- 1 files changed, 55 insertions(+), 28 deletions(-)
drivers/net/wireless/ath5k/hw.c +55 -28
@@ -458,6 +458,56 @@ void ath5k_hw_detach(struct ath5k_hw *ah)*/ /** +* ath5k_hw_write_ofdm_timings - set OFDM timings on AR5212 +* +* @ah: the &struct ath5k_hw +* @channel: the currently set channel upon reset +* +* Write the OFDM timings for the AR5212 upon reset. This is a helper for +* ath5k_hw_reset(). This seems to tune the PLL a specified frequency +* depending on the bandwidth of the channel. +* +*/ +static inline int ath5k_hw_write_ofdm_timings (struct ath5k_hw *ah, +struct ieee80211_channel *channel) +{ +/* Get exponent and mantissa and set it */ +u32 coef_scaled, coef_exp, coef_man, + ds_coef_exp, ds_coef_man, clock; + +if (!(ah->ah_version ==AR5K_AR5212 ) || + !(channel->val &CHANNEL_OFDM )) +BUG (); + +/* Seems there are two PLLs, one for baseband sampling and one +* for tuning. Tuning basebands are 40 MHz or 80MHz when in +* turbo. */ + clock = channel->val &CHANNEL_TURBO ?80 :40 ; + coef_scaled = ((5 * (clock <<24 )) /2 ) / + channel->freq; + +for (coef_exp =31 ; coef_exp >0 ; coef_exp--) +if ((coef_scaled >> coef_exp) &0x1 ) +break ; + +if (!coef_exp) +return -EINVAL ; + + coef_exp =14 - (coef_exp -24 ); + coef_man = coef_scaled + + (1 << (24 - coef_exp -1 )); + ds_coef_man = coef_man >> (24 - coef_exp); + ds_coef_exp = coef_exp -16 ; + +AR5K_REG_WRITE_BITS (ah,AR5K_PHY_TIMING_3 , +AR5K_PHY_TIMING_3_DSC_MAN , ds_coef_man); +AR5K_REG_WRITE_BITS (ah,AR5K_PHY_TIMING_3 , +AR5K_PHY_TIMING_3_DSC_EXP , ds_coef_exp); + +return 0 ; +} + +/** * ath5k_hw_write_rate_duration - set rate duration during hw resets * * @ah: the &struct ath5k_hw
@@ -696,34 +746,11 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,*/ /* Write OFDM timings on 5212*/ -if (ah->ah_version ==AR5K_AR5212 ) { -if (channel->val &CHANNEL_OFDM ) { -/* Get exponent and mantissa and set it */ -u32 coef_scaled, coef_exp, coef_man, - ds_coef_exp, ds_coef_man, clock; - - clock = channel->val &CHANNEL_TURBO ?80 :40 ; - coef_scaled = ((5 * (clock <<24 )) /2 ) / - channel->freq; - -for (coef_exp =31 ; coef_exp >0 ; coef_exp--) -if ((coef_scaled >> coef_exp) &0x1 ) -break ; - -if (!coef_exp) -return -EINVAL ; - - coef_exp =14 - (coef_exp -24 ); - coef_man = coef_scaled + - (1 << (24 - coef_exp -1 )); - ds_coef_man = coef_man >> (24 - coef_exp); - ds_coef_exp = coef_exp -16 ; - -AR5K_REG_WRITE_BITS (ah,AR5K_PHY_TIMING_3 , -AR5K_PHY_TIMING_3_DSC_MAN , ds_coef_man); -AR5K_REG_WRITE_BITS (ah,AR5K_PHY_TIMING_3 , -AR5K_PHY_TIMING_3_DSC_EXP , ds_coef_exp); - } +if (ah->ah_version ==AR5K_AR5212 && + channel->val &CHANNEL_OFDM ) { + ret =ath5k_hw_write_ofdm_timings (ah, channel); +if (ret) +return ret; }/*Enable/disable 802.11b mode on 5111
Signature · 1 line
1.5.2.5
Re: [PATCH 5/7] ath5k: Move OFDM timings into a helper routine
Quoted 31 lines · Luis R. Rodriguez
** Resending after checkpatch.pl..
This move the OFDM timings on
ath5k_hw_reset()onto a helper,ath5k_hw_write_ofdm_timings()to make code cleaner.Changes to
ath5k.h,hw.c
Changes-licensed-under: ISCSigned-off-by Luis R. Rodriguez <[email protected]>--- drivers/net/wireless/ath5k/hw.c | 83 ++++++++++++++++++++++++++------------- 1 files changed, 55 insertions(+), 28 deletions(-)drivers/net/wireless/ath5k/hw.c +10
-0@@ -458,6 +458,56 @@ void ath5k_hw_detach(struct ath5k_hw *ah)*/ /** +* ath5k_hw_write_ofdm_timings - set OFDM timings on AR5212 +* +* @ah: the &struct ath5k_hw +* @channel: the currently set channel upon reset +* +* Write the OFDM timings for the AR5212 upon reset. This is a helper for +* ath5k_hw_reset(). This seems to tune the PLL a specified frequency +* depending on the bandwidth of the channel. +* +*/
drivers/net/wireless/ath5k/hw.c void ath5k_hw_detach(struct ath5k_hw *ah) · line 480
Quoted 10 lines
drivers/net/wireless/ath5k/hw.c +10
-0+static inline int ath5k_hw_write_ofdm_timings (struct ath5k_hw *ah, +struct ieee80211_channel *channel) +{ +/* Get exponent and mantissa and set it */ +u32 coef_scaled, coef_exp, coef_man, + ds_coef_exp, ds_coef_man, clock; + +if (!(ah->ah_version ==AR5K_AR5212 ) || + !(channel->val &CHANNEL_OFDM )) +BUG ();
Note, that BUG can return (on configurations where !CONFIG_BUG). It is my fault writing you it won't, sorry! Could you post a patch which will add return from here and also from places where the BUG() is used in other places?
drivers/net/wireless/ath5k/hw.c void ath5k_hw_detach(struct ath5k_hw *ah) · line 487
Quoted 7 lines
drivers/net/wireless/ath5k/hw.c +7
-0+ +/* Seems there are two PLLs, one for baseband sampling and one +* for tuning. Tuning basebands are 40 MHz or 80MHz when in +* turbo. */ + clock = channel->val &CHANNEL_TURBO ?80 :40 ; + coef_scaled = ((5 * (clock <<24 )) /2 ) / + channel->freq;
thanks,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: [PATCH 5/7] ath5k: Move OFDM timings into a helper routine
Quoted 38 lines · Jiri Slaby
Quoted 37 lines · Luis R. Rodriguez
** Resending after checkpatch.pl..
This move the OFDM timings on
ath5k_hw_reset()onto a helper,ath5k_hw_write_ofdm_timings()to make code cleaner.Changes to
ath5k.h,hw.c
Changes-licensed-under: ISCSigned-off-by Luis R. Rodriguez <[email protected]>--- drivers/net/wireless/ath5k/hw.c | 83 ++++++++++++++++++++++++++------------- 1 files changed, 55 insertions(+), 28 deletions(-)drivers/net/wireless/ath5k/hw.c +16
-0@@ -458,6 +458,56 @@ void ath5k_hw_detach(struct ath5k_hw *ah)*/ /** +* ath5k_hw_write_ofdm_timings - set OFDM timings on AR5212 +* +* @ah: the &struct ath5k_hw +* @channel: the currently set channel upon reset +* +* Write the OFDM timings for the AR5212 upon reset. This is a helper for +* ath5k_hw_reset(). This seems to tune the PLL a specified frequency +* depending on the bandwidth of the channel. +* +*/ +static inline int ath5k_hw_write_ofdm_timings (struct ath5k_hw *ah, +struct ieee80211_channel *channel) +{ +/* Get exponent and mantissa and set it */ +u32 coef_scaled, coef_exp, coef_man, + ds_coef_exp, ds_coef_man, clock;
Quoted 8 lines
drivers/net/wireless/ath5k/hw.c void ath5k_hw_detach(struct ath5k_hw *ah) · line 480
Quoted 4 lines
drivers/net/wireless/ath5k/hw.c +4
-0+ +if (!(ah->ah_version ==AR5K_AR5212 ) || + !(channel->val &CHANNEL_OFDM )) +BUG ();Note, that BUG can return (on configurations where !CONFIG_BUG). It is my fault writing you it won't, sorry! Could you post a patch which will add return from here and also from places where the
BUG()is used in other places?
The only case where this will trigger is if someone in the driver called this on hardware not supported so it is intended.
Do you want to BUG() and also return?
Quoted 7 lines
drivers/net/wireless/ath5k/hw.c void ath5k_hw_detach(struct ath5k_hw *ah) · line 487
Quoted 7 lines
drivers/net/wireless/ath5k/hw.c +7
-0+ +/* Seems there are two PLLs, one for baseband sampling and one +* for tuning. Tuning basebands are 40 MHz or 80MHz when in +* turbo. */ + clock = channel->val &CHANNEL_TURBO ?80 :40 ; + coef_scaled = ((5 * (clock <<24 )) /2 ) / + channel->freq;
Luis
Re: [PATCH 5/7] ath5k: Move OFDM timings into a helper routine
Quoted 5 lines · Luis R. Rodriguez
Quoted 4 lines · Jiri Slaby
Quoted 3 lines · Luis R. Rodriguez
drivers/net/wireless/ath5k/hw.c +3
-0+if (!(ah->ah_version ==AR5K_AR5212 ) || + !(channel->val &CHANNEL_OFDM )) +BUG ();
Quoted 8 lines
Quoted 3 lines
Note, that BUG can return (on configurations where !CONFIG_BUG). It is my fault writing you it won't, sorry! Could you post a patch which will add return from here and also from places where the
BUG()is used in other places?The only case where this will trigger is if someone in the driver called this on hardware not supported so it is intended.
Do you want to
BUG()and also return?
Yes, exactly.
Jiri Slaby
Acked-byRe: [PATCH 5/7] ath5k: Move OFDM timings into a helper routine
In reply to Jiri SlabyQuoted 3 lines · Jiri Slaby
Note, that BUG can return (on configurations where !CONFIG_BUG). It is my fault writing you it won't, sorry! Could you post a patch which will add return from here and also from places where the
BUG()is used in other places?
Ok, after a talk we agreed, that making the BUG() a void is non-recommended option on embedded and we can let the patch as it is. Hence it is
Nick Kossifidis
Acked-byRe: [PATCH 5/7] ath5k: Move OFDM timings into a helper routine
2007/11/2, Jiri Slaby <[email protected]>:
Quoted 9 lines · Jiri Slaby
Quoted 3 lines
Note, that BUG can return (on configurations where !CONFIG_BUG). It is my fault writing you it won't, sorry! Could you post a patch which will add return from here and also from places where the
BUG()is used in other places?Ok, after a talk we agreed, that making the
BUG()a void is non-recommended option on embedded and we can let the patch as it is. Hence it isAcked-by Jiri Slaby <[email protected]>
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick
Re: [PATCH 3/7] ath5k: Clean up ath5k rate duration settings
In reply to Luis R. RodriguezReplace ath5k's rate duration computations for one using mac80211's internals. Another consideration here is to simply remove these and put them into initval values. They seem to be static values based only on mode. We can do this later though once we can physically confirm by trial and error these are indeed just used for ACK timeout. The next puzzle is figuring out which registers are actually setting the control rates.
Changes to ath5k.h, hw.c
Changes-licensed-under: ISC
From: Luis R. Rodriguez <[email protected]>
To: John Linville <[email protected]>
Cc: [email protected], "Jiri Slaby" <[email protected]>,
"Nick Kossifidis" <[email protected]>
Subject: [PATCH 3/7] ath5k: Clean up ath5k rate duration settings
** Resending after running through checkpatch.pl, removes ** some trailing whitespaces.
Replace ath5k's rate duration computations for one using mac80211's internals. Another consideration here is to simply remove these and put them into initval values. They seem to be static values based only on mode.
Changes to ath5k.h, hw.c
Changes-licensed-under: ISC
--- drivers/net/wireless/ath5k/ath5k.h | 80 -------------- drivers/net/wireless/ath5k/hw.c | 201 ++++++++++++++---------------------- 2 files changed, 76 insertions(+), 205 deletions(-)
drivers/net/wireless/ath5k/ath5k.h +0 -80
@@ -374,86 +374,6 @@ enum ath5k_pkt_type { )/* -* Used to compute TX times -*/ -#define AR5K_CCK_SIFS_TIME 10 -#define AR5K_CCK_PREAMBLE_BITS 144 -#define AR5K_CCK_PLCP_BITS 48 - -#define AR5K_OFDM_SIFS_TIME 16 -#define AR5K_OFDM_PREAMBLE_TIME 20 -#define AR5K_OFDM_PLCP_BITS 22 -#define AR5K_OFDM_SYMBOL_TIME 4 - -#define AR5K_TURBO_SIFS_TIME 8 -#define AR5K_TURBO_PREAMBLE_TIME 14 -#define AR5K_TURBO_PLCP_BITS 22 -#define AR5K_TURBO_SYMBOL_TIME 4 - -#define AR5K_XR_SIFS_TIME 16 -#define AR5K_XR_PLCP_BITS 22 -#define AR5K_XR_SYMBOL_TIME 4 - -/* CCK */ -#define AR5K_CCK_NUM_BITS (_frmlen) (_frmlen << 3) - -#define AR5K_CCK_PHY_TIME (_sp) (_sp ? \ - ((AR5K_CCK_PREAMBLE_BITS + AR5K_CCK_PLCP_BITS) >> 1) : \ - (AR5K_CCK_PREAMBLE_BITS + AR5K_CCK_PLCP_BITS)) - -#define AR5K_CCK_TX_TIME (_kbps, _frmlen, _sp) \ - (AR5K_CCK_PHY_TIME(_sp) + \ - ((AR5K_CCK_NUM_BITS(_frmlen) * 1000) / _kbps) + \ - AR5K_CCK_SIFS_TIME) - -/* OFDM */ -#define AR5K_OFDM_NUM_BITS (_frmlen) (AR5K_OFDM_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_OFDM_NUM_BITS_PER_SYM (_kbps) ((_kbps * \ - AR5K_OFDM_SYMBOL_TIME) / 1000) - -#define AR5K_OFDM_NUM_BITS (_frmlen) (AR5K_OFDM_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_OFDM_NUM_SYMBOLS (_kbps, _frmlen) \ - DIV_ROUND_UP(AR5K_OFDM_NUM_BITS(_frmlen), \ - AR5K_OFDM_NUM_BITS_PER_SYM(_kbps)) - -#define AR5K_OFDM_TX_TIME (_kbps, _frmlen) \ - (AR5K_OFDM_PREAMBLE_TIME + AR5K_OFDM_SIFS_TIME + \ - (AR5K_OFDM_NUM_SYMBOLS(_kbps, _frmlen) * AR5K_OFDM_SYMBOL_TIME)) - -/* TURBO */ -#define AR5K_TURBO_NUM_BITS (_frmlen) (AR5K_TURBO_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_TURBO_NUM_BITS_PER_SYM (_kbps) (((_kbps << 1) * \ - AR5K_TURBO_SYMBOL_TIME) / 1000) - -#define AR5K_TURBO_NUM_BITS (_frmlen) (AR5K_TURBO_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_TURBO_NUM_SYMBOLS (_kbps, _frmlen) \ - DIV_ROUND_UP(AR5K_TURBO_NUM_BITS(_frmlen), \ - AR5K_TURBO_NUM_BITS_PER_SYM(_kbps)) - -#define AR5K_TURBO_TX_TIME (_kbps, _frmlen) \ - (AR5K_TURBO_PREAMBLE_TIME + AR5K_TURBO_SIFS_TIME + \ - (AR5K_TURBO_NUM_SYMBOLS(_kbps, _frmlen) * AR5K_TURBO_SYMBOL_TIME)) - -/* eXtendent Range (?)*/ -#define AR5K_XR_PREAMBLE_TIME (_kbps) (((_kbps) < 1000) ? 173 : 76) - -#define AR5K_XR_NUM_BITS_PER_SYM (_kbps) ((_kbps * \ - AR5K_XR_SYMBOL_TIME) / 1000) - -#define AR5K_XR_NUM_BITS (_frmlen) (AR5K_XR_PLCP_BITS + (_frmlen << 3)) - -#define AR5K_XR_NUM_SYMBOLS (_kbps, _frmlen) \ - DIV_ROUND_UP(AR5K_XR_NUM_BITS(_frmlen), AR5K_XR_NUM_BITS_PER_SYM(_kbps)) - -#define AR5K_XR_TX_TIME (_kbps, _frmlen) \ - (AR5K_XR_PREAMBLE_TIME(_kbps) + AR5K_XR_SIFS_TIME + \ - (AR5K_XR_NUM_SYMBOLS(_kbps, _frmlen) * AR5K_XR_SYMBOL_TIME)) - -/* * DMA size definitions (2^n+2) */ enum ath5k_dmasize {
drivers/net/wireless/ath5k/hw.c +76 -125
225 lines not on this page · raw message
Signature · 1 line
1.5.2.5
2007/11/1, Luis R. Rodriguez <[email protected]>:
Quoted 122 lines
Since we don't have a HAL anymore there is no point to use opaque pointers in
ath5k_hw_attach(). This will also givehw.caccess toath5k_softcstructure now when needed. While we're at it, lets also give someah_sha reasonable name,ah_sh-->ah_iobase.Changes to
base.c
Changes-licensed-under: 3-clause-BSDChanges to
ath5k.h,hw.c
Changes-licensed-under: ISCSigned-off-by Luis R. Rodriguez <[email protected]>--- drivers/net/wireless/ath5k/ath5k.h | 10 +++++----- drivers/net/wireless/ath5k/base.c | 2 +- drivers/net/wireless/ath5k/hw.c | 11 +++++------ 3 files changed, 11 insertions(+), 12 deletions(-)drivers/net/wireless/ath5k/ath5k.h +5
-5@@ -943,8 +943,8 @@ struct ath5k_capabilities {struct ath5k_hw {u32 ah_magic; -void *ah_sc; -void __iomem *ah_sh; +struct ath5k_softc *ah_sc; +void __iomem *ah_iobase;enum ath5k_int ah_imr;@@ -1042,7 +1042,7 @@ struct ath5k_hw {/* General Functions */ extern int ath5k_hw_register_timeout (struct ath5k_hw *ah,u32 reg,u32 flag,u32 val,bool is_set);/* Attach/Detach Functions */ -extern struct ath5k_hw *ath5k_hw_attach (u16 device,u8 mac_version,void *sc,void __iomem *sh); +extern struct ath5k_hw *ath5k_hw_attach (struct ath5k_softc *sc,u8 mac_version);extern const struct ath5k_rate_table *ath5k_hw_get_rate_table (struct ath5k_hw *ah,unsigned int mode);extern void ath5k_hw_detach (struct ath5k_hw *ah);/* Reset Functions */ @@ -1151,12 +1151,12 @@ extern int ath5k_hw_set_txpower_limit(struct ath5k_hw *ah, unsigned int power);static inline u32 ath5k_hw_reg_read (struct ath5k_hw *ah,u16 reg) { -return ioread32 (ah->ah_sh + reg); +return ioread32 (ah->ah_iobase + reg); }static inline void ath5k_hw_reg_write (struct ath5k_hw *ah,u32 val,u16 reg) { -iowrite32 (val, ah->ah_sh + reg); +iowrite32 (val, ah->ah_iobase + reg); }#endif drivers/net/wireless/ath5k/base.c +1
-1@@ -559,7 +559,7 @@ ath5k_pci_probe(struct pci_dev *pdev, }/* Initialize device */ - sc->ah =ath5k_hw_attach (pdev->device, id->driver_data, sc, sc->iobase); + sc->ah =ath5k_hw_attach (sc, id->driver_data);if (IS_ERR (sc->ah)) { ret =PTR_ERR (sc->ah); goto err_irq;drivers/net/wireless/ath5k/hw.c +5
-7@@ -27,8 +27,8 @@#include <linux/pci.h> #include <linux/delay.h> -#include "ath5k.h" #include "reg.h" +#include "base.h" /*Rate tables*/ static const struct ath5k_rate_table ath5k_rt_11a =AR5K_RATES_11A ;@@ -187,8 +187,7 @@ int ath5k_hw_register_timeout(struct ath5k_hw *ah, u32 reg, u32 flag, u32 val,/* * Check if the device is supported and initialize the needed structs */ -struct ath5k_hw *ath5k_hw_attach (u16 device,u8 mac_version,void *sc, -void __iomem *sh) +struct ath5k_hw *ath5k_hw_attach (struct ath5k_softc *sc,u8 mac_version) {struct ath5k_hw *ah;u8 mac[ETH_ALEN ];@@ -204,7 +203,7 @@ struct ath5k_hw *ath5k_hw_attach(u16 device, u8 mac_version, void *sc, } ah->ah_sc = sc; - ah->ah_sh = sh; + ah->ah_iobase = sc->iobase;/* * HW information @@ -323,7 +322,7 @@ struct ath5k_hw *ath5k_hw_attach(u16 device, u8 mac_version, void *sc, ret =ath5k_hw_get_capabilities (ah);if (ret) {AR5K_PRINTF ("unable to get device capabilities: 0x%04x\n" , - device); + sc->pdev->device); goto err_free; }@@ -331,7 +330,7 @@ struct ath5k_hw *ath5k_hw_attach(u16 device, u8 mac_version, void *sc, ret =ath5k_eeprom_read_mac (ah, mac);if (ret) {AR5K_PRINTF ("unable to read address from EEPROM: 0x%04x\n" , - device); + sc->pdev->device); goto err_free; } --
Quoted 2 lines
1.5.2.5
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick
drivers/net/wireless/ath5k/ath5k.h struct ath5k_capabilities { · line 949
Quoted 9 lines
struct
ath5k_hw{drivers/net/wireless/ath5k/ath5k.h +2
-2u32 ah_magic; -void *ah_sc; -void __iomem *ah_sh; +struct ath5k_softc *ah_sc; +void __iomem *ah_iobase;enum ath5k_int ah_imr;
Why do you need separate ath5k_hw and ath5k_softc structures anyway?
Quoted 11 lines · Christoph Hellwig
drivers/net/wireless/ath5k/ath5k.h struct ath5k_capabilities { · line 949
Quoted 9 lines
struct ath5k_hw { u32 ah_magic;drivers/net/wireless/ath5k/ath5k.h +2
-2-void *ah_sc; -void __iomem *ah_sh; +struct ath5k_softc *ah_sc; +void __iomem *ah_iobase;enum ath5k_int ah_imr;Why do you need separate
ath5k_hwandath5k_softcstructures anyway?
CC'ing Michael Taylor.
I hope we don't need both. This will take a bit to remove though. Because of the old HAL, things that were MadWIfi driver related could be written to ath5k_softc and the HAL itself was in charge of only using ath5k_hw (their respective counterparts in MadWifi).
The only thing that might be useful here is perhaps for locking access to HW parts, so it is nice to have those parts separate. Recently there was some effort put into MadWifi by Michael Taylor to ensure A LOT of HAL access routines were spinlocked before being run. You can see this in if_ath_hal.h. Essentially a macro which does the spin_lock_irqsave() was being run before many HAL access routines... whether we need such extensive locking merits some review. Perhaps this is where some of our current problems lies in.
Luis