Go back –> ath5k kerneldoc

enum ath5k_tx_queue

enum ath5k_tx_queue {
AR5K_TX_QUEUE_INACTIVE,
AR5K_TX_QUEUE_DATA,
AR5K_TX_QUEUE_XR_DATA,
AR5K_TX_QUEUE_BEACON,
AR5K_TX_QUEUE_CAB,
AR5K_TX_QUEUE_UAPSD
};

Constants

AR5K_TX_QUEUE_INACTIVE
q is unused -- see ath5k_hw_release_tx_queue
AR5K_TX_QUEUE_DATA
A normal data queue
AR5K_TX_QUEUE_XR_DATA
An XR-data queue
AR5K_TX_QUEUE_BEACON
The beacon queue
AR5K_TX_QUEUE_CAB
The after-beacon queue
AR5K_TX_QUEUE_UAPSD
Unscheduled Automatic Power Save Delivery queue

struct ath5k_beacon_state - Per-station beacon timer state.

struct ath5k_beacon_state {
    u32 bs_interval;
    u16 bs_cfp_max_duration;
};

Members

bs_interval
in TU's, can also include the above flags
bs_cfp_max_duration
if non-zero hw is setup to coexist with a Point Coordination Function capable AP

struct ath5k_rate - rate structure

struct ath5k_rate {
    u8 valid;
    u32 modulation;
    u16 rate_kbps;
    u8 rate_code;
    u8 dot11_rate;
    u8 control_rate;
};

Members

valid
is this a valid rate for rate control (remove)
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.

Description

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 ? ? ? ? ?

enum ath5k_int

enum ath5k_int {
AR5K_INT_RX,
AR5K_INT_RXDESC,
AR5K_INT_RXNOFRM,
AR5K_INT_RXEOL,
AR5K_INT_RXORN,
AR5K_INT_TX,
AR5K_INT_TXDESC,
AR5K_INT_TXURN,
AR5K_INT_MIB,
AR5K_INT_RXPHY,
AR5K_INT_RXKCM,
AR5K_INT_SWBA,
AR5K_INT_BMISS,
AR5K_INT_BNR,
AR5K_INT_GPIO,
AR5K_INT_FATAL,
AR5K_INT_GLOBAL,
AR5K_INT_COMMON,
AR5K_INT_NOCARD
};

Constants

AR5K_INT_RX
mask to identify received frame interrupts, of type AR5K_ISR_RXOK or AR5K_ISR_RXERR
AR5K_INT_RXDESC
Request RX descriptor/Read RX descriptor (?)
AR5K_INT_RXNOFRM
No frame received (?)
AR5K_INT_RXEOL
received End Of List for VEOL (Virtual End Of List). The Queue Control Unit (QCU) signals an EOL interrupt only if a descriptor's LinkPtr is NULL. For more details, refer to:
AR5K_INT_RXORN
Indicates we got RX overrun (eg. no more descriptors). Note that Rx overrun is not always fatal, on some chips we can continue operation without reseting the card, that's why int_fatal is not common for all chips.
AR5K_INT_TX
mask to identify received frame interrupts, of type AR5K_ISR_TXOK or AR5K_ISR_TXERR
AR5K_INT_TXDESC
Request TX descriptor/Read TX status descriptor (?)
AR5K_INT_TXURN
received when we should increase the TX trigger threshold We currently do increments on interrupt by (AR5K_TUNE_MAX_TX_FIFO_THRES - current_trigger_level) / 2
AR5K_INT_MIB
Indicates the Management Information Base counters should be checked. We should do this with ath5k_hw_update_mib_counters but it seems we should also then do some noise immunity work.
AR5K_INT_RXPHY
RX PHY Error
AR5K_INT_RXKCM
??
AR5K_INT_SWBA
SoftWare Beacon Alert - indicates its time to send a beacon that must be handled in software. The alternative is if you have VEOL support, in that case you let the hardware deal with things.
AR5K_INT_BMISS
If in STA mode this indicates we have stopped seeing beacons from the AP have associated with, we should probably try to reassociate. When in IBSS mode this might mean we have not received any beacons from any local stations. Note that every station in an IBSS schedules to send beacons at the Target Beacon Transmission Time (TBTT) with a random backoff.
AR5K_INT_BNR
Beacon Not Ready interrupt - ??
AR5K_INT_GPIO
GPIO interrupt is used for RF Kill, disabled for now until properly handled
AR5K_INT_FATAL
Fatal errors were encountered, typically caused by DMA errors. These types of errors we can enable seem to be of type AR5K_SIMR2_MCABT, AR5K_SIMR2_SSERR and AR5K_SIMR2_DPERR.
AR5K_INT_GLOBAL
Seems to be used to clear and set the IER
AR5K_INT_COMMON
common interrupts shared amogst MACs with the same bit value
AR5K_INT_NOCARD
signals the card has been removed

http

//www.freepatentsonline.com/20030225739.html

Description

These are mapped to take advantage of some common bits between the MACs, to be able to set intr properties easier. Some of them are not used yet inside hw.c. Most map to the respective hw interrupt value as they are common amogst different MACs.