[rt2x00-users] [RFC] rt2800usb: use hrtimer to emulate TBTT and pre-TBTT irqs for AP mode

[Ivo Van Doorn]

Hi,

> 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. :)

Thanks,

Ivo