On Tue, Nov 11, 2008 at 10:17:54PM -0800, Vivek Natarajan wrote: > Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > Vivek Natarajan wrote: > >> 2) Do you intend to leave the NULL frame formation, waking up the chip > >> for TIM and modifying sleep/awake time according to DTIM to > >> the driver since I did not see this in your TODO list?( I understand from > >> the iwlwifi code that it just sends a request to the firmware for sending > >> NULL frame and the firmware takes care of the rest. But it may not be > >> so in the case of other vendor drivers.) > > > > Can you elaborate on this? I don't think we're concerned with that in > > dynPS. > > I'm listing whatever I have understood about 'Power save'. > It might be too basic but do correct me if I'm wrong somewhere. > > NULL DATA frame: > a) A NULL data frame with PM bit ON is to be sent to the AP before > going to sleep. > b) After sending Null frame, the chip should not go to sleep before > getting ack: move to sleep pending state > c) In sleep pending state, wait for one more 'timeout' period before > sending null frame again > d) If ack is received, goto sleep. > This is to make sure that the AP buffers frames for us. > Sanity check: > Check if the hw has been sleeping too long! It could imply that the > sleep timers have gotten out of sync with the TSF. If so, force wake > until the sleep timers get resynced. > > Tx: > If there is a frame to transmit, send null data with PM bit off and start Tx. > Rx: > If there is any buffered frames, it is indicated in TIM. > TIPS on TIM: > Some hardware processes the TIM IE and fires an interrupt when the TIM > bit is set. > For hardware that doesn't, we should process the TIM in software as > part of processing the received Beacon > → A function to check if TIM bit is set based on the offset in the beacon. > → A function to put the chip to awake(if TIM is set) and send a null > data with PM bit off. > > DTIM: > The period after which multicast traffic may be transmitted. So be > awake even if there is no unicast packets > as indicated by TIM. > There are some registers related to TIM and DTIM periods in ath5k > registers.(Thanks Nick for pointing > them out)Need to dig more to see if it is enough to program these > registers to be awake for post-DTIM muticast traffic. Also check out: http://wireless.kernel.org/en/developers/Documentation/ieee80211/power-savings Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
