* Re: [bug?] Battery notifications produce flashing battery icon, syslog spam (Re: [PATCH 11/11] ACPI / Battery: Update information on info notification and resume)
From: Paolo Scarabelli @ 2012-05-02 11:49 UTC (permalink / raw)
To: Ralf Jung
Cc: Jonathan Nieder, Adrian Fita, Rafael J. Wysocki, Len Brown, LKML,
Matthew Garrett, ACPI Devel Maling List, Linux-pm mailing list,
Andy Whitcroft
In-Reply-To: <201205012142.55664.post@ralfj.de>
Hi,
I have the same problem on kernel 3.2.0 (actually I have the same
problem with all kernels I tried since reporting the issue the first time).
I'm almost sure this is related to several Debian bugs open for upower:
#606414, #596721 and #619343.
Is it possible that the high cpu problem with upowerd is caused just to
the log size increasing too much when the laptop is left on for a long time?
In my laptop upowerd starts using a lot of cpu only when I leave it on
overnight.
Regards,
Paolo
On 05/02/2012 03:42 AM, Ralf Jung wrote:
> Hi,
>
> in addition to the constant flickering when running on AC, there is a more
> "high frequency" flickering immediately after plugging in the AC: For some 5
> to 10 seconds, the battery appears and disappears (according to upower) around
> once per second. There's also a short moment without battery after plugging
> out the AC.
> All this is gone after going to a kernel version without this patch applied.
>
> I did not notice unusual high CPU usage of upower on my system, however I
> noticed disc activity - according to iotop, upower is writing several MiB of
> data per minute to /var/lib/upower/ where it keeps some battery statistics. I
> do not know whether this is out of the ordinary.
>
> Kind regards,
> Ralf
>
>
> On Tuesday 01 May 2012 21:14:08 Jonathan Nieder wrote:
>> (cc-ing Andy)
>>
>> Adrian Fita wrote:
>>> Also, searching on Google after "upowerd device
>>> removed:/org/freedesktop/UPower/devices/battery_BAT0", reveals much
>>> more bug reports with the exact issue.
>>
>> Thanks. That confirms the high CPU consumption in upowerd ---
>> see [1], for example.
>>
>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/987807
>
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Santosh Shilimkar @ 2012-05-02 7:22 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel@vger.kernel.org, Amit Kucheria,
linux-pm@lists.linux-foundation.org, Arjan van de Ven,
Arnd Bergmann, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMbhsRRhJ-7Am0k0OCJG0E9C=w+ApVi2Ce4b-BfV_6frJfTh=Q@mail.gmail.com>
On Wednesday 02 May 2012 05:41 AM, Colin Cross wrote:
> On Tue, May 1, 2012 at 3:43 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
>> Hi Colin,
>>
>> On Mon, Apr 30, 2012 at 10:37:30PM +0100, Colin Cross wrote:
> <snip>
>
>>> On Tegra3, the deepest individual cpu state for cpus 1-3 is OFF, the
>>> same state the cpu would go into as the first step of a transition to
>>> a deeper power state (cpus 0-3 OFF). It would be more optimal in that
>>> case to bypass the SMP cross call, and leave the cpu in OFF, but that
>>> would require some way of disabling all wakeups for the secondary cpus
>>> and then verifying that they didn't start waking up just before the
>>> wakeups were disabled. I have just started considering this
>>> optimization, but I don't see anything in the existing code that would
>>> prevent adding it later.
>>
I was also looking at how we can avoid the un-necessary wakeup on
secondary CPUs if the timer event is not for those CPUs. As you
rightly said, we can add all the optimisations once we have the
base patches merged.
>> I agree it is certainly an optimisation that can be added later if benchmarks
>> show it is needed (but again it is heavily platform dependent, ie technology
>> dependent).
>> On a side note, disabling (or move to the primary) wake-ups for "secondaries"
>> on platforms where every core is in a different power domain is still needed
>> to avoid having a situation where a CPU can independently get out of idle, ie
>> abort idle, after hitting the coupled barrier.
>> Still do not know if for those platforms coupled C-states should be used, but
>> it is much better to have a choice there IMHO.
>
> Yes, that is the primary need for the coupled_cpuidle_parallel_barrier
> function - secondary cpus need to disable their wakeup sources, then
> check that a wakeup was not already pending and abort if necessary.
>
>> I have also started thinking about a cluster or multi-CPU "next-event" that
>> could avoid triggering heavy operations like L2 cleaning (ie cluster shutdown)
>> if a timer is about to expire on a given CPU (as you know CPUs get in and out
>> of idle independently so the governor decision at the point the coupled state
>> barrier is hit might be stale).
>
> It would be possible to re-check the governor to decide the next state
> (maybe only if the previous decision is out of date by more than the
> target_residency?), but I left that as an additional optimization.
>
Yep. If the remaining time for idle is not enough, we
should abort that C-states since the CPU won't stay for good
enough time in the C-state to save power.
>> I reckon the coupled C-state concept can prove to be an effective one for
>> some platforms, currently benchmarking it.
>>
>>> A simple measurement using the tracing may show that it is
>>> unnecessary. If the wakeup time for CPU1 to go from OFF to active is
>>> small there might be no need to optimize out the extra wakeup.
>>
>> Indeed, it is all about resetting the CPU and getting it started, with
>> inclusive L2 the power cost of shutting down a CPU and resuming it should be
>> low (and timing very fast) for most platforms.
>
> The limiting factor may be the amount of time spent in ROM/Trustzone
> code when bringing a cpu back online.
It is fast but it's not very small time and will vary on CPU speed too.
As mentioned by Colin it all depends on secure code, CPU restore code
as well as the power domain transition time. Of course power domain
transition time will be different on different platforms.
Regards
santosh
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: J, KEERTHY @ 2012-05-02 5:04 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
In-Reply-To: <87wr4wriq3.fsf@ti.com>
On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman <khilman@ti.com> wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>
>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
>>> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>>
>>> > But presumably these things should integrate somehow - for example,
>>> > should devfreq and cpufreq be providing inputs into what AVS is doing,
>>> > and if so how?
>>
>>> The way it is currently designed, cpufreq/devfreq/regulator layers don't
>>> need to know about AVS.
>>
>> Yes, and that was a part of my concern, but see below.
>>
>>> The higher-level layers only know about the "nominal" voltage. AVS
>>> hardware does automatic, adaptive, micro-adjustments around that nominal
>>> voltage, and these micro-adjustments are managed by the AVS hardware
>>> sending commands to the PMIC. (specifically, on OMAP, the AVS sensors
>>> provide inputs to the voltage processor (VP) which provide inputs to the
>>> voltage controller (VC) which sends commands to the PMIC[1].)
>>
>> Right, that's what I'd understood it to be.
>>
>>> The driver proposed here is primarily for initializing the various
>>> parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
>>> adjustments are done in hardware by VC/VP.
>>
>> It's not just a driver, though - it's also creating this power/avs
>> thing, though now I look at the code rather than just its shape there's
>> not actually an abstraction being added here, it's mostly just straight
>> code motion of the arch/arm code that's there already. The changelog
>> and the shape of the code make it sound like this is intended to be
>> somewhat generic when really it's providing some OMAP specific tuning
>> for the device which is much less of a concern.
>>
>> I guess for now it's probably OK to just clarify in the documentation
>> and say that whoever adds the second driver has to work on making this
>> generic :)
>
> Agreed.
>
> In a different thread (which I can't seem to find now) we discussed this
> as well, so it just sounds like the changelog should clarify this a bit
> better.
Kevin/Mark,
Thanks for the feedback. I will add more documentation
to clarify this aspect. Please let me know if there are any more
things to be taken care of in this patch set.
>
> Kevin
>
>> This does also sound rather like it's in a similar area to the current
>> management work which Durgadoss R (CCed) was working on, though with a
>> slightly different application and in the OMAP case it's pretty much all
>> hidden in the external processor.
>
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Colin Cross @ 2012-05-02 0:11 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel@vger.kernel.org, Amit Kucheria,
linux-pm@lists.linux-foundation.org, Arjan van de Ven,
Arnd Bergmann, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20120501104310.GB28930@e102568-lin.cambridge.arm.com>
On Tue, May 1, 2012 at 3:43 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> Hi Colin,
>
> On Mon, Apr 30, 2012 at 10:37:30PM +0100, Colin Cross wrote:
<snip>
>> On Tegra3, the deepest individual cpu state for cpus 1-3 is OFF, the
>> same state the cpu would go into as the first step of a transition to
>> a deeper power state (cpus 0-3 OFF). It would be more optimal in that
>> case to bypass the SMP cross call, and leave the cpu in OFF, but that
>> would require some way of disabling all wakeups for the secondary cpus
>> and then verifying that they didn't start waking up just before the
>> wakeups were disabled. I have just started considering this
>> optimization, but I don't see anything in the existing code that would
>> prevent adding it later.
>
> I agree it is certainly an optimization that can be added later if benchmarks
> show it is needed (but again it is heavily platform dependent, ie technology
> dependent).
> On a side note, disabling (or move to the primary) wake-ups for "secondaries"
> on platforms where every core is in a different power domain is still needed
> to avoid having a situation where a CPU can independently get out of idle, ie
> abort idle, after hitting the coupled barrier.
> Still do not know if for those platforms coupled C-states should be used, but
> it is much better to have a choice there IMHO.
Yes, that is the primary need for the coupled_cpuidle_parallel_barrier
function - secondary cpus need to disable their wakeup sources, then
check that a wakeup was not already pending and abort if necessary.
> I have also started thinking about a cluster or multi-CPU "next-event" that
> could avoid triggering heavy operations like L2 cleaning (ie cluster shutdown)
> if a timer is about to expire on a given CPU (as you know CPUs get in and out
> of idle independently so the governor decision at the point the coupled state
> barrier is hit might be stale).
It would be possible to re-check the governor to decide the next state
(maybe only if the previous decision is out of date by more than the
target_residency?), but I left that as an additional optimization.
> I reckon the coupled C-state concept can prove to be an effective one for
> some platforms, currently benchmarking it.
>
>> A simple measurement using the tracing may show that it is
>> unnecessary. If the wakeup time for CPU1 to go from OFF to active is
>> small there might be no need to optimize out the extra wakeup.
>
> Indeed, it is all about resetting the CPU and getting it started, with
> inclusive L2 the power cost of shutting down a CPU and resuming it should be
> low (and timing very fast) for most platforms.
The limiting factor may be the amount of time spent in ROM/Trustzone
code when bringing a cpu back online.
^ permalink raw reply
* Re: [bug?] Battery notifications produce flashing battery icon, syslog spam (Re: [PATCH 11/11] ACPI / Battery: Update information on info notification and resume)
From: Ralf Jung @ 2012-05-01 19:42 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Adrian Fita, Rafael J. Wysocki, Len Brown, LKML, Matthew Garrett,
ACPI Devel Maling List, Linux-pm mailing list, Paolo Scarabelli,
Andy Whitcroft
In-Reply-To: <20120501191408.GD19143@burratino>
Hi,
in addition to the constant flickering when running on AC, there is a more
"high frequency" flickering immediately after plugging in the AC: For some 5
to 10 seconds, the battery appears and disappears (according to upower) around
once per second. There's also a short moment without battery after plugging
out the AC.
All this is gone after going to a kernel version without this patch applied.
I did not notice unusual high CPU usage of upower on my system, however I
noticed disc activity - according to iotop, upower is writing several MiB of
data per minute to /var/lib/upower/ where it keeps some battery statistics. I
do not know whether this is out of the ordinary.
Kind regards,
Ralf
On Tuesday 01 May 2012 21:14:08 Jonathan Nieder wrote:
> (cc-ing Andy)
>
> Adrian Fita wrote:
> > Also, searching on Google after "upowerd device
> > removed:/org/freedesktop/UPower/devices/battery_BAT0", reveals much
> > more bug reports with the exact issue.
>
> Thanks. That confirms the high CPU consumption in upowerd ---
> see [1], for example.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/987807
^ permalink raw reply
* Re: [bug?] Battery notifications produce flashing battery icon, syslog spam (Re: [PATCH 11/11] ACPI / Battery: Update information on info notification and resume)
From: Jonathan Nieder @ 2012-05-01 19:14 UTC (permalink / raw)
To: Adrian Fita
Cc: Rafael J. Wysocki, Len Brown, LKML, Matthew Garrett,
ACPI Devel Maling List, Linux-pm mailing list, Ralf Jung,
Paolo Scarabelli, Andy Whitcroft
In-Reply-To: <4FA032EA.1090608@gmail.com>
(cc-ing Andy)
Adrian Fita wrote:
> Also, searching on Google after "upowerd device
> removed:/org/freedesktop/UPower/devices/battery_BAT0", reveals much
> more bug reports with the exact issue.
Thanks. That confirms the high CPU consumption in upowerd ---
see [1], for example.
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/987807
^ permalink raw reply
* Re: [bug?] Battery notifications produce flashing battery icon, syslog spam (Re: [PATCH 11/11] ACPI / Battery: Update information on info notification and resume)
From: Adrian Fita @ 2012-05-01 19:00 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Paolo Scarabelli, LKML, Ralf Jung, ACPI Devel Maling List,
Linux-pm mailing list
In-Reply-To: <20120501184534.GA31731@burratino>
On 01/05/12 21:47, Jonathan Nieder wrote:
>
> [...]
>
> [...] More background
> at [2].
>
> [2] http://bugs.debian.org/670958
Also, searching on Google after "upowerd device
removed:/org/freedesktop/UPower/devices/battery_BAT0", reveals much more
bug reports with the exact issue.
Thanks,
--
Fita Adrian
^ permalink raw reply
* [bug?] Battery notifications produce flashing battery icon, syslog spam (Re: [PATCH 11/11] ACPI / Battery: Update information on info notification and resume)
From: Jonathan Nieder @ 2012-05-01 18:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, LKML, Matthew Garrett, ACPI Devel Maling List,
Linux-pm mailing list, Adrian Fita, Ralf Jung, Paolo Scarabelli
In-Reply-To: <201101062342.28168.rjw@sisk.pl>
Hi Rafael et al,
Rafael J. Wysocki wrote:
> A notification event 0x81 from an ACPI battery device requires us to
> re-read the battery information structure. Follow this requirement
> and remove and re-create the battery's attibutes in sysfs so that
> they reflect the reporting units used by the battery at the moment
> (those units may actually change sometimes at run time, which happens
> on some Thinkpads).
Ralf Jung was noticing his system tray power management icon in the
bottom-right corner *flickering* every 30 seconds with recent kernels.
Bisects to v2.6.38-rc1~68^2~4 ("ACPI / Battery: Update information on
info notification and resume"), which has the above description.
Some affected systems:
HP ProBook 4515s/3077, BIOS 68GPI Ver. F.03 (Adrian Fita)
HP ProBook 4510s (Paolo Scarabelli)
HP Compaq 615 (Ralf Jung)
Some symptoms:
KDE power management icon shows "no battery" for a fraction of a
second (upower is its backend)
upowerd makes CPU run at close to 100% CPU all the time (?)
/var/log/syslog gets lots of messages from laptop-mode, like this:
| Apr 20 10:52:14 zero laptop-mode: Laptop mode
| Apr 20 10:52:14 zero laptop-mode: enabled,
| Apr 20 10:52:14 zero laptop-mode: not active [unchanged]
| Apr 20 10:52:14 zero laptop-mode: Laptop mode
| Apr 20 10:52:14 zero laptop-mode: enabled,
| Apr 20 10:52:14 zero laptop-mode: not active [unchanged]
| Apr 20 10:52:33 zero laptop-mode: Laptop mode
| Apr 20 10:52:33 zero laptop-mode: enabled,
Known problems? Is there some way to handle notification events
without these side effects? Anything the submitters can do to help
track details down?
An acpidump from Adrian's system can be found at [1]. More background
at [2].
Thanks,
Jonathan
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=54;filename=acpidump_HP_ProBook_4515s.dat.gz;att=1;bug=670958
[2] http://bugs.debian.org/670958
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Lorenzo Pieralisi @ 2012-05-01 10:43 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel@vger.kernel.org, Amit Kucheria,
linux-pm@lists.linux-foundation.org, Arjan van de Ven,
Arnd Bergmann, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMbhsRRReyiv2LgUNgp6XiW07V8Eb0gd4fb7W6nBjMZ1FpmOBQ@mail.gmail.com>
Hi Colin,
On Mon, Apr 30, 2012 at 10:37:30PM +0100, Colin Cross wrote:
> On Mon, Apr 30, 2012 at 2:25 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Hi,
> >
> > I have a comment, which isn't about the series itself, but something
> > thay may be worth thinking about.
> >
> > On Monday, April 30, 2012, Colin Cross wrote:
> >> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> >> cpus cannot be independently powered down, either due to
> >> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> >> power down), or due to HW bugs (on OMAP4460, a cpu powering up
> >> will corrupt the gic state unless the other cpu runs a work
> >> around). Each cpu has a power state that it can enter without
> >> coordinating with the other cpu (usually Wait For Interrupt, or
> >> WFI), and one or more "coupled" power states that affect blocks
> >> shared between the cpus (L2 cache, interrupt controller, and
> >> sometimes the whole SoC). Entering a coupled power state must
> >> be tightly controlled on both cpus.
> >
> > That seems to be a special case of a more general situation where
> > a number of CPU cores belong into a single power domain, possibly along
> > some I/O devices.
> >
> > We'll need to handle the general case at one point anyway, so I wonder if
> > the approach shown here may get us in the way?
>
> I can't parse what you're saying here.
>
> >> The easiest solution to implementing coupled cpu power states is
> >> to hotplug all but one cpu whenever possible, usually using a
> >> cpufreq governor that looks at cpu load to determine when to
> >> enable the secondary cpus. This causes problems, as hotplug is an
> >> expensive operation, so the number of hotplug transitions must be
> >> minimized, leading to very slow response to loads, often on the
> >> order of seconds.
> >
> > This isn't a solution at all, rather a workaround and a poor one for that
> > matter.
>
> Yes, which is what started me on this series.
>
> >> This patch series implements an alternative solution, where each
> >> cpu will wait in the WFI state until all cpus are ready to enter
> >> a coupled state, at which point the coupled state function will
> >> be called on all cpus at approximately the same time.
> >>
> >> Once all cpus are ready to enter idle, they are woken by an smp
> >> cross call.
> >
> > Is it really necessary to wake up all of the CPUs in WFI before
> > going to deeper idle? We should be able to figure out when they
> > are going to be needed next time without waking them up and we should
> > know the latency to wake up from the deeper multi-CPU "C-state",
> > so it should be possible to decide whether or not to go to deeper
> > idle without the SMP cross call. Is there anything I'm missing here?
>
> The decision to go to the lower state has already been made when the
> cross call occurs. On the platforms I have worked directly with so
> far (Tegra2 and OMAP4460), the secondary cpu needs to execute code
> before the primary cpu turns off the power. For example, on OMAP4460,
> the secondary cpu needs to go from WFI (clock gated) to OFF (power
> gated), because OFF is not supported as an individual cpu state due to
> a ROM code bug. To do that transition, it needs to come out of WFI,
> set up it's power domain registers, save a bunch of state, and
> transition to OFF.
>
> On Tegra3, the deepest individual cpu state for cpus 1-3 is OFF, the
> same state the cpu would go into as the first step of a transition to
> a deeper power state (cpus 0-3 OFF). It would be more optimal in that
> case to bypass the SMP cross call, and leave the cpu in OFF, but that
> would require some way of disabling all wakeups for the secondary cpus
> and then verifying that they didn't start waking up just before the
> wakeups were disabled. I have just started considering this
> optimization, but I don't see anything in the existing code that would
> prevent adding it later.
I agree it is certainly an optimization that can be added later if benchmarks
show it is needed (but again it is heavily platform dependent, ie technology
dependent).
On a side note, disabling (or move to the primary) wake-ups for "secondaries"
on platforms where every core is in a different power domain is still needed
to avoid having a situation where a CPU can independently get out of idle, ie
abort idle, after hitting the coupled barrier.
Still do not know if for those platforms coupled C-states should be used, but
it is much better to have a choice there IMHO.
I have also started thinking about a cluster or multi-CPU "next-event" that
could avoid triggering heavy operations like L2 cleaning (ie cluster shutdown)
if a timer is about to expire on a given CPU (as you know CPUs get in and out
of idle independently so the governor decision at the point the coupled state
barrier is hit might be stale).
I reckon the coupled C-state concept can prove to be an effective one for
some platforms, currently benchmarking it.
> A simple measurement using the tracing may show that it is
> unnecessary. If the wakeup time for CPU1 to go from OFF to active is
> small there might be no need to optimize out the extra wakeup.
Indeed, it is all about resetting the CPU and getting it started, with
inclusive L2 the power cost of shutting down a CPU and resuming it should be
low (and timing very fast) for most platforms.
Lorenzo
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Colin Cross @ 2012-04-30 22:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <201204302354.41969.rjw@sisk.pl>
On Mon, Apr 30, 2012 at 2:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday, April 30, 2012, Colin Cross wrote:
>> On Mon, Apr 30, 2012 at 2:25 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > Hi,
>> >
>> > I have a comment, which isn't about the series itself, but something
>> > thay may be worth thinking about.
>> >
>> > On Monday, April 30, 2012, Colin Cross wrote:
>> >> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
>> >> cpus cannot be independently powered down, either due to
>> >> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
>> >> power down), or due to HW bugs (on OMAP4460, a cpu powering up
>> >> will corrupt the gic state unless the other cpu runs a work
>> >> around). Each cpu has a power state that it can enter without
>> >> coordinating with the other cpu (usually Wait For Interrupt, or
>> >> WFI), and one or more "coupled" power states that affect blocks
>> >> shared between the cpus (L2 cache, interrupt controller, and
>> >> sometimes the whole SoC). Entering a coupled power state must
>> >> be tightly controlled on both cpus.
>> >
>> > That seems to be a special case of a more general situation where
>> > a number of CPU cores belong into a single power domain, possibly along
>> > some I/O devices.
>> >
>> > We'll need to handle the general case at one point anyway, so I wonder if
>> > the approach shown here may get us in the way?
>>
>> I can't parse what you're saying here.
>
> The general case is a CPU core in one PM domain with a number of I/O
> devices and a number of other CPU cores. If we forget about the I/O
> devices, we get a situation your patchset is addressing, so the
> question is how difficult it is going to be to extend it to cover the
> I/O devices as well.
The logic in this patch set is always going to be required to get
multiple cpus to coordinate an idle transition, and it will need to
stay fairly tightly coupled with cpuidle to correctly track the idle
time statistics for the intermediate and final states. I don't think
there would be an issue if it ends up getting hoisted out into a
future combined cpu/IO power domain, but it seems more likely that the
coupled cpu idle states would call into the power domain to say they
no longer need power.
>> >> The easiest solution to implementing coupled cpu power states is
>> >> to hotplug all but one cpu whenever possible, usually using a
>> >> cpufreq governor that looks at cpu load to determine when to
>> >> enable the secondary cpus. This causes problems, as hotplug is an
>> >> expensive operation, so the number of hotplug transitions must be
>> >> minimized, leading to very slow response to loads, often on the
>> >> order of seconds.
>> >
>> > This isn't a solution at all, rather a workaround and a poor one for that
>> > matter.
>>
>> Yes, which is what started me on this series.
>>
>> >> This patch series implements an alternative solution, where each
>> >> cpu will wait in the WFI state until all cpus are ready to enter
>> >> a coupled state, at which point the coupled state function will
>> >> be called on all cpus at approximately the same time.
>> >>
>> >> Once all cpus are ready to enter idle, they are woken by an smp
>> >> cross call.
>> >
>> > Is it really necessary to wake up all of the CPUs in WFI before
>> > going to deeper idle? We should be able to figure out when they
>> > are going to be needed next time without waking them up and we should
>> > know the latency to wake up from the deeper multi-CPU "C-state",
>> > so it should be possible to decide whether or not to go to deeper
>> > idle without the SMP cross call. Is there anything I'm missing here?
>>
>> The decision to go to the lower state has already been made when the
>> cross call occurs. On the platforms I have worked directly with so
>> far (Tegra2 and OMAP4460), the secondary cpu needs to execute code
>> before the primary cpu turns off the power. For example, on OMAP4460,
>> the secondary cpu needs to go from WFI (clock gated) to OFF (power
>> gated), because OFF is not supported as an individual cpu state due to
>> a ROM code bug. To do that transition, it needs to come out of WFI,
>> set up it's power domain registers, save a bunch of state, and
>> transition to OFF.
>>
>> On Tegra3, the deepest individual cpu state for cpus 1-3 is OFF, the
>> same state the cpu would go into as the first step of a transition to
>> a deeper power state (cpus 0-3 OFF). It would be more optimal in that
>> case to bypass the SMP cross call, and leave the cpu in OFF, but that
>> would require some way of disabling all wakeups for the secondary cpus
>> and then verifying that they didn't start waking up just before the
>> wakeups were disabled. I have just started considering this
>> optimization, but I don't see anything in the existing code that would
>> prevent adding it later.
>
> OK
>
>> A simple measurement using the tracing may show that it is
>> unnecessary. If the wakeup time for CPU1 to go from OFF to active is
>> small there might be no need to optimize out the extra wakeup.
>
> I see.
>
> So, in the end, it may always be more straightforward to put individual
> CPU cores into single-core idle states until the "we can all go to
> deeper idle" condition is satisfied and then wake them all up and let
> each of them do the transition individually, right?
Yes, the tradeoff will be the complexity of code to handle a generic
way of holding another cpu in idle while this cpu does the transition
vs. the time and power required to bring a cpu back online just to put
it into a deeper state. Right now, since all the users of this code
are using WFI for their intermediate state, it takes microseconds to
bring a cpu back up. On Tegra3, the answer might be "sometimes" -
only cpu0 can perform the final idle state transition, so if cpu1 is
the last to go to idle, it will always have to SMP cross call to cpu0,
but if cpu0 is the last to go idle it may be able to avoid waking up
cpu1.
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Rafael J. Wysocki @ 2012-04-30 21:54 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <CAMbhsRRReyiv2LgUNgp6XiW07V8Eb0gd4fb7W6nBjMZ1FpmOBQ@mail.gmail.com>
On Monday, April 30, 2012, Colin Cross wrote:
> On Mon, Apr 30, 2012 at 2:25 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Hi,
> >
> > I have a comment, which isn't about the series itself, but something
> > thay may be worth thinking about.
> >
> > On Monday, April 30, 2012, Colin Cross wrote:
> >> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> >> cpus cannot be independently powered down, either due to
> >> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> >> power down), or due to HW bugs (on OMAP4460, a cpu powering up
> >> will corrupt the gic state unless the other cpu runs a work
> >> around). Each cpu has a power state that it can enter without
> >> coordinating with the other cpu (usually Wait For Interrupt, or
> >> WFI), and one or more "coupled" power states that affect blocks
> >> shared between the cpus (L2 cache, interrupt controller, and
> >> sometimes the whole SoC). Entering a coupled power state must
> >> be tightly controlled on both cpus.
> >
> > That seems to be a special case of a more general situation where
> > a number of CPU cores belong into a single power domain, possibly along
> > some I/O devices.
> >
> > We'll need to handle the general case at one point anyway, so I wonder if
> > the approach shown here may get us in the way?
>
> I can't parse what you're saying here.
The general case is a CPU core in one PM domain with a number of I/O
devices and a number of other CPU cores. If we forget about the I/O
devices, we get a situation your patchset is addressing, so the
question is how difficult it is going to be to extend it to cover the
I/O devices as well.
> >> The easiest solution to implementing coupled cpu power states is
> >> to hotplug all but one cpu whenever possible, usually using a
> >> cpufreq governor that looks at cpu load to determine when to
> >> enable the secondary cpus. This causes problems, as hotplug is an
> >> expensive operation, so the number of hotplug transitions must be
> >> minimized, leading to very slow response to loads, often on the
> >> order of seconds.
> >
> > This isn't a solution at all, rather a workaround and a poor one for that
> > matter.
>
> Yes, which is what started me on this series.
>
> >> This patch series implements an alternative solution, where each
> >> cpu will wait in the WFI state until all cpus are ready to enter
> >> a coupled state, at which point the coupled state function will
> >> be called on all cpus at approximately the same time.
> >>
> >> Once all cpus are ready to enter idle, they are woken by an smp
> >> cross call.
> >
> > Is it really necessary to wake up all of the CPUs in WFI before
> > going to deeper idle? We should be able to figure out when they
> > are going to be needed next time without waking them up and we should
> > know the latency to wake up from the deeper multi-CPU "C-state",
> > so it should be possible to decide whether or not to go to deeper
> > idle without the SMP cross call. Is there anything I'm missing here?
>
> The decision to go to the lower state has already been made when the
> cross call occurs. On the platforms I have worked directly with so
> far (Tegra2 and OMAP4460), the secondary cpu needs to execute code
> before the primary cpu turns off the power. For example, on OMAP4460,
> the secondary cpu needs to go from WFI (clock gated) to OFF (power
> gated), because OFF is not supported as an individual cpu state due to
> a ROM code bug. To do that transition, it needs to come out of WFI,
> set up it's power domain registers, save a bunch of state, and
> transition to OFF.
>
> On Tegra3, the deepest individual cpu state for cpus 1-3 is OFF, the
> same state the cpu would go into as the first step of a transition to
> a deeper power state (cpus 0-3 OFF). It would be more optimal in that
> case to bypass the SMP cross call, and leave the cpu in OFF, but that
> would require some way of disabling all wakeups for the secondary cpus
> and then verifying that they didn't start waking up just before the
> wakeups were disabled. I have just started considering this
> optimization, but I don't see anything in the existing code that would
> prevent adding it later.
OK
> A simple measurement using the tracing may show that it is
> unnecessary. If the wakeup time for CPU1 to go from OFF to active is
> small there might be no need to optimize out the extra wakeup.
I see.
So, in the end, it may always be more straightforward to put individual
CPU cores into single-core idle states until the "we can all go to
deeper idle" condition is satisfied and then wake them all up and let
each of them do the transition individually, right?
Rafael
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Kevin Hilman @ 2012-04-30 21:51 UTC (permalink / raw)
To: Mark Brown
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
In-Reply-To: <20120430095429.GB3170@opensource.wolfsonmicro.com>
Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
>> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>
>> > But presumably these things should integrate somehow - for example,
>> > should devfreq and cpufreq be providing inputs into what AVS is doing,
>> > and if so how?
>
>> The way it is currently designed, cpufreq/devfreq/regulator layers don't
>> need to know about AVS.
>
> Yes, and that was a part of my concern, but see below.
>
>> The higher-level layers only know about the "nominal" voltage. AVS
>> hardware does automatic, adaptive, micro-adjustments around that nominal
>> voltage, and these micro-adjustments are managed by the AVS hardware
>> sending commands to the PMIC. (specifically, on OMAP, the AVS sensors
>> provide inputs to the voltage processor (VP) which provide inputs to the
>> voltage controller (VC) which sends commands to the PMIC[1].)
>
> Right, that's what I'd understood it to be.
>
>> The driver proposed here is primarily for initializing the various
>> parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
>> adjustments are done in hardware by VC/VP.
>
> It's not just a driver, though - it's also creating this power/avs
> thing, though now I look at the code rather than just its shape there's
> not actually an abstraction being added here, it's mostly just straight
> code motion of the arch/arm code that's there already. The changelog
> and the shape of the code make it sound like this is intended to be
> somewhat generic when really it's providing some OMAP specific tuning
> for the device which is much less of a concern.
>
> I guess for now it's probably OK to just clarify in the documentation
> and say that whoever adds the second driver has to work on making this
> generic :)
Agreed.
In a different thread (which I can't seem to find now) we discussed this
as well, so it just sounds like the changelog should clarify this a bit
better.
Kevin
> This does also sound rather like it's in a similar area to the current
> management work which Durgadoss R (CCed) was working on, though with a
> slightly different application and in the OMAP case it's pretty much all
> hidden in the external processor.
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Colin Cross @ 2012-04-30 21:37 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <201204302325.09505.rjw@sisk.pl>
On Mon, Apr 30, 2012 at 2:25 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Hi,
>
> I have a comment, which isn't about the series itself, but something
> thay may be worth thinking about.
>
> On Monday, April 30, 2012, Colin Cross wrote:
>> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
>> cpus cannot be independently powered down, either due to
>> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
>> power down), or due to HW bugs (on OMAP4460, a cpu powering up
>> will corrupt the gic state unless the other cpu runs a work
>> around). Each cpu has a power state that it can enter without
>> coordinating with the other cpu (usually Wait For Interrupt, or
>> WFI), and one or more "coupled" power states that affect blocks
>> shared between the cpus (L2 cache, interrupt controller, and
>> sometimes the whole SoC). Entering a coupled power state must
>> be tightly controlled on both cpus.
>
> That seems to be a special case of a more general situation where
> a number of CPU cores belong into a single power domain, possibly along
> some I/O devices.
>
> We'll need to handle the general case at one point anyway, so I wonder if
> the approach shown here may get us in the way?
I can't parse what you're saying here.
>> The easiest solution to implementing coupled cpu power states is
>> to hotplug all but one cpu whenever possible, usually using a
>> cpufreq governor that looks at cpu load to determine when to
>> enable the secondary cpus. This causes problems, as hotplug is an
>> expensive operation, so the number of hotplug transitions must be
>> minimized, leading to very slow response to loads, often on the
>> order of seconds.
>
> This isn't a solution at all, rather a workaround and a poor one for that
> matter.
Yes, which is what started me on this series.
>> This patch series implements an alternative solution, where each
>> cpu will wait in the WFI state until all cpus are ready to enter
>> a coupled state, at which point the coupled state function will
>> be called on all cpus at approximately the same time.
>>
>> Once all cpus are ready to enter idle, they are woken by an smp
>> cross call.
>
> Is it really necessary to wake up all of the CPUs in WFI before
> going to deeper idle? We should be able to figure out when they
> are going to be needed next time without waking them up and we should
> know the latency to wake up from the deeper multi-CPU "C-state",
> so it should be possible to decide whether or not to go to deeper
> idle without the SMP cross call. Is there anything I'm missing here?
The decision to go to the lower state has already been made when the
cross call occurs. On the platforms I have worked directly with so
far (Tegra2 and OMAP4460), the secondary cpu needs to execute code
before the primary cpu turns off the power. For example, on OMAP4460,
the secondary cpu needs to go from WFI (clock gated) to OFF (power
gated), because OFF is not supported as an individual cpu state due to
a ROM code bug. To do that transition, it needs to come out of WFI,
set up it's power domain registers, save a bunch of state, and
transition to OFF.
On Tegra3, the deepest individual cpu state for cpus 1-3 is OFF, the
same state the cpu would go into as the first step of a transition to
a deeper power state (cpus 0-3 OFF). It would be more optimal in that
case to bypass the SMP cross call, and leave the cpu in OFF, but that
would require some way of disabling all wakeups for the secondary cpus
and then verifying that they didn't start waking up just before the
wakeups were disabled. I have just started considering this
optimization, but I don't see anything in the existing code that would
prevent adding it later.
A simple measurement using the tracing may show that it is
unnecessary. If the wakeup time for CPU1 to go from OFF to active is
small there might be no need to optimize out the extra wakeup.
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Rafael J. Wysocki @ 2012-04-30 21:25 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1335816551-27756-1-git-send-email-ccross@android.com>
Hi,
I have a comment, which isn't about the series itself, but something
thay may be worth thinking about.
On Monday, April 30, 2012, Colin Cross wrote:
> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> cpus cannot be independently powered down, either due to
> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> power down), or due to HW bugs (on OMAP4460, a cpu powering up
> will corrupt the gic state unless the other cpu runs a work
> around). Each cpu has a power state that it can enter without
> coordinating with the other cpu (usually Wait For Interrupt, or
> WFI), and one or more "coupled" power states that affect blocks
> shared between the cpus (L2 cache, interrupt controller, and
> sometimes the whole SoC). Entering a coupled power state must
> be tightly controlled on both cpus.
That seems to be a special case of a more general situation where
a number of CPU cores belong into a single power domain, possibly along
some I/O devices.
We'll need to handle the general case at one point anyway, so I wonder if
the approach shown here may get us in the way?
> The easiest solution to implementing coupled cpu power states is
> to hotplug all but one cpu whenever possible, usually using a
> cpufreq governor that looks at cpu load to determine when to
> enable the secondary cpus. This causes problems, as hotplug is an
> expensive operation, so the number of hotplug transitions must be
> minimized, leading to very slow response to loads, often on the
> order of seconds.
This isn't a solution at all, rather a workaround and a poor one for that
matter.
> This patch series implements an alternative solution, where each
> cpu will wait in the WFI state until all cpus are ready to enter
> a coupled state, at which point the coupled state function will
> be called on all cpus at approximately the same time.
>
> Once all cpus are ready to enter idle, they are woken by an smp
> cross call.
Is it really necessary to wake up all of the CPUs in WFI before
going to deeper idle? We should be able to figure out when they
are going to be needed next time without waking them up and we should
know the latency to wake up from the deeper multi-CPU "C-state",
so it should be possible to decide whether or not to go to deeper
idle without the SMP cross call. Is there anything I'm missing here?
Rafael
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Colin Cross @ 2012-04-30 21:18 UTC (permalink / raw)
To: linux-kernel
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, Amit Kucheria, Colin Cross, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1335816551-27756-1-git-send-email-ccross@android.com>
On Mon, Apr 30, 2012 at 1:09 PM, Colin Cross <ccross@android.com> wrote:
> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> cpus cannot be independently powered down, either due to
> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> power down), or due to HW bugs (on OMAP4460, a cpu powering up
> will corrupt the gic state unless the other cpu runs a work
> around). Each cpu has a power state that it can enter without
> coordinating with the other cpu (usually Wait For Interrupt, or
> WFI), and one or more "coupled" power states that affect blocks
> shared between the cpus (L2 cache, interrupt controller, and
> sometimes the whole SoC). Entering a coupled power state must
> be tightly controlled on both cpus.
>
> The easiest solution to implementing coupled cpu power states is
> to hotplug all but one cpu whenever possible, usually using a
> cpufreq governor that looks at cpu load to determine when to
> enable the secondary cpus. This causes problems, as hotplug is an
> expensive operation, so the number of hotplug transitions must be
> minimized, leading to very slow response to loads, often on the
> order of seconds.
>
> This patch series implements an alternative solution, where each
> cpu will wait in the WFI state until all cpus are ready to enter
> a coupled state, at which point the coupled state function will
> be called on all cpus at approximately the same time.
>
> Once all cpus are ready to enter idle, they are woken by an smp
> cross call. At this point, there is a chance that one of the
> cpus will find work to do, and choose not to enter suspend. A
> final pass is needed to guarantee that all cpus will call the
> power state enter function at the same time. During this pass,
> each cpu will increment the ready counter, and continue once the
> ready counter matches the number of online coupled cpus. If any
> cpu exits idle, the other cpus will decrement their counter and
> retry.
>
> To use coupled cpuidle states, a cpuidle driver must:
>
> Set struct cpuidle_device.coupled_cpus to the mask of all
> coupled cpus, usually the same as cpu_possible_mask if all cpus
> are part of the same cluster. The coupled_cpus mask must be
> set in the struct cpuidle_device for each cpu.
>
> Set struct cpuidle_device.safe_state to a state that is not a
> coupled state. This is usually WFI.
>
> Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
> state that affects multiple cpus.
>
> Provide a struct cpuidle_state.enter function for each state
> that affects multiple cpus. This function is guaranteed to be
> called on all cpus at approximately the same time. The driver
> should ensure that the cpus all abort together if any cpu tries
> to abort once the function is called.
>
> This series has been tested by implementing a test cpuidle state
> that uses the parallel barrier helper function to verify that
> all cpus call the function at the same time.
>
> This patch set has a few disadvantages over the hotplug governor,
> but I think they are all fairly minor:
> * Worst-case interrupt latency can be increased. If one cpu
> receives an interrupt while the other is spinning in the
> ready_count loop, the second cpu will be stuck with
> interrupts off until the first cpu finished processing
> its interrupt and exits idle. This will increase the worst
> case interrupt latency by the worst-case interrupt processing
> time, but should be very rare.
> * Interrupts are processed while still inside pm_idle.
> Normally, interrupts are only processed at the very end of
> pm_idle, just before it returns to the idle loop. Coupled
> states requires processing interrupts inside
> cpuidle_enter_state_coupled in order to distinguish between
> the smp_cross_call from another cpu that is now idle and an
> interrupt that should cause idle to exit.
> I don't see a way to fix this without either being able to
> read the next pending irq from the interrupt chip, or
> querying the irq core for which interrupts were processed.
> * Since interrupts are processed inside cpuidle, the next
> timer event could change. The new timer event will be
> handled correctly, but the idle state decision made by
> the governor will be out of date, and will not be revisited.
> The governor select function could be called again every time,
> but this could lead to a lot of work being done by an idle
> cpu if the other cpu was mostly busy.
>
> v2:
> * removed the coupled lock, replacing it with atomic counters
> * added a check for outstanding pokes before beginning the
> final transition to avoid extra wakeups
> * made the cpuidle_coupled struct completely private
> * fixed kerneldoc comment formatting
> * added a patch with a helper function for resynchronizing
> cpus after aborting idle
> * added a patch (not for merging) to add trace events for
> verification and performance testing
>
> v3:
> * rebased on v3.4-rc4 by Santosh
> * fixed decrement in cpuidle_coupled_cpu_set_alive
> * updated tracing patch to remove unnecessary debugging so
> it can be merged
> * made tracing _rcuidle
>
> This series has been tested and reviewed by Santosh and Kevin
> for OMAP4, which has a cpuidle series ready for 3.5, and Tegra
> and Exynos5 patches are in progress. I think this is ready to
> go in. Lean, are you maintaining a cpuidle tree for linux-next?
Sorry, *Len.
> If not, I can publish a tree for linux-next, or this could go in
> through Arnd's tree.
^ permalink raw reply
* [PATCHv3 5/5] cpuidle: coupled: add trace events
From: Colin Cross @ 2012-04-30 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, Amit Kucheria, Colin Cross, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1335816551-27756-1-git-send-email-ccross@android.com>
Adds trace events to allow debugging of coupled cpuidle.
Can be used to verify cpuidle performance, including time spent
spinning and time spent in safe states.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Colin Cross <ccross@android.com>
---
drivers/cpuidle/coupled.c | 29 +++++-
include/trace/events/cpuidle.h | 243 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 270 insertions(+), 2 deletions(-)
create mode 100644 include/trace/events/cpuidle.h
v3:
* removed debugging code from cpuidle_coupled_parallel_barrier
so this patch can be merged to help with debugging new
coupled cpuidle drivers
* made tracing _rcuidle
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 242dc7c..6b63d67 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -26,6 +26,11 @@
#include "cpuidle.h"
+#define CREATE_TRACE_POINTS
+#include <trace/events/cpuidle.h>
+
+atomic_t cpuidle_trace_seq;
+
/**
* DOC: Coupled cpuidle states
*
@@ -232,6 +237,7 @@ static inline int cpuidle_coupled_get_state(struct cpuidle_device *dev,
static void cpuidle_coupled_poked(void *info)
{
int cpu = (unsigned long)info;
+ trace_coupled_poked_rcuidle(cpu);
cpumask_clear_cpu(cpu, &cpuidle_coupled_poked_mask);
}
@@ -251,8 +257,10 @@ static void cpuidle_coupled_poke(int cpu)
{
struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
- if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
+ if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask)) {
+ trace_coupled_poke_rcuidle(cpu);
__smp_call_function_single(cpu, csd, 0);
+ }
}
/**
@@ -361,28 +369,37 @@ int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
BUG_ON(atomic_read(&coupled->ready_count));
cpuidle_coupled_set_waiting(dev, coupled, next_state);
+ trace_coupled_enter_rcuidle(dev->cpu);
+
retry:
/*
* Wait for all coupled cpus to be idle, using the deepest state
* allowed for a single cpu.
*/
while (!need_resched() && !cpuidle_coupled_cpus_waiting(coupled)) {
+ trace_coupled_safe_enter_rcuidle(dev->cpu);
entered_state = cpuidle_enter_state(dev, drv,
dev->safe_state_index);
+ trace_coupled_safe_exit_rcuidle(dev->cpu);
+ trace_coupled_spin_rcuidle(dev->cpu);
local_irq_enable();
while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
cpu_relax();
local_irq_disable();
+ trace_coupled_unspin_rcuidle(dev->cpu);
}
/* give a chance to process any remaining pokes */
+ trace_coupled_spin_rcuidle(dev->cpu);
local_irq_enable();
while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
cpu_relax();
local_irq_disable();
+ trace_coupled_unspin_rcuidle(dev->cpu);
if (need_resched()) {
+ trace_coupled_abort_rcuidle(dev->cpu);
cpuidle_coupled_set_not_waiting(dev, coupled);
goto out;
}
@@ -401,29 +418,35 @@ int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
smp_mb__after_atomic_inc();
/* alive_count can't change while ready_count > 0 */
alive = atomic_read(&coupled->alive_count);
+ trace_coupled_spin_rcuidle(dev->cpu);
while (atomic_read(&coupled->ready_count) != alive) {
/* Check if any other cpus bailed out of idle. */
if (!cpuidle_coupled_cpus_waiting(coupled)) {
atomic_dec(&coupled->ready_count);
smp_mb__after_atomic_dec();
+ trace_coupled_detected_abort_rcuidle(dev->cpu);
goto retry;
}
cpu_relax();
}
+ trace_coupled_unspin_rcuidle(dev->cpu);
/* all cpus have acked the coupled state */
smp_rmb();
next_state = cpuidle_coupled_get_state(dev, coupled);
-
+ trace_coupled_idle_enter_rcuidle(dev->cpu);
entered_state = cpuidle_enter_state(dev, drv, next_state);
+ trace_coupled_idle_exit_rcuidle(dev->cpu);
cpuidle_coupled_set_not_waiting(dev, coupled);
atomic_dec(&coupled->ready_count);
smp_mb__after_atomic_dec();
out:
+ trace_coupled_exit_rcuidle(dev->cpu);
+
/*
* Normal cpuidle states are expected to return with irqs enabled.
* That leads to an inefficiency where a cpu receiving an interrupt
@@ -445,8 +468,10 @@ int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
* a cpu exits and re-enters the ready state because this cpu has
* already decremented its waiting_count.
*/
+ trace_coupled_spin_rcuidle(dev->cpu);
while (atomic_read(&coupled->ready_count) != 0)
cpu_relax();
+ trace_coupled_unspin_rcuidle(dev->cpu);
smp_rmb();
diff --git a/include/trace/events/cpuidle.h b/include/trace/events/cpuidle.h
new file mode 100644
index 0000000..9b2cbbb
--- /dev/null
+++ b/include/trace/events/cpuidle.h
@@ -0,0 +1,243 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM cpuidle
+
+#if !defined(_TRACE_CPUIDLE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CPUIDLE_H
+
+#include <linux/atomic.h>
+#include <linux/tracepoint.h>
+
+extern atomic_t cpuidle_trace_seq;
+
+TRACE_EVENT(coupled_enter,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_exit,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_spin,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_unspin,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_safe_enter,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_safe_exit,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_idle_enter,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_idle_exit,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_abort,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_detected_abort,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_poke,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+TRACE_EVENT(coupled_poked,
+
+ TP_PROTO(unsigned int cpu),
+
+ TP_ARGS(cpu),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, cpu)
+ __field(unsigned int, seq)
+ ),
+
+ TP_fast_assign(
+ __entry->cpu = cpu;
+ __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
+ ),
+
+ TP_printk("%u %u", __entry->seq, __entry->cpu)
+);
+
+#endif /* if !defined(_TRACE_CPUIDLE_H) || defined(TRACE_HEADER_MULTI_READ) */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
1.7.7.3
^ permalink raw reply related
* [PATCHv3 4/5] cpuidle: coupled: add parallel barrier function
From: Colin Cross @ 2012-04-30 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, linux-pm, Kevin Hilman, Len Brown,
Trinabh Gupta, Arjan van de Ven, Deepthi Dharwar,
Greg Kroah-Hartman, Kay Sievers, Santosh Shilimkar,
Daniel Lezcano, Amit Kucheria, Lorenzo Pieralisi, Arnd Bergmann,
Russell King, Colin Cross
In-Reply-To: <1335816551-27756-1-git-send-email-ccross@android.com>
Adds cpuidle_coupled_parallel_barrier, which can be used by coupled
cpuidle state enter functions to handle resynchronization after
determining if any cpu needs to abort. The normal use case will
be:
static bool abort_flag;
static atomic_t abort_barrier;
int arch_cpuidle_enter(struct cpuidle_device *dev, ...)
{
if (arch_turn_off_irq_controller()) {
/* returns an error if an irq is pending and would be lost
if idle continued and turned off power */
abort_flag = true;
}
cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
if (abort_flag) {
/* One of the cpus didn't turn off it's irq controller */
arch_turn_on_irq_controller();
return -EINTR;
}
/* continue with idle */
...
}
This will cause all cpus to abort idle together if one of them needs
to abort.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Colin Cross <ccross@android.com>
---
drivers/cpuidle/coupled.c | 37 +++++++++++++++++++++++++++++++++++++
include/linux/cpuidle.h | 4 ++++
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index d097826..242dc7c 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -134,6 +134,43 @@ struct cpuidle_coupled {
static cpumask_t cpuidle_coupled_poked_mask;
/**
+ * cpuidle_coupled_parallel_barrier - synchronize all online coupled cpus
+ * @dev: cpuidle_device of the calling cpu
+ * @a: atomic variable to hold the barrier
+ *
+ * No caller to this function will return from this function until all online
+ * cpus in the same coupled group have called this function. Once any caller
+ * has returned from this function, the barrier is immediately available for
+ * reuse.
+ *
+ * The atomic variable a must be initialized to 0 before any cpu calls
+ * this function, will be reset to 0 before any cpu returns from this function.
+ *
+ * Must only be called from within a coupled idle state handler
+ * (state.enter when state.flags has CPUIDLE_FLAG_COUPLED set).
+ *
+ * Provides full smp barrier semantics before and after calling.
+ */
+void cpuidle_coupled_parallel_barrier(struct cpuidle_device *dev, atomic_t *a)
+{
+ int n = atomic_read(&dev->coupled->alive_count);
+
+ smp_mb__before_atomic_inc();
+ atomic_inc(a);
+
+ while (atomic_read(a) < n)
+ cpu_relax();
+
+ if (atomic_inc_return(a) == n * 2) {
+ atomic_set(a, 0);
+ return;
+ }
+
+ while (atomic_read(a) > n)
+ cpu_relax();
+}
+
+/**
* cpuidle_state_is_coupled - check if a state is part of a coupled set
* @dev: struct cpuidle_device for the current cpu
* @drv: struct cpuidle_driver for the platform
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 6038448..5ab7183 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -183,6 +183,10 @@ static inline int cpuidle_wrap_enter(struct cpuidle_device *dev,
#endif
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
+void cpuidle_coupled_parallel_barrier(struct cpuidle_device *dev, atomic_t *a);
+#endif
+
/******************************
* CPUIDLE GOVERNOR INTERFACE *
******************************/
--
1.7.7.3
^ permalink raw reply related
* [PATCHv3 3/5] cpuidle: add support for states that affect multiple cpus
From: Colin Cross @ 2012-04-30 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, Amit Kucheria, Colin Cross, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1335816551-27756-1-git-send-email-ccross@android.com>
On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
cpus cannot be independently powered down, either due to
sequencing restrictions (on Tegra 2, cpu 0 must be the last to
power down), or due to HW bugs (on OMAP4460, a cpu powering up
will corrupt the gic state unless the other cpu runs a work
around). Each cpu has a power state that it can enter without
coordinating with the other cpu (usually Wait For Interrupt, or
WFI), and one or more "coupled" power states that affect blocks
shared between the cpus (L2 cache, interrupt controller, and
sometimes the whole SoC). Entering a coupled power state must
be tightly controlled on both cpus.
The easiest solution to implementing coupled cpu power states is
to hotplug all but one cpu whenever possible, usually using a
cpufreq governor that looks at cpu load to determine when to
enable the secondary cpus. This causes problems, as hotplug is an
expensive operation, so the number of hotplug transitions must be
minimized, leading to very slow response to loads, often on the
order of seconds.
This file implements an alternative solution, where each cpu will
wait in the WFI state until all cpus are ready to enter a coupled
state, at which point the coupled state function will be called
on all cpus at approximately the same time.
Once all cpus are ready to enter idle, they are woken by an smp
cross call. At this point, there is a chance that one of the
cpus will find work to do, and choose not to enter idle. A
final pass is needed to guarantee that all cpus will call the
power state enter function at the same time. During this pass,
each cpu will increment the ready counter, and continue once the
ready counter matches the number of online coupled cpus. If any
cpu exits idle, the other cpus will decrement their counter and
retry.
To use coupled cpuidle states, a cpuidle driver must:
Set struct cpuidle_device.coupled_cpus to the mask of all
coupled cpus, usually the same as cpu_possible_mask if all cpus
are part of the same cluster. The coupled_cpus mask must be
set in the struct cpuidle_device for each cpu.
Set struct cpuidle_device.safe_state to a state that is not a
coupled state. This is usually WFI.
Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
state that affects multiple cpus.
Provide a struct cpuidle_state.enter function for each state
that affects multiple cpus. This function is guaranteed to be
called on all cpus at approximately the same time. The driver
should ensure that the cpus all abort together if any cpu tries
to abort once the function is called.
Cc: Len Brown <len.brown@intel.com>
Cc: Amit Kucheria <amit.kucheria@linaro.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Trinabh Gupta <g.trinabh@gmail.com>
Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Colin Cross <ccross@android.com>
---
drivers/cpuidle/Kconfig | 3 +
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/coupled.c | 571 +++++++++++++++++++++++++++++++++++++++++++++
drivers/cpuidle/cpuidle.c | 15 ++-
drivers/cpuidle/cpuidle.h | 30 +++
include/linux/cpuidle.h | 7 +
6 files changed, 626 insertions(+), 1 deletions(-)
create mode 100644 drivers/cpuidle/coupled.c
v2:
* removed the coupled lock, replacing it with atomic counters
* added a check for outstanding pokes before beginning the
final transition to avoid extra wakeups
* made the cpuidle_coupled struct completely private
* fixed kerneldoc comment formatting
v3:
* fixed decrement in cpuidle_coupled_cpu_set_alive
* added kerneldoc annotation to the description
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 78a666d..a76b689 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -18,3 +18,6 @@ config CPU_IDLE_GOV_MENU
bool
depends on CPU_IDLE && NO_HZ
default y
+
+config ARCH_NEEDS_CPU_IDLE_COUPLED
+ def_bool n
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 5634f88..38c8f69 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -3,3 +3,4 @@
#
obj-y += cpuidle.o driver.o governor.o sysfs.o governors/
+obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
new file mode 100644
index 0000000..d097826
--- /dev/null
+++ b/drivers/cpuidle/coupled.c
@@ -0,0 +1,571 @@
+/*
+ * coupled.c - helper functions to enter the same idle state on multiple cpus
+ *
+ * Copyright (c) 2011 Google, Inc.
+ *
+ * Author: Colin Cross <ccross@android.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/cpu.h>
+#include <linux/cpuidle.h>
+#include <linux/mutex.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+#include "cpuidle.h"
+
+/**
+ * DOC: Coupled cpuidle states
+ *
+ * On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
+ * cpus cannot be independently powered down, either due to
+ * sequencing restrictions (on Tegra 2, cpu 0 must be the last to
+ * power down), or due to HW bugs (on OMAP4460, a cpu powering up
+ * will corrupt the gic state unless the other cpu runs a work
+ * around). Each cpu has a power state that it can enter without
+ * coordinating with the other cpu (usually Wait For Interrupt, or
+ * WFI), and one or more "coupled" power states that affect blocks
+ * shared between the cpus (L2 cache, interrupt controller, and
+ * sometimes the whole SoC). Entering a coupled power state must
+ * be tightly controlled on both cpus.
+ *
+ * The easiest solution to implementing coupled cpu power states is
+ * to hotplug all but one cpu whenever possible, usually using a
+ * cpufreq governor that looks at cpu load to determine when to
+ * enable the secondary cpus. This causes problems, as hotplug is an
+ * expensive operation, so the number of hotplug transitions must be
+ * minimized, leading to very slow response to loads, often on the
+ * order of seconds.
+ *
+ * This file implements an alternative solution, where each cpu will
+ * wait in the WFI state until all cpus are ready to enter a coupled
+ * state, at which point the coupled state function will be called
+ * on all cpus at approximately the same time.
+ *
+ * Once all cpus are ready to enter idle, they are woken by an smp
+ * cross call. At this point, there is a chance that one of the
+ * cpus will find work to do, and choose not to enter idle. A
+ * final pass is needed to guarantee that all cpus will call the
+ * power state enter function at the same time. During this pass,
+ * each cpu will increment the ready counter, and continue once the
+ * ready counter matches the number of online coupled cpus. If any
+ * cpu exits idle, the other cpus will decrement their counter and
+ * retry.
+ *
+ * requested_state stores the deepest coupled idle state each cpu
+ * is ready for. It is assumed that the states are indexed from
+ * shallowest (highest power, lowest exit latency) to deepest
+ * (lowest power, highest exit latency). The requested_state
+ * variable is not locked. It is only written from the cpu that
+ * it stores (or by the on/offlining cpu if that cpu is offline),
+ * and only read after all the cpus are ready for the coupled idle
+ * state are are no longer updating it.
+ *
+ * Three atomic counters are used. alive_count tracks the number
+ * of cpus in the coupled set that are currently or soon will be
+ * online. waiting_count tracks the number of cpus that are in
+ * the waiting loop, in the ready loop, or in the coupled idle state.
+ * ready_count tracks the number of cpus that are in the ready loop
+ * or in the coupled idle state.
+ *
+ * To use coupled cpuidle states, a cpuidle driver must:
+ *
+ * Set struct cpuidle_device.coupled_cpus to the mask of all
+ * coupled cpus, usually the same as cpu_possible_mask if all cpus
+ * are part of the same cluster. The coupled_cpus mask must be
+ * set in the struct cpuidle_device for each cpu.
+ *
+ * Set struct cpuidle_device.safe_state to a state that is not a
+ * coupled state. This is usually WFI.
+ *
+ * Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
+ * state that affects multiple cpus.
+ *
+ * Provide a struct cpuidle_state.enter function for each state
+ * that affects multiple cpus. This function is guaranteed to be
+ * called on all cpus at approximately the same time. The driver
+ * should ensure that the cpus all abort together if any cpu tries
+ * to abort once the function is called. The function should return
+ * with interrupts still disabled.
+ */
+
+/**
+ * struct cpuidle_coupled - data for set of cpus that share a coupled idle state
+ * @coupled_cpus: mask of cpus that are part of the coupled set
+ * @requested_state: array of requested states for cpus in the coupled set
+ * @ready_count: count of cpus that are ready for the final idle transition
+ * @waiting_count: count of cpus that are waiting for all other cpus to be idle
+ * @alive_count: count of cpus that are online or soon will be
+ * @refcnt: reference count of cpuidle devices that are using this struct
+ */
+struct cpuidle_coupled {
+ cpumask_t coupled_cpus;
+ int requested_state[NR_CPUS];
+ atomic_t ready_count;
+ atomic_t waiting_count;
+ atomic_t alive_count;
+ int refcnt;
+};
+
+#define CPUIDLE_COUPLED_NOT_IDLE (-1)
+#define CPUIDLE_COUPLED_DEAD (-2)
+
+static DEFINE_MUTEX(cpuidle_coupled_lock);
+static DEFINE_PER_CPU(struct call_single_data, cpuidle_coupled_poke_cb);
+
+/*
+ * The cpuidle_coupled_poked_mask masked is used to avoid calling
+ * __smp_call_function_single with the per cpu call_single_data struct already
+ * in use. This prevents a deadlock where two cpus are waiting for each others
+ * call_single_data struct to be available
+ */
+static cpumask_t cpuidle_coupled_poked_mask;
+
+/**
+ * cpuidle_state_is_coupled - check if a state is part of a coupled set
+ * @dev: struct cpuidle_device for the current cpu
+ * @drv: struct cpuidle_driver for the platform
+ * @state: index of the target state in drv->states
+ *
+ * Returns true if the target state is coupled with cpus besides this one
+ */
+bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int state)
+{
+ return drv->states[state].flags & CPUIDLE_FLAG_COUPLED;
+}
+
+/**
+ * cpuidle_coupled_cpus_waiting - check if all cpus in a coupled set are waiting
+ * @coupled: the struct coupled that contains the current cpu
+ *
+ * Returns true if all cpus coupled to this target state are in the wait loop
+ */
+static inline bool cpuidle_coupled_cpus_waiting(struct cpuidle_coupled *coupled)
+{
+ int alive;
+ int waiting;
+
+ /*
+ * Read alive before reading waiting so a booting cpu is not treated as
+ * idle
+ */
+ alive = atomic_read(&coupled->alive_count);
+ smp_rmb();
+ waiting = atomic_read(&coupled->waiting_count);
+
+ return (waiting == alive);
+}
+
+/**
+ * cpuidle_coupled_get_state - determine the deepest idle state
+ * @dev: struct cpuidle_device for this cpu
+ * @coupled: the struct coupled that contains the current cpu
+ *
+ * Returns the deepest idle state that all coupled cpus can enter
+ */
+static inline int cpuidle_coupled_get_state(struct cpuidle_device *dev,
+ struct cpuidle_coupled *coupled)
+{
+ int i;
+ int state = INT_MAX;
+
+ for_each_cpu_mask(i, coupled->coupled_cpus)
+ if (coupled->requested_state[i] != CPUIDLE_COUPLED_DEAD &&
+ coupled->requested_state[i] < state)
+ state = coupled->requested_state[i];
+
+ BUG_ON(state >= dev->state_count || state < 0);
+
+ return state;
+}
+
+static void cpuidle_coupled_poked(void *info)
+{
+ int cpu = (unsigned long)info;
+ cpumask_clear_cpu(cpu, &cpuidle_coupled_poked_mask);
+}
+
+/**
+ * cpuidle_coupled_poke - wake up a cpu that may be waiting
+ * @cpu: target cpu
+ *
+ * Ensures that the target cpu exits it's waiting idle state (if it is in it)
+ * and will see updates to waiting_count before it re-enters it's waiting idle
+ * state.
+ *
+ * If cpuidle_coupled_poked_mask is already set for the target cpu, that cpu
+ * either has or will soon have a pending IPI that will wake it out of idle,
+ * or it is currently processing the IPI and is not in idle.
+ */
+static void cpuidle_coupled_poke(int cpu)
+{
+ struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
+
+ if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
+ __smp_call_function_single(cpu, csd, 0);
+}
+
+/**
+ * cpuidle_coupled_poke_others - wake up all other cpus that may be waiting
+ * @dev: struct cpuidle_device for this cpu
+ * @coupled: the struct coupled that contains the current cpu
+ *
+ * Calls cpuidle_coupled_poke on all other online cpus.
+ */
+static void cpuidle_coupled_poke_others(struct cpuidle_device *dev,
+ struct cpuidle_coupled *coupled)
+{
+ int cpu;
+
+ for_each_cpu_mask(cpu, coupled->coupled_cpus)
+ if (cpu != dev->cpu && cpu_online(cpu))
+ cpuidle_coupled_poke(cpu);
+}
+
+/**
+ * cpuidle_coupled_set_waiting - mark this cpu as in the wait loop
+ * @dev: struct cpuidle_device for this cpu
+ * @coupled: the struct coupled that contains the current cpu
+ * @next_state: the index in drv->states of the requested state for this cpu
+ *
+ * Updates the requested idle state for the specified cpuidle device,
+ * poking all coupled cpus out of idle if necessary to let them see the new
+ * state.
+ *
+ * Provides memory ordering around waiting_count.
+ */
+static void cpuidle_coupled_set_waiting(struct cpuidle_device *dev,
+ struct cpuidle_coupled *coupled, int next_state)
+{
+ int alive;
+
+ BUG_ON(coupled->requested_state[dev->cpu] >= 0);
+
+ coupled->requested_state[dev->cpu] = next_state;
+
+ /*
+ * If this is the last cpu to enter the waiting state, poke
+ * all the other cpus out of their waiting state so they can
+ * enter a deeper state. This can race with one of the cpus
+ * exiting the waiting state due to an interrupt and
+ * decrementing waiting_count, see comment below.
+ */
+ alive = atomic_read(&coupled->alive_count);
+ if (atomic_inc_return(&coupled->waiting_count) == alive)
+ cpuidle_coupled_poke_others(dev, coupled);
+}
+
+/**
+ * cpuidle_coupled_set_not_waiting - mark this cpu as leaving the wait loop
+ * @dev: struct cpuidle_device for this cpu
+ * @coupled: the struct coupled that contains the current cpu
+ *
+ * Removes the requested idle state for the specified cpuidle device.
+ *
+ * Provides memory ordering around waiting_count.
+ */
+static void cpuidle_coupled_set_not_waiting(struct cpuidle_device *dev,
+ struct cpuidle_coupled *coupled)
+{
+ BUG_ON(coupled->requested_state[dev->cpu] < 0);
+
+ /*
+ * Decrementing waiting_count can race with incrementing it in
+ * cpuidle_coupled_set_waiting, but that's OK. Worst case, some
+ * cpus will increment ready_count and then spin until they
+ * notice that this cpu has cleared it's requested_state.
+ */
+
+ smp_mb__before_atomic_dec();
+ atomic_dec(&coupled->waiting_count);
+ smp_mb__after_atomic_dec();
+
+ coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
+}
+
+/**
+ * cpuidle_enter_state_coupled - attempt to enter a state with coupled cpus
+ * @dev: struct cpuidle_device for the current cpu
+ * @drv: struct cpuidle_driver for the platform
+ * @next_state: index of the requested state in drv->states
+ *
+ * Coordinate with coupled cpus to enter the target state. This is a two
+ * stage process. In the first stage, the cpus are operating independently,
+ * and may call into cpuidle_enter_state_coupled at completely different times.
+ * To save as much power as possible, the first cpus to call this function will
+ * go to an intermediate state (the cpuidle_device's safe state), and wait for
+ * all the other cpus to call this function. Once all coupled cpus are idle,
+ * the second stage will start. Each coupled cpu will spin until all cpus have
+ * guaranteed that they will call the target_state.
+ */
+int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int next_state)
+{
+ int entered_state = -1;
+ struct cpuidle_coupled *coupled = dev->coupled;
+ int alive;
+
+ if (!coupled)
+ return -EINVAL;
+
+ BUG_ON(atomic_read(&coupled->ready_count));
+ cpuidle_coupled_set_waiting(dev, coupled, next_state);
+
+retry:
+ /*
+ * Wait for all coupled cpus to be idle, using the deepest state
+ * allowed for a single cpu.
+ */
+ while (!need_resched() && !cpuidle_coupled_cpus_waiting(coupled)) {
+ entered_state = cpuidle_enter_state(dev, drv,
+ dev->safe_state_index);
+
+ local_irq_enable();
+ while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
+ cpu_relax();
+ local_irq_disable();
+ }
+
+ /* give a chance to process any remaining pokes */
+ local_irq_enable();
+ while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
+ cpu_relax();
+ local_irq_disable();
+
+ if (need_resched()) {
+ cpuidle_coupled_set_not_waiting(dev, coupled);
+ goto out;
+ }
+
+ /*
+ * All coupled cpus are probably idle. There is a small chance that
+ * one of the other cpus just became active. Increment a counter when
+ * ready, and spin until all coupled cpus have incremented the counter.
+ * Once a cpu has incremented the counter, it cannot abort idle and must
+ * spin until either the count has hit alive_count, or another cpu
+ * leaves idle.
+ */
+
+ smp_mb__before_atomic_inc();
+ atomic_inc(&coupled->ready_count);
+ smp_mb__after_atomic_inc();
+ /* alive_count can't change while ready_count > 0 */
+ alive = atomic_read(&coupled->alive_count);
+ while (atomic_read(&coupled->ready_count) != alive) {
+ /* Check if any other cpus bailed out of idle. */
+ if (!cpuidle_coupled_cpus_waiting(coupled)) {
+ atomic_dec(&coupled->ready_count);
+ smp_mb__after_atomic_dec();
+ goto retry;
+ }
+
+ cpu_relax();
+ }
+
+ /* all cpus have acked the coupled state */
+ smp_rmb();
+
+ next_state = cpuidle_coupled_get_state(dev, coupled);
+
+ entered_state = cpuidle_enter_state(dev, drv, next_state);
+
+ cpuidle_coupled_set_not_waiting(dev, coupled);
+ atomic_dec(&coupled->ready_count);
+ smp_mb__after_atomic_dec();
+
+out:
+ /*
+ * Normal cpuidle states are expected to return with irqs enabled.
+ * That leads to an inefficiency where a cpu receiving an interrupt
+ * that brings it out of idle will process that interrupt before
+ * exiting the idle enter function and decrementing ready_count. All
+ * other cpus will need to spin waiting for the cpu that is processing
+ * the interrupt. If the driver returns with interrupts disabled,
+ * all other cpus will loop back into the safe idle state instead of
+ * spinning, saving power.
+ *
+ * Calling local_irq_enable here allows coupled states to return with
+ * interrupts disabled, but won't cause problems for drivers that
+ * exit with interrupts enabled.
+ */
+ local_irq_enable();
+
+ /*
+ * Wait until all coupled cpus have exited idle. There is no risk that
+ * a cpu exits and re-enters the ready state because this cpu has
+ * already decremented its waiting_count.
+ */
+ while (atomic_read(&coupled->ready_count) != 0)
+ cpu_relax();
+
+ smp_rmb();
+
+ return entered_state;
+}
+
+/**
+ * cpuidle_coupled_register_device - register a coupled cpuidle device
+ * @dev: struct cpuidle_device for the current cpu
+ *
+ * Called from cpuidle_register_device to handle coupled idle init. Finds the
+ * cpuidle_coupled struct for this set of coupled cpus, or creates one if none
+ * exists yet.
+ */
+int cpuidle_coupled_register_device(struct cpuidle_device *dev)
+{
+ int cpu;
+ struct cpuidle_device *other_dev;
+ struct call_single_data *csd;
+ struct cpuidle_coupled *coupled;
+
+ if (cpumask_empty(&dev->coupled_cpus))
+ return 0;
+
+ for_each_cpu_mask(cpu, dev->coupled_cpus) {
+ other_dev = per_cpu(cpuidle_devices, cpu);
+ if (other_dev && other_dev->coupled) {
+ coupled = other_dev->coupled;
+ goto have_coupled;
+ }
+ }
+
+ /* No existing coupled info found, create a new one */
+ coupled = kzalloc(sizeof(struct cpuidle_coupled), GFP_KERNEL);
+ if (!coupled)
+ return -ENOMEM;
+
+ coupled->coupled_cpus = dev->coupled_cpus;
+ for_each_cpu_mask(cpu, coupled->coupled_cpus)
+ coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_DEAD;
+
+have_coupled:
+ dev->coupled = coupled;
+ BUG_ON(!cpumask_equal(&dev->coupled_cpus, &coupled->coupled_cpus));
+
+ if (cpu_online(dev->cpu)) {
+ coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
+ atomic_inc(&coupled->alive_count);
+ }
+
+ coupled->refcnt++;
+
+ csd = &per_cpu(cpuidle_coupled_poke_cb, dev->cpu);
+ csd->func = cpuidle_coupled_poked;
+ csd->info = (void *)(unsigned long)dev->cpu;
+
+ return 0;
+}
+
+/**
+ * cpuidle_coupled_unregister_device - unregister a coupled cpuidle device
+ * @dev: struct cpuidle_device for the current cpu
+ *
+ * Called from cpuidle_unregister_device to tear down coupled idle. Removes the
+ * cpu from the coupled idle set, and frees the cpuidle_coupled_info struct if
+ * this was the last cpu in the set.
+ */
+void cpuidle_coupled_unregister_device(struct cpuidle_device *dev)
+{
+ struct cpuidle_coupled *coupled = dev->coupled;
+
+ if (cpumask_empty(&dev->coupled_cpus))
+ return;
+
+ if (--coupled->refcnt)
+ kfree(coupled);
+ dev->coupled = NULL;
+}
+
+/**
+ * cpuidle_coupled_cpu_set_alive - adjust alive_count during hotplug transitions
+ * @cpu: target cpu number
+ * @alive: whether the target cpu is going up or down
+ *
+ * Run on the cpu that is bringing up the target cpu, before the target cpu
+ * has been booted, or after the target cpu is completely dead.
+ */
+static void cpuidle_coupled_cpu_set_alive(int cpu, bool alive)
+{
+ struct cpuidle_device *dev;
+ struct cpuidle_coupled *coupled;
+
+ mutex_lock(&cpuidle_lock);
+
+ dev = per_cpu(cpuidle_devices, cpu);
+ if (!dev->coupled)
+ goto out;
+
+ coupled = dev->coupled;
+
+ /*
+ * waiting_count must be at least 1 less than alive_count, because
+ * this cpu is not waiting. Spin until all cpus have noticed this cpu
+ * is not idle and exited the ready loop before changing alive_count.
+ */
+ while (atomic_read(&coupled->ready_count))
+ cpu_relax();
+
+ if (alive) {
+ smp_mb__before_atomic_inc();
+ atomic_inc(&coupled->alive_count);
+ smp_mb__after_atomic_inc();
+ coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
+ } else {
+ smp_mb__before_atomic_dec();
+ atomic_dec(&coupled->alive_count);
+ smp_mb__after_atomic_dec();
+ coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_DEAD;
+ }
+
+out:
+ mutex_unlock(&cpuidle_lock);
+}
+
+/**
+ * cpuidle_coupled_cpu_notify - notifier called during hotplug transitions
+ * @nb: notifier block
+ * @action: hotplug transition
+ * @hcpu: target cpu number
+ *
+ * Called when a cpu is brought on or offline using hotplug. Updates the
+ * coupled cpu set appropriately
+ */
+static int cpuidle_coupled_cpu_notify(struct notifier_block *nb,
+ unsigned long action, void *hcpu)
+{
+ int cpu = (unsigned long)hcpu;
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_DEAD:
+ case CPU_UP_CANCELED:
+ cpuidle_coupled_cpu_set_alive(cpu, false);
+ break;
+ case CPU_UP_PREPARE:
+ cpuidle_coupled_cpu_set_alive(cpu, true);
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block cpuidle_coupled_cpu_notifier = {
+ .notifier_call = cpuidle_coupled_cpu_notify,
+};
+
+static int __init cpuidle_coupled_init(void)
+{
+ return register_cpu_notifier(&cpuidle_coupled_cpu_notifier);
+}
+core_initcall(cpuidle_coupled_init);
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 4540672..e81cfda 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -171,7 +171,11 @@ int cpuidle_idle_call(void)
trace_power_start_rcuidle(POWER_CSTATE, next_state, dev->cpu);
trace_cpu_idle_rcuidle(next_state, dev->cpu);
- entered_state = cpuidle_enter_state(dev, drv, next_state);
+ if (cpuidle_state_is_coupled(dev, drv, next_state))
+ entered_state = cpuidle_enter_state_coupled(dev, drv,
+ next_state);
+ else
+ entered_state = cpuidle_enter_state(dev, drv, next_state);
trace_power_end_rcuidle(dev->cpu);
trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
@@ -407,9 +411,16 @@ static int __cpuidle_register_device(struct cpuidle_device *dev)
if (ret)
goto err_sysfs;
+ ret = cpuidle_coupled_register_device(dev);
+ if (ret)
+ goto err_coupled;
+
dev->registered = 1;
return 0;
+err_coupled:
+ cpuidle_remove_sysfs(cpu_dev);
+ wait_for_completion(&dev->kobj_unregister);
err_sysfs:
list_del(&dev->device_list);
per_cpu(cpuidle_devices, dev->cpu) = NULL;
@@ -464,6 +475,8 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
wait_for_completion(&dev->kobj_unregister);
per_cpu(cpuidle_devices, dev->cpu) = NULL;
+ cpuidle_coupled_unregister_device(dev);
+
cpuidle_resume_and_unlock();
module_put(cpuidle_driver->owner);
diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
index d8a3ccc..76e7f69 100644
--- a/drivers/cpuidle/cpuidle.h
+++ b/drivers/cpuidle/cpuidle.h
@@ -32,4 +32,34 @@ extern int cpuidle_enter_state(struct cpuidle_device *dev,
extern int cpuidle_add_sysfs(struct device *dev);
extern void cpuidle_remove_sysfs(struct device *dev);
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
+bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int state);
+int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int next_state);
+int cpuidle_coupled_register_device(struct cpuidle_device *dev);
+void cpuidle_coupled_unregister_device(struct cpuidle_device *dev);
+#else
+static inline bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int state)
+{
+ return false;
+}
+
+static inline int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int next_state)
+{
+ return -1;
+}
+
+static inline int cpuidle_coupled_register_device(struct cpuidle_device *dev)
+{
+ return 0;
+}
+
+static inline void cpuidle_coupled_unregister_device(struct cpuidle_device *dev)
+{
+}
+#endif
+
#endif /* __DRIVER_CPUIDLE_H */
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 6c26a3d..6038448 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -57,6 +57,7 @@ struct cpuidle_state {
/* Idle State Flags */
#define CPUIDLE_FLAG_TIME_VALID (0x01) /* is residency time measurable? */
+#define CPUIDLE_FLAG_COUPLED (0x02) /* state applies to multiple cpus */
#define CPUIDLE_DRIVER_FLAGS_MASK (0xFFFF0000)
@@ -100,6 +101,12 @@ struct cpuidle_device {
struct list_head device_list;
struct kobject kobj;
struct completion kobj_unregister;
+
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
+ int safe_state_index;
+ cpumask_t coupled_cpus;
+ struct cpuidle_coupled *coupled;
+#endif
};
DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
--
1.7.7.3
^ permalink raw reply related
* [PATCHv3 2/5] cpuidle: fix error handling in __cpuidle_register_device
From: Colin Cross @ 2012-04-30 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, Amit Kucheria, Colin Cross, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1335816551-27756-1-git-send-email-ccross@android.com>
Fix the error handling in __cpuidle_register_device to include
the missing list_del. Move it to a label, which will simplify
the error handling when coupled states are added.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Colin Cross <ccross@android.com>
---
drivers/cpuidle/cpuidle.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 3e3e3e4..4540672 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -403,13 +403,18 @@ static int __cpuidle_register_device(struct cpuidle_device *dev)
per_cpu(cpuidle_devices, dev->cpu) = dev;
list_add(&dev->device_list, &cpuidle_detected_devices);
- if ((ret = cpuidle_add_sysfs(cpu_dev))) {
- module_put(cpuidle_driver->owner);
- return ret;
- }
+ ret = cpuidle_add_sysfs(cpu_dev);
+ if (ret)
+ goto err_sysfs;
dev->registered = 1;
return 0;
+
+err_sysfs:
+ list_del(&dev->device_list);
+ per_cpu(cpuidle_devices, dev->cpu) = NULL;
+ module_put(cpuidle_driver->owner);
+ return ret;
}
/**
--
1.7.7.3
^ permalink raw reply related
* [PATCHv3 1/5] cpuidle: refactor out cpuidle_enter_state
From: Colin Cross @ 2012-04-30 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, linux-pm, Kevin Hilman, Len Brown,
Trinabh Gupta, Arjan van de Ven, Deepthi Dharwar,
Greg Kroah-Hartman, Kay Sievers, Santosh Shilimkar,
Daniel Lezcano, Amit Kucheria, Lorenzo Pieralisi, Arnd Bergmann,
Russell King, Colin Cross
In-Reply-To: <1335816551-27756-1-git-send-email-ccross@android.com>
Split the code to enter a state and update the stats into a helper
function, cpuidle_enter_state, and export it. This function will
be called by the coupled state code to handle entering the safe
state and the final coupled state.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Colin Cross <ccross@android.com>
---
drivers/cpuidle/cpuidle.c | 42 +++++++++++++++++++++++++++++-------------
drivers/cpuidle/cpuidle.h | 2 ++
2 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 2f0083a..3e3e3e4 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -103,6 +103,34 @@ int cpuidle_play_dead(void)
}
/**
+ * cpuidle_enter_state - enter the state and update stats
+ * @dev: cpuidle device for this cpu
+ * @drv: cpuidle driver for this cpu
+ * @next_state: index into drv->states of the state to enter
+ */
+int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
+ int next_state)
+{
+ int entered_state;
+
+ entered_state = cpuidle_enter_ops(dev, drv, next_state);
+
+ if (entered_state >= 0) {
+ /* Update cpuidle counters */
+ /* This can be moved to within driver enter routine
+ * but that results in multiple copies of same code.
+ */
+ dev->states_usage[entered_state].time +=
+ (unsigned long long)dev->last_residency;
+ dev->states_usage[entered_state].usage++;
+ } else {
+ dev->last_residency = 0;
+ }
+
+ return entered_state;
+}
+
+/**
* cpuidle_idle_call - the main idle loop
*
* NOTE: no locks or semaphores should be used here
@@ -143,23 +171,11 @@ int cpuidle_idle_call(void)
trace_power_start_rcuidle(POWER_CSTATE, next_state, dev->cpu);
trace_cpu_idle_rcuidle(next_state, dev->cpu);
- entered_state = cpuidle_enter_ops(dev, drv, next_state);
+ entered_state = cpuidle_enter_state(dev, drv, next_state);
trace_power_end_rcuidle(dev->cpu);
trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
- if (entered_state >= 0) {
- /* Update cpuidle counters */
- /* This can be moved to within driver enter routine
- * but that results in multiple copies of same code.
- */
- dev->states_usage[entered_state].time +=
- (unsigned long long)dev->last_residency;
- dev->states_usage[entered_state].usage++;
- } else {
- dev->last_residency = 0;
- }
-
/* give the governor an opportunity to reflect on the outcome */
if (cpuidle_curr_governor->reflect)
cpuidle_curr_governor->reflect(dev, entered_state);
diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
index 7db1866..d8a3ccc 100644
--- a/drivers/cpuidle/cpuidle.h
+++ b/drivers/cpuidle/cpuidle.h
@@ -14,6 +14,8 @@
extern struct mutex cpuidle_lock;
extern spinlock_t cpuidle_driver_lock;
extern int cpuidle_disabled(void);
+extern int cpuidle_enter_state(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int next_state);
/* idle loop */
extern void cpuidle_install_idle_handler(void);
--
1.7.7.3
^ permalink raw reply related
* [PATCHv3 0/5] coupled cpuidle state support
From: Colin Cross @ 2012-04-30 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, linux-pm, Kevin Hilman, Len Brown,
Trinabh Gupta, Arjan van de Ven, Deepthi Dharwar,
Greg Kroah-Hartman, Kay Sievers, Santosh Shilimkar,
Daniel Lezcano, Amit Kucheria, Lorenzo Pieralisi, Arnd Bergmann,
Russell King, Colin Cross
On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
cpus cannot be independently powered down, either due to
sequencing restrictions (on Tegra 2, cpu 0 must be the last to
power down), or due to HW bugs (on OMAP4460, a cpu powering up
will corrupt the gic state unless the other cpu runs a work
around). Each cpu has a power state that it can enter without
coordinating with the other cpu (usually Wait For Interrupt, or
WFI), and one or more "coupled" power states that affect blocks
shared between the cpus (L2 cache, interrupt controller, and
sometimes the whole SoC). Entering a coupled power state must
be tightly controlled on both cpus.
The easiest solution to implementing coupled cpu power states is
to hotplug all but one cpu whenever possible, usually using a
cpufreq governor that looks at cpu load to determine when to
enable the secondary cpus. This causes problems, as hotplug is an
expensive operation, so the number of hotplug transitions must be
minimized, leading to very slow response to loads, often on the
order of seconds.
This patch series implements an alternative solution, where each
cpu will wait in the WFI state until all cpus are ready to enter
a coupled state, at which point the coupled state function will
be called on all cpus at approximately the same time.
Once all cpus are ready to enter idle, they are woken by an smp
cross call. At this point, there is a chance that one of the
cpus will find work to do, and choose not to enter suspend. A
final pass is needed to guarantee that all cpus will call the
power state enter function at the same time. During this pass,
each cpu will increment the ready counter, and continue once the
ready counter matches the number of online coupled cpus. If any
cpu exits idle, the other cpus will decrement their counter and
retry.
To use coupled cpuidle states, a cpuidle driver must:
Set struct cpuidle_device.coupled_cpus to the mask of all
coupled cpus, usually the same as cpu_possible_mask if all cpus
are part of the same cluster. The coupled_cpus mask must be
set in the struct cpuidle_device for each cpu.
Set struct cpuidle_device.safe_state to a state that is not a
coupled state. This is usually WFI.
Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
state that affects multiple cpus.
Provide a struct cpuidle_state.enter function for each state
that affects multiple cpus. This function is guaranteed to be
called on all cpus at approximately the same time. The driver
should ensure that the cpus all abort together if any cpu tries
to abort once the function is called.
This series has been tested by implementing a test cpuidle state
that uses the parallel barrier helper function to verify that
all cpus call the function at the same time.
This patch set has a few disadvantages over the hotplug governor,
but I think they are all fairly minor:
* Worst-case interrupt latency can be increased. If one cpu
receives an interrupt while the other is spinning in the
ready_count loop, the second cpu will be stuck with
interrupts off until the first cpu finished processing
its interrupt and exits idle. This will increase the worst
case interrupt latency by the worst-case interrupt processing
time, but should be very rare.
* Interrupts are processed while still inside pm_idle.
Normally, interrupts are only processed at the very end of
pm_idle, just before it returns to the idle loop. Coupled
states requires processing interrupts inside
cpuidle_enter_state_coupled in order to distinguish between
the smp_cross_call from another cpu that is now idle and an
interrupt that should cause idle to exit.
I don't see a way to fix this without either being able to
read the next pending irq from the interrupt chip, or
querying the irq core for which interrupts were processed.
* Since interrupts are processed inside cpuidle, the next
timer event could change. The new timer event will be
handled correctly, but the idle state decision made by
the governor will be out of date, and will not be revisited.
The governor select function could be called again every time,
but this could lead to a lot of work being done by an idle
cpu if the other cpu was mostly busy.
v2:
* removed the coupled lock, replacing it with atomic counters
* added a check for outstanding pokes before beginning the
final transition to avoid extra wakeups
* made the cpuidle_coupled struct completely private
* fixed kerneldoc comment formatting
* added a patch with a helper function for resynchronizing
cpus after aborting idle
* added a patch (not for merging) to add trace events for
verification and performance testing
v3:
* rebased on v3.4-rc4 by Santosh
* fixed decrement in cpuidle_coupled_cpu_set_alive
* updated tracing patch to remove unnecessary debugging so
it can be merged
* made tracing _rcuidle
This series has been tested and reviewed by Santosh and Kevin
for OMAP4, which has a cpuidle series ready for 3.5, and Tegra
and Exynos5 patches are in progress. I think this is ready to
go in. Lean, are you maintaining a cpuidle tree for linux-next?
If not, I can publish a tree for linux-next, or this could go in
through Arnd's tree.
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Mark Brown @ 2012-04-30 9:54 UTC (permalink / raw)
To: Kevin Hilman
Cc: J, KEERTHY, linux-kernel, linux-pm, linux-omap, j-pihet,
linux-arm-kernel
In-Reply-To: <87397o3n4y.fsf@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 2023 bytes --]
On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> > But presumably these things should integrate somehow - for example,
> > should devfreq and cpufreq be providing inputs into what AVS is doing,
> > and if so how?
> The way it is currently designed, cpufreq/devfreq/regulator layers don't
> need to know about AVS.
Yes, and that was a part of my concern, but see below.
> The higher-level layers only know about the "nominal" voltage. AVS
> hardware does automatic, adaptive, micro-adjustments around that nominal
> voltage, and these micro-adjustments are managed by the AVS hardware
> sending commands to the PMIC. (specifically, on OMAP, the AVS sensors
> provide inputs to the voltage processor (VP) which provide inputs to the
> voltage controller (VC) which sends commands to the PMIC[1].)
Right, that's what I'd understood it to be.
> The driver proposed here is primarily for initializing the various
> parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
> adjustments are done in hardware by VC/VP.
It's not just a driver, though - it's also creating this power/avs
thing, though now I look at the code rather than just its shape there's
not actually an abstraction being added here, it's mostly just straight
code motion of the arch/arm code that's there already. The changelog
and the shape of the code make it sound like this is intended to be
somewhat generic when really it's providing some OMAP specific tuning
for the device which is much less of a concern.
I guess for now it's probably OK to just clarify in the documentation
and say that whoever adds the second driver has to work on making this
generic :)
This does also sound rather like it's in a similar area to the current
management work which Durgadoss R (CCed) was working on, though with a
slightly different application and in the OMAP case it's pretty much all
hidden in the external processor.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: J, KEERTHY @ 2012-04-30 4:25 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet
In-Reply-To: <87397o3n4y.fsf@ti.com>
On Sat, Apr 28, 2012 at 2:31 AM, Kevin Hilman <khilman@ti.com> wrote:
> Hi Mark,
>
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>
>> On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
>>
>>> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
>>> pre defined Operating Performance Points or the OPPs. Every OPP being
>>> a voltage/frequency pair. Smartreflex is a different
>>> power management technique.
>>
>> But presumably these things should integrate somehow - for example,
>> should devfreq and cpufreq be providing inputs into what AVS is doing,
>> and if so how?
>
> The way it is currently designed, cpufreq/devfreq/regulator layers don't
> need to know about AVS.
>
> The higher-level layers only know about the "nominal" voltage. AVS
> hardware does automatic, adaptive, micro-adjustments around that nominal
> voltage, and these micro-adjustments are managed by the AVS hardware
> sending commands to the PMIC. (specifically, on OMAP, the AVS sensors
> provide inputs to the voltage processor (VP) which provide inputs to the
> voltage controller (VC) which sends commands to the PMIC[1].)
>
> The driver proposed here is primarily for initializing the various
> parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
> adjustments are done in hardware by VC/VP.
>
> The only thing the higher-level layers might potentially need to do to
> enable/disable AVS around transitions (e.g. when changing OPP, AVS is
> disabled before changing OPP and only re-enabled when the new nominal
> voltage has been acheived.)
>
> On OMAP, we handle this inside the OMAP-specific voltage layer which is
> called by the regulator framework, so even the regulators do not need
> any knowledge of AVS.
>
> Kevin
>
> [1] Figure 3-76 in OMAP4430 ES2.1 Public TRM vAD provides a
> detailed diagram:
> http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAD.zip
Thanks for the detailed answer Kevin.
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Kevin Hilman @ 2012-04-27 21:01 UTC (permalink / raw)
To: Mark Brown
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet
In-Reply-To: <20120427175657.GP18260@opensource.wolfsonmicro.com>
Hi Mark,
Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
>
>> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
>> pre defined Operating Performance Points or the OPPs. Every OPP being
>> a voltage/frequency pair. Smartreflex is a different
>> power management technique.
>
> But presumably these things should integrate somehow - for example,
> should devfreq and cpufreq be providing inputs into what AVS is doing,
> and if so how?
The way it is currently designed, cpufreq/devfreq/regulator layers don't
need to know about AVS.
The higher-level layers only know about the "nominal" voltage. AVS
hardware does automatic, adaptive, micro-adjustments around that nominal
voltage, and these micro-adjustments are managed by the AVS hardware
sending commands to the PMIC. (specifically, on OMAP, the AVS sensors
provide inputs to the voltage processor (VP) which provide inputs to the
voltage controller (VC) which sends commands to the PMIC[1].)
The driver proposed here is primarily for initializing the various
parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
adjustments are done in hardware by VC/VP.
The only thing the higher-level layers might potentially need to do to
enable/disable AVS around transitions (e.g. when changing OPP, AVS is
disabled before changing OPP and only re-enabled when the new nominal
voltage has been acheived.)
On OMAP, we handle this inside the OMAP-specific voltage layer which is
called by the regulator framework, so even the regulators do not need
any knowledge of AVS.
Kevin
[1] Figure 3-76 in OMAP4430 ES2.1 Public TRM vAD provides a
detailed diagram:
http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAD.zip
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Mark Brown @ 2012-04-27 17:56 UTC (permalink / raw)
To: J, KEERTHY
Cc: khilman, linux-kernel, linux-pm, linux-omap, j-pihet,
linux-arm-kernel
In-Reply-To: <CAJ6a13a6WN9h1QZynpEOf-R6RXwWBZ2eOPkTeNc15JX_YfAz_w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 454 bytes --]
On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
> pre defined Operating Performance Points or the OPPs. Every OPP being
> a voltage/frequency pair. Smartreflex is a different
> power management technique.
But presumably these things should integrate somehow - for example,
should devfreq and cpufreq be providing inputs into what AVS is doing,
and if so how?
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox