CARL9170

CARL9170

[David H. Lynch Jr.]

     I am trying to digest some things in the carl9170 firmware.

     Many routines are coded to look like interrupt handlers, but the 
code seems to be entirely polled ?
     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.

     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 ?

     Thank you.

Re: CARL9170

[Christian Lamparter]

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

Re: CARL9170

[Ignacy Gawedzki]

Hi David,

I happen to be trying to achieve something very similar to what you are aiming
at.  I need to measure each TX frame's "service time", i.e. the interval of
time between the instant this frame is considered for transmission and the
instant the corresponding ACK is received or the transmission is given up (too
many failed transmission attempts).  Then I need this value to be returned to
the kernel with the TX status, for further processing.

Until now, I oversimplistically was doing that measurement upstream, in the
kernel driver, taking a timestamp between the instant a frame is shipped
through the USB framework and the instant the TX completion interrupt is
received.  This approach worked well only when sending sustained traffic
(back-to-back frames), since the TX completion time of the previous frame was
then used as the starting instant of the current frame.  When frames were sent
one-by-one, the measured interval was way too large (as a matter of fact, it
was a lot smaller, while still too large, when I used the ar9170
firmware+driver), so as to become unusable.  Since I discovered the carl9170
firmware+driver, I'm seriously thinking about implementing that measurement
inside the firmware for much higher accuracy.

I read with great interest the threads you started and wanted to ask whether
you managed to advance in your quest.  In the meantime, I continue to read
carl9170 firmware code thoroughly to get a feeling of how things are going on
in it.

Ignacy

-- 
Information wants to be beer, or something like that.