*Ping!*
Happy New Year everyone. Is there any update on this? I think Francesco already
pointed out how to solve the last remaining issue with this, so I hope we can
now resubmit these patches and finally get them merged. Daniel?
___
linaro-dev mailing
Thanks again for making this happen, Daniel. I like this version,
except for the small nitpick that I still think it would make sense to
also turn the loop in menu.c around. How about something like this:
for (i = drv->state_count - 1; i >= CPUIDLE_DRIVER_STATE_START; i++) {
Hi,
What is the current status of this? Daniel, do you think you have got
enough feedback to submit a definitive patch for this? Rafael, would
you approve of such a change?
The bug with dynamically added C-states that is tied to this still
hurts the battery life for some users across all distros
d
not appear anymore.
Signed-off-by: Julius Werner
---
arch/powerpc/platforms/pseries/processor_idle.c |4 +-
drivers/acpi/processor_idle.c | 57 +-
drivers/cpuidle/cpuidle.c |3 +-
drivers/idle/intel_i
> Maybe you can remove all these computations and set the flag
> en_core_tk_irqen for the driver ? That will be handled by the cpuidle
> framework, no ?
>
> Same comment for the intel_idle driver.
Yeah, I thought about that, too. I was a little too afraid of touching
the sched_clock_idle_wakeup_ev
Thanks for moving this along, Daniel. I think this is the right
approach... the cpuidle driver shouldn't be more complex than
necessary.
Note that you are starting your loop too high in cpuidle_play_dead...
states[state_count] is not an actual state anymore, it should start at
state_count - 1. Als
> Could we just say this is always true because state[i+1] consumes less
> than state[i] ?
>
> And then just remove the 'set_power_state' function, and the field
> 'driver->power_specified' ?
>
> That will cleanup the code and fix this problem, no ?
I totally agree with your analysis. Even if a dr
to enter them.
This patch ensures that the ACPI cpuidle driver sets those dummy power
values itself whenever it (re-)initializes its idle states.
Tested and verified on an Acer AC700 Chromebook, which supports the C3
state only when it switches from AC to battery power.
Signed-off-by: Julius Werner
> This is specific to the acpi and should be handled in the
> processor_idle.c file instead of the cpuidle core code.
>
> Could be the function 'acpi_processor_cst_has_changed' the right place
> to set a dummy power value for the power in the new C-state ?
Thanks for your feedback. I think it woul
