[rt2x00-users] [RFC] rt2800usb: use hrtimer to emulate TBTT and pre-TBTT irqs for AP mode
Ivo Van Doorn
ivdoorn at gmail.com
Thu Feb 3 06:12:30 EST 2011
> the patch below is unfinshed and untested, but I'm throwing
> it out anyway, hoping to get opinions if I'm on the right track.
> Basically in AP mode the TBTT_TIMER register is read
> (which is a count-down timer, i.e. TBTT_TIMER is 0 at TBTT),
> and then a Linux timer is set to emulate the TBTT and PRE_TBTT irqs.
> It then uses tasklets like rt2800pci does to handle these events.
> The patch is on top of rt2x00/experimental since it uses
> rt2x00usb_register_read_async() to read the TBTT_TIMER register
> from atomic context (timer callback).
> I used a hrtimer since I assumed the rounding applied to jiffies
> based timers would not allow to emulate the TBTT irq with good timing.
> (The Linux timer code does a lot of rounding to reduce the number
> of timer irqs, i.e. as many timers as possible with a single timer irq.)
> Real code probably should not use hrtimer_start() but better
> hrtimer_start_range_ns() for this reason, but in this patch
> I wanted to see how well the timing is on my 330MHz ARM board.
> The debug print I left in the patch prints:
> [ 40.630492] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10, Aifs: 7, TXop: 0.
> [ 40.866840] TBTT: 2048 94448
> [ 40.961606] TBTT: 9664 9664
> [ 40.971509] TBTT: 102144 92144
> [ 41.063904] TBTT: 9792 9792
> [ 41.073993] TBTT: 102080 92080
> [ 41.166371] TBTT: 9728 9728
> [ 41.176361] TBTT: 102144 92144
> [ 41.268759] TBTT: 9728 9728
> [ 41.278772] TBTT: 102144 92144
> [ 41.371172] TBTT: 9728 9728
> [ 41.381150] TBTT: 102144 92144
> [ 41.473542] TBTT: 9792 9792
> [ 41.483574] TBTT: 102144 92144
> [ 41.575977] TBTT: 9728 9728
> I.e. ~300usec latency. I think it takes best case 125usec
> to read the TBTT_TIMER register via USB. The timing seems
> to be stable under CPU load but I haven't tested much yet.
> With this change rt2800usb should be on par with rt2800pci
> wrt to beacon generation and handling of bc/mc packets.
> However, It still does not guarantee that bc/mc frames are sent
> first right after the beacon is sent. This would need hardware/firmware
> support, e.g. a seperate DMA queue which can be started/stopped manually.
> The existence of the TXINFO_W0_QSEL flags is a hint that multiple
> queues exist.
> How does it work in practice on rt2800pci? Can power saving stations
> reliably receive bc/mc trafiic from rt2800pci AP?
> The question is, how long do stations stay awake after the DTIM
> beacon? If they go back to sleep immediately after seening the
> first non-bc/mc frame then it would seem the TX timing is very critical.
> Signed-off-by: Johannes Stezenbach <js at sig21.net>
Applied to the experimental tree.
I will do some new testing on the experimental tree this weekend,
to see if some patches can be merge into the master tree. :)
More information about the users