Hi Alexander, thanks for valuable informations!
On Thu, 22 Jun 2006 23:08:10 +0400, Alexander Tsvyashchenko wrote: > As for the PS, the main problem currently seems to be the lack of hardware > specifications: quite some things that are needed to make it work are > unknown. I tried to look at bcm43xx specs but didn't find how TIM (or TIM bitmap) is updated by the stack. > The information/speculations I have so far > (please note my understanding of 802.11 specs is very limited!!!): > > 1) TIM seems to be generated by software (I think it was confirmed by smb > from specs group). You mean Bitmap Control and Partial Virtual Bitmap fields of TIM, right? > 2) DTIM counter in beacons sent is updated by hardware (confirmed by > specs group). > > 3) There is PS interrupt that in my experiments seemed to correlate with > the beacon interval > (one PS interrupt for one beacon sent?) This seems to be important. Is this generated after every beacon or after DTIM only? > My original idea was that it could be used to update beacon template, but > specs group seemed > to be sceptical about this idea saying that in original driver the beacon > template was not updated > in PS interrupt handler. Especially if this is called after the beacon is set (or while is being transmitted), there is no sense in updating beacon template in that interrupt handler. > Now I think that it's, probably, not necessary to update beacon template > exactly before/after current > beacon is sent, as the reason to update beacon is only change in TIM, and > we can just update > template as soon as TIM is changed (so, some sort of callback from dscape > to the driver is needed). You mean to update TIM each time a packet for PS-enabled STA arrives? It doesn't look like a good idea to me. Maybe some caching can be performed (e.g. update only for the first frame to each PS-enabled STA in a given DTIM period) but it's probably still too bad performance - imagine a situation with a lot of PS-enabled STAs. > However, this PS interrupt could be used for sending broadcast packets > (which, as far as I understood > from 802.11 specs, should be sent after DTIM beacon). To use it for this > purpose, we need the following information: > > a) Confirmation that PS interrupt is invoked exactly after current > beacon is sent. > b) The way to know whether current beacon was DTIM or not. This is a problem only if that interrupt is generated after each beacon. In such case, the stack is able to tell you this (though we need to be sure it is in sync with the hardware) - look at the comment before ieee80211_get_buffered_bc function in d80211.h. It's not useful for bcm43xx in the current form but it can be easily extended (some ieee80211_report_sent_beacon function). > [...] > All other PS things seem to be relatively OK - there's also some support > in hardware for processing entering/exiting > PS mode for STAs, but these packets seem to be passed to dscape layer > also, and as they are already processed > in dscape, it looks like there's no need to bother with using hardware > for that. Are you sure that hardware functionality is not used for generating TIM bitmap? Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
