True, we could create new wakeup sources specifically to
track this information, perhaps as needed once an IRQ is first
observed to trigger a wakeup.
We would want to know which wakeup sources were responsible for the
most recent wakeup, since we keep a timeline of suspend/resume events
with wakeu
On Thursday, March 13, 2014 05:43:20 PM Ruchi Kandoi wrote:
> This should be true most of the times.
>
> But there might be cases otherwise too.
>
> For instance, there was a bug earlier with wi-fi which would cause the
> system to wake up but not get hold of a wakeup source because there
> wasn'
This should be true most of the times.
But there might be cases otherwise too.
For instance, there was a bug earlier with wi-fi which would cause the
system to wake up but not get hold of a wakeup source because there
wasn't any work for it to do. In that case, the wakeup sources would
not log su
Hi,
I saw the v4, but I don't have it handy, so replying here.
On Wednesday, March 12, 2014 12:46:38 PM Ruchi Kandoi wrote:
> For power management diagnostic purposes, it is often useful to know
> what interrupts are frequently waking the system from low power
> suspend mode, especially on batter
On Wed, 2014-03-12 at 12:46 -0700, Ruchi Kandoi wrote:
> For power management diagnostic purposes, it is often useful to know
> what interrupts are frequently waking the system from low power
> suspend mode, especially on battery-powered consumer electronics
> devices that are expected to spend muc
For power management diagnostic purposes, it is often useful to know
what interrupts are frequently waking the system from low power
suspend mode, especially on battery-powered consumer electronics
devices that are expected to spend much of their time in low-power
suspend while not in active use.
6 matches
Mail list logo
