On Monday 14 June 2010 22:50:24 David H. Lynch Jr. wrote: > Many routines are coded to look like interrupt handlers, but the > code seems to be entirely polled ? Hardware design decision. (See "AR9170 STA Programming Guide" - Paragraph 3-3.) > Am I correct there ? If so do you know if the AR9170-fw code or > something else might show an example of interrupt handling for the > AR9170. I must have tx complete interrupts. Well you have to "poll" the MAC's WLAN Status Registers (0x1c3510?) for BIT(0)=TX COMP (and BIT(2) = TX FAIL) changes... Or, if you are only sending one frame at a time, you might be able to poll 0x1c36d4 instead. Also you could decrease the maximum pending tx "interrupt" timeout in 0x1c3d7c etc... But if that does not satisfy your need for "real-time responsiveness", you should contact Stephen Chen @ Atheros directly, maybe he knows a undocumented feature register which enables real-time interrupt processing. > Next there are remarks throught the driver and firmware regarding > cookies. > I think a cookie is a u8 that uniquely identifies a packet - is > that correct ? > > In the firmware there is a remark somewhere that suguests that the > cookie AND something else are needed - is that correct or is the cookie > sufficient ? This is because of historic reasons. In ar9170usb the driver had use dirty tricks to get the AC_ID into the firmware's tx report. So it could do some primitive frame lookup. carl9170 driver still needs the AC_ID (but now) to reduce the frame lookup cost. This is somewhat necessary because tx feedback is usually processed in a critical section and when aggregation is enabled, it can be up to 16 frames at any time... regards, Chr -- 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
