[firmware] powersave mode non-functional.

[dwmw2]

Perhaps this is just because the access points in 1cc and my WRT54g at home don't support it, but enabling powersave mode (iwconfig eth1 power on) just seems to give an endless loop of:

[ 2633.189408] libertas host: CMD_RESP: response 0x8021, size 18, jiffies 2333060
[ 2633.196750] libertas host: CMD_RESP: PS_MODE cmd reply result 0x2, action 0x30
[ 2633.204080] libertas host: CMD_RESP: PS command failed with 0x2
[ 2633.210184] libertas host: EXEC_NEXT_CMD: cmdpendingq empty, go back to PS_SLEEP
[ 2633.221601] libertas cmd: PS command:SubCode- Enter PS
[ 2633.226881] libertas host: QUEUE_CMD: inserted command 0x0021 into cmdpendingq

What is result code 0x2? If it's really that the AP isn't letting us go into low-power mode, then I can fix the driver to give up, or at least keep attempting it in a much slower loop.

I could also do with finding a setup where I can really test powersave mode.

[dwmw2]

I'm still unable to get powersave mode to work. Even with the new (5.110.21.p21) firmware, and with the mesh stopped, I always get the above response.

[ashish]

Command response 0x2, indicates that firmware does not support this command. I think it was designed in this way may be becuase of lack MAC TSF synchronization, which is currently not there in mesh.

Driver should not retry any command that returns 0x2 as a command response result.

[dwmw2]

The firmware seems to do that even when mesh is disabled. The last firmware in which it accepted the command seems to have been 5.110.12.p0. Even there it's confusing me -- the return from the 'Enter PS' command seems to have the 'action' field set to 0x8021, which it shouldn't be. The code in cmdresp.c checks it against the values we put in the field when we send the command, which are:

#define CMD_SUBCMD_ENTER_PS		0x0030
#define CMD_SUBCMD_EXIT_PS		0x0031
#define CMD_SUBCMD_SLEEP_CONFIRMED	0x0034
#define CMD_SUBCMD_FULL_POWERDOWN	0x0035
#define CMD_SUBCMD_FULL_POWERUP		0x0036

This is the output:

libertas host: CMD_RESP: response 0x8021, seq 18, size 18, jiffies 43484103
libertas host: CMD_RESP: PS_MODE cmd reply result 0x0, action 0x8021
libertas host: CMD_RESP: PS action 0x8021

When I change the code in cmdresp.c to 'know' what we sent in the action field of the last PS_MODE command instead of reading it from the response, I find that the firmware never talks to us again after we send it the CONFIRM_SLEEP...

[root@efika ~]# iwconfig eth1 power on                                                                                    
[44304.781077] libertas host: PREP_CMD: command 0x0021                                                                    
[44304.786140] libertas cmd: PS command:SubCode- Enter PS
[44304.791429] libertas host: QUEUE_CMD: inserted command 0x0021 into cmdpendingq                                         
[44304.799143] libertas host: PREP_CMD: wait for response                                                                 
[44304.804519] libertas host: EXEC_NEXT_CMD: sending command 0x0021                                                       
[44304.810713] libertas host: DNLD_CMD: command 0x0021, seq 18, size 18, jiffies 44004682                                 
[44304.818862] libertas cmd: DNLD_CMD: sent command 0x0021, jiffies 44004690                                              
[44304.827542] libertas host: CMD_RESP: response 0x8021, seq 18, size 18, jiffies 44004699                                
[44304.835713] libertas host: CMD_RESP: PS_MODE cmd reply result 0x0, action 0x8021                                       
[44304.843250] libertas host: CMD_RESP: ENTER_PS command response                                                         
[44304.849605] libertas cmd: event cause 10                                                                               
[44304.853767] libertas cmd: EVENT: awake                                                                                 
[44304.857806] libertas cmd: event cause 11                                                                               
[44304.861861] libertas cmd: EVENT: sleep                                                                                 
[44304.865718] libertas host: sending lbs_ps_confirm_sleep                                                                
[44304.871076] libertas host: SEND_SLEEPC_CMD: before download, cmd size 18                                               
[44304.877969] libertas host: SEND_SLEEPC_CMD: sent confirm sleep                                                         
[root@efika ~]#                                                                                                           
[root@efika ~]#                                                                                                           
[root@efika ~]# iwconfig eth1                                                                                             
[44330.010775] libertas host: PREP_CMD: command 0x001f                                                                    
[44330.015834] libertas host: QUEUE_CMD: inserted command 0x001f into cmdpendingq                                         
[44330.023287] libertas host: PREP_CMD: command 0x000b                                                                    
[44330.028326] libertas host: QUEUE_CMD: inserted command 0x000b into cmdpendingq                                         
[44330.039420] libertas host: PREP_CMD: command 0x001e                                                                    
[44330.044501] libertas cmd: RF_TX_POWER_CMD: size:12 cmd:0x1e Act:0                                                      
[44330.050752] libertas host: QUEUE_CMD: inserted command 0x001e into cmdpendingq                                         
[44330.058150] libertas host: PREP_CMD: wait for response

Shouldn't it be waking periodically? When was the last time the driver was known to work with powersave mode?

[dwmw2]

OK, the 'action' thing turns out to be a bug introduced recently, which I've now fixed.

I've found a firmware (5.110.7) which seems to work with PS mode. It sends the 'HOST_AWAKE' event and expects the WAKEUP_CONFIRM command to be sent in response. After implementing that, it seems to work -- and I can get on with cleaning up that part of the driver.

Later versions of the firmware seem to ignore the FW_WAKE_METHOD set command, and stubbornly remain configured to wake via GPIO even when asked nicely to change. And the most recent versions don't support powersave at all.

[dwmw2]

The firmware manual seems to suggest that the host should ignore the SLEEP event if it doesn't want to go to sleep -- and I've made the driver do just that if there are commands or data still to be sent.

However, this causes a delay on incoming traffic. Obviously the device cannot know that we have ignored its SLEEP event, and seems to wait for a couple of seconds before sending us anything else.

Is there a command we can send to actively NAK the SLEEP event? As a quick hack I tried resending the CONFIRM_WAKE command (not because I thought that was a sensible thing to do, but just because I happened to be able to test that with a one-line change). I thought it might hint to the device that the driver _isn't_ going into sleep mode. It doesn't...

[18795.582111] libertas cmd: EVENT: sleep
[18795.586006] libertas cmd: EVENT: something to send; ignoring PS_SLEEP
[18795.592599] libertas host: SEND_WAKEC_CMD: before download
[18795.598228] usb8xxx usbd: 1-2:*** type = 1
[18795.602446] usb8xxx usbd: 1-2:size after = 8
[18795.606879] libertas host: SEND_WAKEC_CMD: sent confirm wake
[18795.612790] usb8xxx usbd (INT): 1-2:Recv length = 0xc, Recv type = 0xF00DFACE
[18795.620191] libertas thread (INT): lbs_interrupt: intcounter=0
[18795.626197] usb8xxx usbd (INT): 1-2:Wake up main thread to handle cmd response
[18795.633932] usb8xxx usbd: 1-2:*** type = 0
[18795.638097] usb8xxx usbd: 1-2:size after = 142
[18795.642737] libertas thread: main-thread 111: intcounter=1 currenttxskb=00000000 dnld_sent=1
[18795.651425] libertas thread: main-thread 222 (waking up): intcounter=1 currenttxskb=00000000 dnld_sent=0
[18795.661152] libertas thread: main-thread 333: intcounter=1 currenttxskb=00000000 dnld_sent=0
[18795.669782] usb8xxx usbd: 1-2:Int cause is 0x8
[18795.674305] libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=0
[18795.682865] libertas thread: main-thread: cmd response ready
[18795.691121] libertas host: CMD_RESP: cur_cmd is NULL
[18795.696270] libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=0
[18795.704938] libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=1 PS_State=1
[18797.650823] usb8xxx usbd (INT): 1-2:Recv length = 0x8, Recv type = 0xBEEFFACE
[18797.658123] usb8xxx usbd (INT): 1-2:**EVENT** 0xA

A ping is running, pinging this device from outside once as second. When the above happens, it (unsurprisingly) sees a couple of packets with high latency (>2s then >1s then back to normal).

[rchokshi]

On-chip power saving modes have not been implemented / turned ON in the firmware. They have not been tested also. Reasons: (1) power save mode when mesh is turned ON is very tricky and we are working on the design/implementation right now. (2) power save mode in infrastructure mode (connected to an AP) is implemented but not turned ON. This has quite a lot of repurcussions on the firmware state machine transitions. Moreover, this is a USB device and hence how this would interoperate with the USB suspend/resume becomes the big question.

Power management on the host side (i.e. through USB suspend/resume) was the target before deployment of XOs.

That said, we are still working on the on-chip power management feature. But this will not be in place for at least another month or so. We will have a full-blown power management scheme for the device by that time.

So, I would suggest to halt your efforts on enabling power save mode for now.

[dwmw2]

I've found a version of the firmware in which PS mode works, allowing me to properly test that part of the driver. It would still be useful to make PS work in our current firmware though, when mesh is disabled.