It looks like your patch never actually made it to the list - perhaps
test that before you add me to Cc :)
> If we receive suspend after TX path has executed
> dynamic ps disable work, the driver will be in
> ACTIVE state during suspend and even after it
> resumes.
>
> As before suspend all data packets are flushed
> it is safe to put the driver in to sleep for
> optimal power during suspend or up on resume.
I'm not sure I get it - we always transmit a frame after resume.
johannes
On Wed, May 20, 2015 at 7:11 PM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2015-05-19 at 13:53 +0530, Krishna Chaitanya wrote:
>
>> > I'm not sure I get it - we always transmit a frame after resume.
>> Let me explain the sequence of events:
>>
>> tx_frame:
>> dynamic_ps_disable_work.
>> get the chip out of power save.
>> suspend came:
>> dynamic ps timer is cancelled.
>> tx queues are flushed.
>> chip stays out of power save unless there is one more
>> tx frame which kicks the dynamic ps timer again.
>
> So initially, for suspend, this shouldn't matter.
Some chipsets are using power_save state from mac80211
to stay in DOZE mode, so in that case we end up
drawing more power. We can force the chipset fw to enter
DOZE independent of the mac80211 power save state but
when resuming the chip FW should again configure as per
mac80211 power save state.
> And after suspend we always transmit a frame. What gives?
Yes, but we have seen that in idle case this delay is more like
30secs-1min depending on the keepalive packet.
Till that time the chip is active and drawing more power.
On Tue, May 19, 2015 at 1:01 PM, Johannes Berg
<[email protected]> wrote:
> It looks like your patch never actually made it to the list - perhaps
> test that before you add me to Cc :)
Sure, i realized that after a few trails and then removed you from CC :-).
>> If we receive suspend after TX path has executed
>> dynamic ps disable work, the driver will be in
>> ACTIVE state during suspend and even after it
>> resumes.
>>
>> As before suspend all data packets are flushed
>> it is safe to put the driver in to sleep for
>> optimal power during suspend or up on resume.
>
> I'm not sure I get it - we always transmit a frame after resume.
Let me explain the sequence of events:
tx_frame:
dynamic_ps_disable_work.
get the chip out of power save.
suspend came:
dynamic ps timer is cancelled.
tx queues are flushed.
chip stays out of power save unless there is one more
tx frame which kicks the dynamic ps timer again.
--
Thanks,
Regards,
Chaitanya T K.
On Tue, 2015-05-19 at 13:53 +0530, Krishna Chaitanya wrote:
> > I'm not sure I get it - we always transmit a frame after resume.
> Let me explain the sequence of events:
>
> tx_frame:
> dynamic_ps_disable_work.
> get the chip out of power save.
> suspend came:
> dynamic ps timer is cancelled.
> tx queues are flushed.
> chip stays out of power save unless there is one more
> tx frame which kicks the dynamic ps timer again.
So initially, for suspend, this shouldn't matter.
And after suspend we always transmit a frame. What gives?
johannes