[rt2x00-users] rt2800: missing parts for 11n support
helmut.schaa at googlemail.com
Fri May 7 21:57:30 AEST 2010
Am Freitag 07 Mai 2010 schrieb Ivo Van Doorn:
> On Fri, May 7, 2010 at 1:51 PM, Helmut Schaa
> <helmut.schaa at googlemail.com> wrote:
> > Hi,
> > Am Freitag 07 Mai 2010 schrieb Ivo Van Doorn:
> >> > using 11n MCS rates works already fine with the rt2800 devices when hardcoded
> >> > in the tx descriptor ;) as far as I could see also reception of MCS rates works
> >> > fine as long as HT20 is used.
> >> Even for receiving?
> > I'm pretty sure I saw this, yes. I guess there is something wrong in the
> > way we set up the receiver for HT40.
> >> > Did I miss anything here or is it really only this one bit missing to get
> >> > 11n support?
> >> Aggregation support is missing, both on the receiving as sending side.
> >> That is one of the most important things which must be implemented for
> >> full 11n support. I believe the receiving side must be implemented to fix
> >> some loss of RX frames. The hardware seems to receive multiple frames
> >> in one block, as-if it was aggregated for some regular frames as well. This
> >> was at least reported some months ago by somebody.
> > Hmm, AFAIK mac80211 handles all of the MAC layer stuff like negotiating ba
> > sessions and will tell us about the results via ampdu_action. So, I'm not
> > sure if we have to implement a lot or if we only have to set a few registers
> > up for aggregation. Hopefully the second approach is enough ;)
> Negotiating stuff is indeed for mac80211. But we assume only one frame is
> placed in the RX entry. Which is not the case. There can be multiple, each
> with its own RX descriptor. So we have to parse that correctly.
Oh, are you sure? I thought/hoped that aggregated frames have only one rx
descriptor. But I did not dig into this further yet.
> AFAIK for sending we have the same issue, we need to give each frame
> in the aggregated
> frame its own TX descriptor.
I had the same hope here ;)
More information about the users