On 10/11/07, Nick Kossifidis <mickflemm@xxxxxxxxx> wrote: > I should have added something inside ath5kreg.h, sry for that... > > (?) = not sure > > > + * @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: > > + * http://www.freepatentsonline.com/20030225739.html > > > + * @AR5K_INT_RXORN: indicates a hardware reset is required > 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 used for RF Kill, we should handle this inside > interrupt handler, until then i've disabled it because it results an > interrupt storm in case RF Kill switch is off. > > > + * @AR5K_INT_NOCARD: signals the card has been removed > There is no such interrupt, it's software stuff used in hal. We can > always check for pending interrupts by reading that register (check > out is_intr_pending) and get rid of this. Since I'm resending, I've added these new comments. However I'm leaving @AR5K_INT_NOCARD for now as it does seem to be read in hw: if (hal->ah_version == AR5K_AR5210) { data = ath5k_hw_reg_read(hal, AR5K_ISR); if (unlikely(data == AR5K_INT_NOCARD)) { *interrupt_mask = data; return -ENODEV; } } else { /* * Read interrupt status from the Read-And-Clear shadow register * Note: PISR/SISR Not available on 5210 */ data = ath5k_hw_reg_read(hal, AR5K_RAC_PISR); } /* * Get abstract interrupt mask (HAL-compatible) */ *interrupt_mask = (data & AR5K_INT_COMMON) & hal->ah_imr; if (unlikely(data == AR5K_INT_NOCARD)) return -ENODEV; - 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
