TX A-mpdu (without the 'A')

Bob Copeland me at bobcopeland.com
Fri Feb 28 00:44:43 EST 2014


On Thu, Feb 27, 2014 at 05:01:40PM +0000, Eugene Krasnikov wrote:
> When i was investigating this problem i had 3 theories what can be wrong:
> 1) First one that wcn36xx_dxe_tx_frame is sending packets after
> packets instead of queuing them into the ring and then tell the
> hardware to send all the packets in the ring.

Well, this was easy enough for me to test since I've restructured
the code a little.  I pass in a 'has_more' flag to wcn36xx_dxe_tx_frame
indicating whether or not there are more frames queued, and I only
do the ctrl reg write (or SMSM state change) at the end if there
are no more frames, or if the ring has filled.

    if (!has_more) {
        printk(KERN_DEBUG "no more frames, kicking dxe");
        wcn36xx_dxe_write_register(wcn,
                                   ch->reg_ctrl, ch->def_ctrl);
    }

Is that what you had in mind?  printk shows, e.g.:

<7>[   70.635617] in tx work, queue len=2
<7>[   70.635678] no more frames, kicking dxe
<7>[   70.685609] in tx work, queue len=16

[ here it would've added all 16 to the ring, but I don't
  print anything for that to cut down on log spam ]

<7>[   70.685853] no more frames, kicking dxe
<7>[   70.695620] in tx work, queue len=4
<7>[   70.695711] no more frames, kicking dxe

Ok, maybe DMA engine is still traversing the ring and the ctrl write
doesn't matter... so I suppose I could also try adding all the frames
and not setting valid bit on any until they are all there.  But I
think prima is doing things more or less the same way as wcn36xx here.

> 2) Second theory was that we miss some flag in wcn36xx_tx_bd that will
> tell hardware that this is A-MPDU

The only difference in the tx bd I can see is bd_ssn (part of
pdu.reserved3) which is set to 2 in prima.  That means the device
generates QoS sequence numbers instead of host.  So I turned that on,
but makes no difference.

> 3) And finally last one is that wcn36xx does not configure HW in a
> proper way when calling config_bss/config_sta/update_cfg/add_ba and so
> on.

There are a few differences in config_bss / config_sta, etc.  I'm
working through them but nothing substantive found so far.

> First two theories are kind of difficult to debug because they
> on the data path but i am sure you can find the fix for this issue!

Hope so :)

-- 
Bob Copeland %% www.bobcopeland.com



More information about the wcn36xx mailing list