* Re: Crash when suspending Lenovo T510 laptop (2.6.39.3)
From: Alan Stern @ 2011-08-05 20:21 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Len Brown, linux-pm, Jesper Juhl, linux-kernel
In-Reply-To: <201108052213.40969.rjw@sisk.pl>
On Fri, 5 Aug 2011, Rafael J. Wysocki wrote:
> > > I don't know how to fix it yet, but I think I know what the problem is.
> > > Namely, a runtime suspend of the Ethernet adapter as occured in parallel with
> > > the system-wide suspend and they clashed. The runtime suspend has probably
> > > been provoked by detaching the Ethernet cable from the box.
> >
> > For them to clash in that way would mean that the PM workqueue didn't
> > get frozen.
>
> Not necessarily, I think. It's sufficient that system suspend is started
> while the runtime PM operation is in progress.
How so? The system suspend doesn't call down to the subsystems or
drivers until after all the threads are frozen. In this case the stack
dump shows that the runtime PM operation was asynchronous, running in a
workqueue thread (pm_runtime_work is one of the routines near the end
of the stack dump). The thread wouldn't have frozen until the runtime
PM operation was complete.
Alan Stern
^ permalink raw reply
* Re: Crash when suspending Lenovo T510 laptop (2.6.39.3)
From: Rafael J. Wysocki @ 2011-08-05 20:13 UTC (permalink / raw)
To: Alan Stern; +Cc: Len Brown, linux-pm, Jesper Juhl, linux-kernel
In-Reply-To: <Pine.LNX.4.44L0.1108051557500.2055-100000@iolanthe.rowland.org>
On Friday, August 05, 2011, Alan Stern wrote:
> On Fri, 5 Aug 2011, Rafael J. Wysocki wrote:
>
> > On Friday, August 05, 2011, Jesper Juhl wrote:
> > > Hi
> > >
> > > I just experienced a kernel crash when trying to suspend my Lenovo
> > > Thinkpad T510 (model 4384-GJG) laptop.
> > >
> > > Normally I just shut the lid and the little moon icon lights up telling me
> > > that the laptop has suspended. This time was different; the moon icon
> > > didn't light up as it usually does, so I opened the lid again and found a
> > > kernel crash dump on the screen. The machine was completely dead at this
> > > point, so all I could do was take a photo of the screen - nothing had made
> > > it to the log files either (checked after a reboot).
> > >
> > > The image I took of the screen with the crash info is available here:
> > > http://personal.chaosbits.net/suspend-crash.jpg
> > >
> > > The kernel version is 2.6.39.3
> > > The kernel config is attached as '2.6.39.3-config.gz'
> > > The distribution is Arch Linux 64bit.
> > >
> > > Here is a partial transcript of the image (typed in manually, so check the
> > > image if you suspect an error - I also left out function addresses/offsets
> > > and other details before/after the backtrace to save me some typing, so
> > > check the image for the full details) :
> > >
> > > Call Trace:
> > > ? wq_worker_sleeping
> > > schedule
> > > ? cfq_put_queue
> > > ? cic_free_func
> > > ? kmem_cache_free
> > > ? put_io_context
> > > do_exit
> > > oops_end
> > > die
> > > do_trap
> > > do_invalid_op
> > > ? free_msi_irqs
> > > ? find_busiest_group
> > > ? pci_conf1_write
> > > pci_disable_msi
> > > e1000e_reset_interrupt_capabillity
> > > __e1000_runtime_suspend
> > > ? __switch_to
> > > pci_pm_runtime_suspend
> > > ? pci_legacy_suspend_late
> > > rpm_callback
> > > ? schedule
> > > rpm_suspend
> > > ? linkwatch_do_dev
> > > ? pm_schedule_suspend
> > > pm_runtime_work
> > > process_one_work
> > > worker_thread
> > > ? manage_workers.isra.29
> > > kthread
> > > kernel_thread_helper
> > > ? kthread_worker
> > > ? gs_change
> > >
> > > I've not experienced this before with this kernel, nor with earlier or
> > > newer ones, so it's not exactely reproducible on demand, so it's anyones
> > > guess when this was introduced (or if it's been there for ages, just
> > > triggers rarely)...
> > >
> > > One detail that may be relevant; normally when I suspend the laptop I do
> > > so before unplugging any cables or suspend after not having anything
> > > plugged in for ages (or at all). This time I was in a hurry, so I quickly
> > > unplugged the power, 3 usb cables and the ethernet cable and then quickly
> > > slammed the lid shut. Not sure if that has an impact on triggering this
> > > though. I tried reproducing that scenario 4-5 times, but the laptop
> > > suspended fine when I did that.
> > >
> > > If you require further information then please let me know and I'll be
> > > happy to provide it.
> > >
> > > I'll of course try to submit more details if it happens again, but if
> > > someone has a good guess as to how to provoke it or an idea for a fix I'd
> > > sure like to know.
> >
> > I don't know how to fix it yet, but I think I know what the problem is.
> > Namely, a runtime suspend of the Ethernet adapter as occured in parallel with
> > the system-wide suspend and they clashed. The runtime suspend has probably
> > been provoked by detaching the Ethernet cable from the box.
>
> For them to clash in that way would mean that the PM workqueue didn't
> get frozen.
Not necessarily, I think. It's sufficient that system suspend is started
while the runtime PM operation is in progress.
> Is that possible?
Shouldn't be.
Thanks,
Rafael
^ permalink raw reply
* Re: Crash when suspending Lenovo T510 laptop (2.6.39.3)
From: Alan Stern @ 2011-08-05 20:01 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Len Brown, linux-pm, Jesper Juhl, linux-kernel
In-Reply-To: <201108052118.12955.rjw@sisk.pl>
On Fri, 5 Aug 2011, Rafael J. Wysocki wrote:
> On Friday, August 05, 2011, Jesper Juhl wrote:
> > Hi
> >
> > I just experienced a kernel crash when trying to suspend my Lenovo
> > Thinkpad T510 (model 4384-GJG) laptop.
> >
> > Normally I just shut the lid and the little moon icon lights up telling me
> > that the laptop has suspended. This time was different; the moon icon
> > didn't light up as it usually does, so I opened the lid again and found a
> > kernel crash dump on the screen. The machine was completely dead at this
> > point, so all I could do was take a photo of the screen - nothing had made
> > it to the log files either (checked after a reboot).
> >
> > The image I took of the screen with the crash info is available here:
> > http://personal.chaosbits.net/suspend-crash.jpg
> >
> > The kernel version is 2.6.39.3
> > The kernel config is attached as '2.6.39.3-config.gz'
> > The distribution is Arch Linux 64bit.
> >
> > Here is a partial transcript of the image (typed in manually, so check the
> > image if you suspect an error - I also left out function addresses/offsets
> > and other details before/after the backtrace to save me some typing, so
> > check the image for the full details) :
> >
> > Call Trace:
> > ? wq_worker_sleeping
> > schedule
> > ? cfq_put_queue
> > ? cic_free_func
> > ? kmem_cache_free
> > ? put_io_context
> > do_exit
> > oops_end
> > die
> > do_trap
> > do_invalid_op
> > ? free_msi_irqs
> > ? find_busiest_group
> > ? pci_conf1_write
> > pci_disable_msi
> > e1000e_reset_interrupt_capabillity
> > __e1000_runtime_suspend
> > ? __switch_to
> > pci_pm_runtime_suspend
> > ? pci_legacy_suspend_late
> > rpm_callback
> > ? schedule
> > rpm_suspend
> > ? linkwatch_do_dev
> > ? pm_schedule_suspend
> > pm_runtime_work
> > process_one_work
> > worker_thread
> > ? manage_workers.isra.29
> > kthread
> > kernel_thread_helper
> > ? kthread_worker
> > ? gs_change
> >
> > I've not experienced this before with this kernel, nor with earlier or
> > newer ones, so it's not exactely reproducible on demand, so it's anyones
> > guess when this was introduced (or if it's been there for ages, just
> > triggers rarely)...
> >
> > One detail that may be relevant; normally when I suspend the laptop I do
> > so before unplugging any cables or suspend after not having anything
> > plugged in for ages (or at all). This time I was in a hurry, so I quickly
> > unplugged the power, 3 usb cables and the ethernet cable and then quickly
> > slammed the lid shut. Not sure if that has an impact on triggering this
> > though. I tried reproducing that scenario 4-5 times, but the laptop
> > suspended fine when I did that.
> >
> > If you require further information then please let me know and I'll be
> > happy to provide it.
> >
> > I'll of course try to submit more details if it happens again, but if
> > someone has a good guess as to how to provoke it or an idea for a fix I'd
> > sure like to know.
>
> I don't know how to fix it yet, but I think I know what the problem is.
> Namely, a runtime suspend of the Ethernet adapter as occured in parallel with
> the system-wide suspend and they clashed. The runtime suspend has probably
> been provoked by detaching the Ethernet cable from the box.
For them to clash in that way would mean that the PM workqueue didn't
get frozen. Is that possible?
Alan Stern
^ permalink raw reply
* Re: [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
From: Rafael J. Wysocki @ 2011-08-05 19:37 UTC (permalink / raw)
To: Mark Brown; +Cc: Linux PM mailing list, linux-omap, Jean Pihet, markgross
In-Reply-To: <20110805161147.GA3438@opensource.wolfsonmicro.com>
On Friday, August 05, 2011, Mark Brown wrote:
> On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, August 04, 2011, Mark Brown wrote:
>
> > > On the one hand that's true. On the other hand that just seems like
> > > going down a bad road where we have drivers that only work when run with
> > > a magic userspace that may or may not be published which is just going
>
> > First off, we're doing this already (user space can block runtime PM, for
> > one example, because there are systems where runtime PM doesn't work
> > although it works on other systems with analogous hardware and pretty
> > much the same set of drivers).
>
> Yeah, I've never been terribly convinced about that and for the things
> that drivers need to manualy implement (like wake configuration) it's
> widely ignored.
>
> > Second, I think there are valid use cases in which user space _really_ knows
> > better than the kernel. I'm opposed to the idea that users shouldn't be given
> > control of their systems, because they may not know what they're doing.
>
> Do you have any examples of this that aren't better expressed in device
> specific terms?
I'm not sure what you mean exactly, but if you take two PC-like systems
with similar hardware configurations, but different BIOS-es and motherboard
layouts, it's very likely that on one of them PCI PME won't be routed
correctly, for example. In that case the kernel has no way to figure out
that that system is broken, the problem can only be worked around from user
space by diabling runtime PM on the affected PCI devices. I expect similar
problems to appear for the PM QoS settings.
> It's not that users don't know what they're doing, it's
> that working around system integration and stability issues in userspace
> isn't really progressing things well or helping with maintainability.
No, it's not, but sometimes we simply don't have the choice. Besides,
in the particular case of PM QoS, the constraints set by user space will
simply be added to the constraints set by kernel subsystems. Thus they
won't prevent any kernel subsystem from specifying its own constraints,
but they will give user space the option to override the constraints
originating from the kernel.
> Generally if the user has sufficient access to be able to do anything
> with this stuff they've got just as much access to the kernel as to
> userspace.
Do you mean they may rebuild the kernel? That isn't always possible.
Thanks,
Rafael
^ permalink raw reply
* Re: [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
From: Rafael J. Wysocki @ 2011-08-05 19:22 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-pm, linux-omap, linux-arm-kernel, Colin Cross
In-Reply-To: <87vcuczrey.fsf@ti.com>
On Friday, August 05, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Friday, July 22, 2011, Kevin Hilman wrote:
> >> Currently the use of pm_runtime_put_sync() is not safe from
> >> interrupts-disabled context because rpm_idle() will release the
> >> spinlock and enable interrupts for the idle callbacks. This enables
> >> interrupts during a time where interrupts were expected to be
> >> disabled, and can have strange side effects on drivers that expected
> >> interrupts to be disabled.
> >>
> >> This is not a bug since the documentation clearly states that only
> >> _put_sync_suspend() is safe in IRQ-safe mode.
> >>
> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> >> mode by releasing the spinlock but not re-enabling interrupts, which
> >> is what this patch aims to do.
> >>
> >> Problem was found when using some buggy drivers that set
> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> >> context.
> >>
> >> The offending drivers have been fixed to use _put_sync_suspend(),
> >> But this patch is an RFC to see if it might make sense to allow
> >> using _put_sync() from interrupts-disabled context.
> >
> > OK, I'm going to take this for 3.2.
>
> Rafael,
>
> Since you're planning to merge this, maybe we should consider merging
> this as a fix for v3.1, and possibly even for v3.0 stable. That way,
> any current drivers using irq_safe and the normal _put_sync() will not
> have this problem.
I think I can push it for 3.1, but I don't think it's stable material.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] PM: add statistics sysfs file for suspend to ram
From: Rafael J. Wysocki @ 2011-08-05 19:20 UTC (permalink / raw)
To: yanmin_zhang
Cc: Liu, ShuoX, linux-pm@lists.linux-foundation.org, Greg KH,
Brown, Len
In-Reply-To: <1312514389.2043.27.camel@ymzhang>
On Friday, August 05, 2011, Yanmin Zhang wrote:
> On Fri, 2011-08-05 at 09:57 +0800, Liu, ShuoX wrote:
> > > On Thursday, August 04, 2011, Greg KH wrote:
> > > > On Thu, Aug 04, 2011 at 01:13:38PM +0800, Liu, ShuoX wrote:
> > > > > >From a906b0b5b4ff3414ceb9fc7a69a3d7c9d66e46b1 Mon Sep 17
> > > 00:00:00 2001
> > > > > From: ShuoX Liu <shuox.liu@intel.com>
> > > > > Date: Thu, 28 Jul 2011 10:54:22 +0800
> > > > > Subject: [PATCH] PM: add statistics sysfs file for suspend to ram.
> > > >
> > > > What's this stuff here for? That's not needed (hint, I would have to
> > > > edit it out by hand to be able to apply this patch.)
> > > >
> > > > Thanks for resending a version that passes checkpatch.pl and could be
> > > > applied, but all of my previous comments still stand. This patch, as
> > > > is, is totally unacceptable.
> > >
> > > Agreed, plus I'd like to know the motivation behind it. That is, we have
> > > quite a few debug facilities in that code, so why are they insufficient?
> Thanks Greg, Rafael. We are changing the patch based on your comments.
>
> >
> > Some explanation from Yanmin,
> > "We are enabling power features on Medfield. Some testers and developers
> > complain they don't know if system tries suspend-2-ram, and what device
> > fails to suspend. They need such info for a quick check. If turning on
> > CONFIG_PM_DEBUG, we get too much info and testers need recompile
> > the system.
> Comparing with PC/notebook, a mobile enters/exits suspend-2-ram (we call it s3 on
> Medfield) far more frequently. If it can't enter suspend-2-ram in time, the power
> might be used up soon.
>
> We often find sometimes, a device suspend fails. Then, system retries s3 over
> and over again. As display is off, testers/developers don't know what happens.
> Teh system
>
> With the patch, we could know what the bad device is.
>
> The patch doesn't hurt performance as it's just statistics collector.
>
> CONFIG_PM_DEBUG is very useful for finer investigation about what happens behind. What
> we provide by the patch is to analyze the issues quickly, even by an ordinary tester.
Well, what about using dynamic debug?
Rafael
^ permalink raw reply
* Re: Crash when suspending Lenovo T510 laptop (2.6.39.3)
From: Rafael J. Wysocki @ 2011-08-05 19:18 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Len Brown, linux-pm, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1108050215300.9745@swampdragon.chaosbits.net>
On Friday, August 05, 2011, Jesper Juhl wrote:
> Hi
>
> I just experienced a kernel crash when trying to suspend my Lenovo
> Thinkpad T510 (model 4384-GJG) laptop.
>
> Normally I just shut the lid and the little moon icon lights up telling me
> that the laptop has suspended. This time was different; the moon icon
> didn't light up as it usually does, so I opened the lid again and found a
> kernel crash dump on the screen. The machine was completely dead at this
> point, so all I could do was take a photo of the screen - nothing had made
> it to the log files either (checked after a reboot).
>
> The image I took of the screen with the crash info is available here:
> http://personal.chaosbits.net/suspend-crash.jpg
>
> The kernel version is 2.6.39.3
> The kernel config is attached as '2.6.39.3-config.gz'
> The distribution is Arch Linux 64bit.
>
> Here is a partial transcript of the image (typed in manually, so check the
> image if you suspect an error - I also left out function addresses/offsets
> and other details before/after the backtrace to save me some typing, so
> check the image for the full details) :
>
> Call Trace:
> ? wq_worker_sleeping
> schedule
> ? cfq_put_queue
> ? cic_free_func
> ? kmem_cache_free
> ? put_io_context
> do_exit
> oops_end
> die
> do_trap
> do_invalid_op
> ? free_msi_irqs
> ? find_busiest_group
> ? pci_conf1_write
> pci_disable_msi
> e1000e_reset_interrupt_capabillity
> __e1000_runtime_suspend
> ? __switch_to
> pci_pm_runtime_suspend
> ? pci_legacy_suspend_late
> rpm_callback
> ? schedule
> rpm_suspend
> ? linkwatch_do_dev
> ? pm_schedule_suspend
> pm_runtime_work
> process_one_work
> worker_thread
> ? manage_workers.isra.29
> kthread
> kernel_thread_helper
> ? kthread_worker
> ? gs_change
>
> I've not experienced this before with this kernel, nor with earlier or
> newer ones, so it's not exactely reproducible on demand, so it's anyones
> guess when this was introduced (or if it's been there for ages, just
> triggers rarely)...
>
> One detail that may be relevant; normally when I suspend the laptop I do
> so before unplugging any cables or suspend after not having anything
> plugged in for ages (or at all). This time I was in a hurry, so I quickly
> unplugged the power, 3 usb cables and the ethernet cable and then quickly
> slammed the lid shut. Not sure if that has an impact on triggering this
> though. I tried reproducing that scenario 4-5 times, but the laptop
> suspended fine when I did that.
>
> If you require further information then please let me know and I'll be
> happy to provide it.
>
> I'll of course try to submit more details if it happens again, but if
> someone has a good guess as to how to provoke it or an idea for a fix I'd
> sure like to know.
I don't know how to fix it yet, but I think I know what the problem is.
Namely, a runtime suspend of the Ethernet adapter as occured in parallel with
the system-wide suspend and they clashed. The runtime suspend has probably
been provoked by detaching the Ethernet cable from the box.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
From: Mark Brown @ 2011-08-05 16:11 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux PM mailing list, linux-omap, Jean Pihet, markgross
In-Reply-To: <201108042115.30983.rjw@sisk.pl>
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
> On Thursday, August 04, 2011, Mark Brown wrote:
> > On the one hand that's true. On the other hand that just seems like
> > going down a bad road where we have drivers that only work when run with
> > a magic userspace that may or may not be published which is just going
> First off, we're doing this already (user space can block runtime PM, for
> one example, because there are systems where runtime PM doesn't work
> although it works on other systems with analogous hardware and pretty
> much the same set of drivers).
Yeah, I've never been terribly convinced about that and for the things
that drivers need to manualy implement (like wake configuration) it's
widely ignored.
> Second, I think there are valid use cases in which user space _really_ knows
> better than the kernel. I'm opposed to the idea that users shouldn't be given
> control of their systems, because they may not know what they're doing.
Do you have any examples of this that aren't better expressed in device
specific terms? It's not that users don't know what they're doing, it's
that working around system integration and stability issues in userspace
isn't really progressing things well or helping with maintainability.
Generally if the user has sufficient access to be able to do anything
with this stuff they've got just as much access to the kernel as to
userspace.
^ permalink raw reply
* Re: [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
From: mark gross @ 2011-08-05 15:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux PM mailing list, Mark Brown, markgross, Jean Pihet,
linux-omap
In-Reply-To: <201108042115.30983.rjw@sisk.pl>
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
> On Thursday, August 04, 2011, Mark Brown wrote:
> > On Wed, Aug 03, 2011 at 12:16:17AM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, August 02, 2011, Kevin Hilman wrote:
> >
> > > > I disagree and think that both are quite realistic (mainly because they
> > > > exist today, albiet mostly out of tree because no generic QoS framework
> > > > exist. e.g. on OMAP, we have OMAP-specific *kernel* APIs for requesting
> > > > per-device wakeup latencies, and drivers and frameworks are using them.)
> > >
> > > I'm sure there are frameworks using such things. I'm also sure there
> > > are frameworks that don't. BTW, the "we have it out of the tree" argument is
> > > not very useful, so I'd appreciate it if you didn't use it.
> >
> > It's useful to know if people have tried things; it doesn't mean it's
> > going to be OK for mainline but it is a data point.
> >
> > > > In this case, the video framework (V4L2) might not want any knobs
> > > > exposed to userspace because userspace simply doesn't have the knowledge
> > > > to set appropriate constraints. I'm less familiar with audio, but I
> > > > believe audio would be similar (sample rate, number of channels, mixing
> > > > with other concurrent audio streams, etc. etc. are all known by the
> > > > kernel-side code.)
> >
> > Yeah, that sort of stuff and also data like wakeup latencies required to
> > service interrupts.
> >
> > > I still don't understand what's wrong with allowing user space to _add_
> > > requirements. The will only override the drivers' or frameworks' requirements
> > > if they are stronger, so the functionality shouldn't be hurt. They may cause
> > > some more energy to be used, but if user space wants that, it's pretty much
> > > fine by me.
> >
> > On the one hand that's true. On the other hand that just seems like
> > going down a bad road where we have drivers that only work when run with
> > a magic userspace that may or may not be published which is just going
> > to make people miserable. I'm not sure there are many people who would
> > choose to use more power without wanting some functional change so
> > presumably any users would be seeking to work around some kernel problem
> > and adding the user interface seems to be saying that this is OK,
> > expected and a natural part of power optimization.
>
> First off, we're doing this already (user space can block runtime PM, for
> one example, because there are systems where runtime PM doesn't work
> although it works on other systems with analogous hardware and pretty
> much the same set of drivers).
>
> Second, I think there are valid use cases in which user space _really_ knows
> better than the kernel. I'm opposed to the idea that users shouldn't be given
> control of their systems, because they may not know what they're doing.
>
Ok, I can see the point. The challenge is how do we expose ABI's and
abstractions that result in drivers and PM implementations that are
somewhat portable between ISA's and platforms? Simply exporting the low
level knobs of whatever drivers are loaded into memory, if used in user
mode, could result in a tight coupling or even a reverse dependency on a
proper user mode for the kernel to do the right things.
I'm sensitive to becoming blocked on doing kernel a update just because
we can't update the user mode code at the same time. Its quite
annoying.
IMO to make it easy reuse TI SoC drivers in Intel SoC's (and
visa-versa) I would rather have these low level PM-QoS constraint
details abstracted in some sane and consistent way. Through subsystem
API's if possible or, at a bus level if we must.
--mark
Ps I also am worried I'm over thinking about this an Rafael may be right
and we would be better off just exposing the abstractions of "latency"
and "throughput" uniformly and focus more on the missing bus and
subsystem level governors that need to interpret and coordinate the qos
requests.
^ permalink raw reply
* Re: [PATCH v4 1/2] Input: enable i8042-level wakeup control
From: Daniel Drake @ 2011-08-05 15:24 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-pm, dilinger, linux-input
In-Reply-To: <20110803184332.GA17880@core.coreip.homeip.net>
Hi Dmitry,
On Wed, Aug 3, 2011 at 7:43 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Instead of wiring it all through input core could we contain this in
> atkbd and hgpk by registering pm_notifiers and ignoring certain requests
> from input/serio cores during system state transition on OLPC only?
I've started looking at this, but my first problem is that when the
input layer asks atkbd to turn off LEDs, atkbd schedules a workqueue
item to undertake this work. However, as there is no synchronization,
this work only seems to get executed during or after system resume.
This makes it hard to catch with such a scheme. Any ideas?
Daniel
^ permalink raw reply
* Re: [PATCH 5/5] cpuidle: stop depending on pm_idle --build break
From: Deepthi Dharwar @ 2011-08-05 12:18 UTC (permalink / raw)
To: Len Brown; +Cc: Kevin Hilman, Len Brown, linux-pm, x86, linux-kernel
In-Reply-To: <619b3f9e65307529dd4bbc98efe9d2f3b632646c.1312400543.git.len.brown@intel.com>
Following is a patch required to compile on arm
and sh with the latest cpuidle cleanup changes.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Trinabh Gupta <trinabh@linux.vnet.ibm.com>
Index: linux/arch/arm/kernel/process.c
===================================================================
--- linux.orig/arch/arm/kernel/process.c 2011-08-05 11:02:59.000000000 +0000
+++ linux/arch/arm/kernel/process.c 2011-08-05 11:10:03.000000000 +0000
@@ -197,7 +197,7 @@
cpu_relax();
} else {
stop_critical_timings();
- if (cpuidle_call_idle())
+ if (cpuidle_idle_call())
pm_idle();
start_critical_timings();
/*
Index: linux/arch/sh/kernel/idle.c
===================================================================
--- linux.orig/arch/sh/kernel/idle.c 2011-08-05 11:02:59.000000000 +0000
+++ linux/arch/sh/kernel/idle.c 2011-08-05 11:13:23.000000000 +0000
@@ -101,7 +101,7 @@
local_irq_disable();
/* Don't trace irqs off for idle */
stop_critical_timings();
- if (cpuidle_call_idle())
+ if (cpuidle_idle_call())
pm_idle();
/*
* Sanity check to ensure that pm_idle() returns
^ permalink raw reply
* Re: [PATCH 5/5] cpuidle: stop depending on pm_idle
From: Deepthi Dharwar @ 2011-08-05 9:48 UTC (permalink / raw)
Cc: Len Brown, Kevin Hilman, x86, linux-kernel, linux-pm
In-Reply-To: <CAAXLqgrnRi25WM2HpHxe-R4ePrgdbVROky4+=3Jr489M7zbgUA@mail.gmail.com>
Hi Len,
The following code would not compile on ARM.
The patch for this has already been posted by Trinabh
earlier on, in the following link.
https://lkml.org/lkml/2011/4/25/54
On Thursday 04 August 2011 10:51 PM, Trinabh Gupta wrote:
>
>
> On Wed, Aug 3, 2011 at 12:44 PM, Len Brown <lenb@kernel.org <mailto:lenb@kernel.org>> wrote:
>
> From: Len Brown <len.brown@intel.com <mailto:len.brown@intel.com>>
>
> cpuidle users should call cpuidle_call_idle() directly
> rather than via (pm_idle)() function pointer.
>
> Architecture may choose to continue using (pm_idle)(),
> but cpuidle need not depend on it:
>
> my_arch_cpu_idle()
> ...
> if(cpuidle_call_idle())
> pm_idle();
>
> cc: x86@kernel.org <mailto:x86@kernel.org>
> cc: Kevin Hilman <khilman@deeprootsystems.com <mailto:khilman@deeprootsystems.com>>
> cc: Paul Mundt <lethal@linux-sh.org <mailto:lethal@linux-sh.org>>
> Signed-off-by: Len Brown <len.brown@intel.com <mailto:len.brown@intel.com>>
> ---
> arch/arm/kernel/process.c | 4 +++-
> arch/sh/kernel/idle.c | 6 ++++--
> arch/x86/kernel/process_32.c | 4 +++-
> arch/x86/kernel/process_64.c | 4 +++-
> drivers/cpuidle/cpuidle.c | 38 ++++++++++++++++++--------------------
> include/linux/cpuidle.h | 2 ++
> 6 files changed, 33 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 5e1e541..d7ee0d4 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -30,6 +30,7 @@
> #include <linux/uaccess.h>
> #include <linux/random.h>
> #include <linux/hw_breakpoint.h>
> +#include <linux/cpuidle.h>
>
> #include <asm/cacheflush.h>
> #include <asm/leds.h>
> @@ -196,7 +197,8 @@ void cpu_idle(void)
> cpu_relax();
> } else {
> stop_critical_timings();
> - pm_idle();
> + if (cpuidle_call_idle())
>
>
> Hi Len,
>
> This should be cpuidle_idle_call()
>
>
> + pm_idle();
> start_critical_timings();
> /*
> * This will eventually be removed - pm_idle
> diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c
> index 425d604..9c7099e 100644
> --- a/arch/sh/kernel/idle.c
> +++ b/arch/sh/kernel/idle.c
> @@ -16,12 +16,13 @@
> #include <linux/thread_info.h>
> #include <linux/irqflags.h>
> #include <linux/smp.h>
> +#include <linux/cpuidle.h>
> #include <asm/pgalloc.h>
> #include <asm/system.h>
> #include <asm/atomic.h>
> #include <asm/smp.h>
>
> -void (*pm_idle)(void) = NULL;
> +static void (*pm_idle)(void);
>
> static int hlt_counter;
>
> @@ -100,7 +101,8 @@ void cpu_idle(void)
> local_irq_disable();
> /* Don't trace irqs off for idle */
> stop_critical_timings();
> - pm_idle();
> + if (cpuidle_call_idle())
>
>
> Again this should be cpuidle_idle_call()
>
> + pm_idle();
> /*
> * Sanity check to ensure that pm_idle() returns
> * with IRQs enabled
> diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
> index a3d0dc5..7a3b651 100644
> --- a/arch/x86/kernel/process_32.c
> +++ b/arch/x86/kernel/process_32.c
> @@ -38,6 +38,7 @@
> #include <linux/uaccess.h>
> #include <linux/io.h>
> #include <linux/kdebug.h>
> +#include <linux/cpuidle.h>
>
> #include <asm/pgtable.h>
> #include <asm/system.h>
> @@ -109,7 +110,8 @@ void cpu_idle(void)
> local_irq_disable();
> /* Don't trace irqs off for idle */
> stop_critical_timings();
> - pm_idle();
> + if (cpuidle_idle_call())
> + pm_idle();
> start_critical_timings();
> }
> tick_nohz_restart_sched_tick();
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index ca6f7ab..f693e44 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -37,6 +37,7 @@
> #include <linux/uaccess.h>
> #include <linux/io.h>
> #include <linux/ftrace.h>
> +#include <linux/cpuidle.h>
>
> #include <asm/pgtable.h>
> #include <asm/system.h>
> @@ -136,7 +137,8 @@ void cpu_idle(void)
> enter_idle();
> /* Don't trace irqs off for idle */
> stop_critical_timings();
> - pm_idle();
> + if (cpuidle_idle_call())
> + pm_idle();
> start_critical_timings();
>
> /* In many cases the interrupt that ended idle
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 041df0b..d4c5423 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -25,10 +25,10 @@ DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
>
> DEFINE_MUTEX(cpuidle_lock);
> LIST_HEAD(cpuidle_detected_devices);
> -static void (*pm_idle_old)(void);
>
> static int enabled_devices;
> static int off __read_mostly;
> +static int initialized __read_mostly;
>
> int cpuidle_disabled(void)
> {
> @@ -56,25 +56,23 @@ static int __cpuidle_register_device(struct cpuidle_device *dev);
> * cpuidle_idle_call - the main idle loop
> *
> * NOTE: no locks or semaphores should be used here
> + * return non-zero on failure
> */
> -static void cpuidle_idle_call(void)
> +int cpuidle_idle_call(void)
> {
> struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
> struct cpuidle_state *target_state;
> int next_state;
>
> + if (off)
> + return -ENODEV;
> +
> + if (!initialized)
> + return -ENODEV;
> +
> /* check if the device is ready */
> - if (!dev || !dev->enabled) {
> - if (pm_idle_old)
> - pm_idle_old();
> - else
> -#if defined(CONFIG_ARCH_HAS_DEFAULT_IDLE)
> - default_idle();
> -#else
> - local_irq_enable();
> -#endif
> - return;
> - }
> + if (!dev || !dev->enabled)
> + return -EBUSY;
>
> #if 0
> /* shows regressions, re-enable for 2.6.29 */
> @@ -99,7 +97,7 @@ static void cpuidle_idle_call(void)
> next_state = cpuidle_curr_governor->select(dev);
> if (need_resched()) {
> local_irq_enable();
> - return;
> + return 0;
> }
>
> target_state = &dev->states[next_state];
> @@ -124,6 +122,8 @@ static void cpuidle_idle_call(void)
> /* give the governor an opportunity to reflect on the outcome */
> if (cpuidle_curr_governor->reflect)
> cpuidle_curr_governor->reflect(dev);
> +
> + return 0;
> }
>
> /**
> @@ -131,10 +131,10 @@ static void cpuidle_idle_call(void)
> */
> void cpuidle_install_idle_handler(void)
> {
> - if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
> + if (enabled_devices) {
> /* Make sure all changes finished before we switch to new idle */
> smp_wmb();
> - pm_idle = cpuidle_idle_call;
> + initialized = 1;
> }
> }
>
> @@ -143,8 +143,8 @@ void cpuidle_install_idle_handler(void)
> */
> void cpuidle_uninstall_idle_handler(void)
> {
> - if (enabled_devices && pm_idle_old && (pm_idle != pm_idle_old)) {
> - pm_idle = pm_idle_old;
> + if (enabled_devices) {
> + initialized = 0;
> cpuidle_kick_cpus();
> }
> }
> @@ -440,8 +440,6 @@ static int __init cpuidle_init(void)
> if (cpuidle_disabled())
> return -ENODEV;
>
> - pm_idle_old = pm_idle;
> -
> ret = cpuidle_add_class_sysfs(&cpu_sysdev_class);
> if (ret)
> return ret;
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index b89f67d..b51629e 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -123,6 +123,7 @@ struct cpuidle_driver {
>
> #ifdef CONFIG_CPU_IDLE
> extern void disable_cpuidle(void);
> +extern int cpuidle_idle_call(void);
>
> extern int cpuidle_register_driver(struct cpuidle_driver *drv);
> struct cpuidle_driver *cpuidle_get_driver(void);
> @@ -137,6 +138,7 @@ extern void cpuidle_disable_device(struct cpuidle_device *dev);
>
> #else
> static inline void disable_cpuidle(void) { }
> +static inline int cpuidle_idle_call(void) { return -ENODEV; }
>
> static inline int cpuidle_register_driver(struct cpuidle_driver *drv)
> {return -ENODEV; }
> --
> 1.7.6.396.ge0613
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org <mailto:linux-pm@lists.linux-foundation.org>
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>
>
>
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
Regards,
Deepthi
^ permalink raw reply
* Re: [PATCH v4 0/3] DEVFREQ, DVFS framework for non-CPU devices
From: MyungJoo Ham @ 2011-08-05 6:18 UTC (permalink / raw)
To: Rafael J. Wysocki, Turquette, Mike
Cc: Len Brown, Greg Kroah-Hartman, Kyungmin Park, Thomas Gleixner,
linux-pm
In-Reply-To: <CAJOA=zMNToQq=RVrRh2p+kko=n67BWwHjcWX3DGFuYCfAcksOQ@mail.gmail.com>
On Fri, Aug 5, 2011 at 6:59 AM, Turquette, Mike <mturquette@ti.com> wrote:
> On Thu, Aug 4, 2011 at 1:15 AM, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
>>
>> Ok.. I see.
>>
>> Now, I can agree with you that tickle is subset of QoS request.
>>
>> As long as we have QoS request feature on devices with either OPP or
>> DEVFREQ, tickling is not needed.
>>
>> I'll remove tickle in the next revision (along with some bugfixes for
>> bugs found recently).
>>
>>
>> Anyway, it appears that clock-rate-wise QoS request may be dealt at
>> OPP so that the OPPs meeting the QoS requests w/ frequency or voltage
>> specifications are enabled and returned with opp_find_* functions.
>> Maybe we will need to separate enable/disable by
>> opp_enable()/opp_disable() from enable/disable by QoS requests so that
>> the two may have different semantics. Then, QoS requests cannot
>> override opp_disable and opp_enable cannot override QoS requests. This
>> way, any clock-setting code properly based on OPP (including any
>> customized devfreq governors) cannot violate QoS requests.
>
> If devfreq used the QoS API in it's ->target() call then this would
> not be an issue, and further illustrates the idea of devfreq simply
> being a policy into a proper QoS API.
>
> Regards,
> Mike
>
Yes, if we choose an OPP that meets the PM-QoS requests before calling
->target() in devfreq_do(), there wouldn't be an issue.
However, if a device is using DEVFREQ, it also means the device has
OPPs (mandatory for DEVFREQ). If the device is using PM QoS as well as
OPP, I guess the correctly implemented device driver needs to call
opp_enable() and opp_disable() according to PM QoS's update_target()
calls through the PM QoS notifier cb.
Then, for such drivers, DEVFREQ automatically meets PM QoS requests
without any modification; as long as QoS meeting OPPs are enabled at
the device driver's PM QoS callback, there is no QoS issue.
Therefore, now, it appears that neither OPP or DEVFREQ should be
allowed to directly touch PM QoS APIs, but, the device driver should
do so with notifier by simply calling opp-enable/disable if the
frequency is the key QoS "actuator".
If we are going to let DEVFREQ handle its corresponding devices' PM
QoS APIs, it would mean that both device driver and its DEVFREQ codes
will be handling PM QoS API duplicated (or worse, inconsistently).
Cheers,
MyungJoo
>> How about this concept of getting QoS requests associated with clock rates?
>>
>>
>>
>> Cheers!
>> MyungJoo.
>> --
>> MyungJoo Ham, Ph.D.
>> Mobile Software Platform Lab,
>> Digital Media and Communications (DMC) Business
>> Samsung Electronics
>> cell: 82-10-6714-2858
>> _______________________________________________
>> linux-pm mailing list
>> linux-pm@lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>>
>
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
^ permalink raw reply
* Re: [PATCH] PM: add statistics sysfs file for suspend to ram
From: Yanmin Zhang @ 2011-08-05 3:19 UTC (permalink / raw)
To: Liu, ShuoX; +Cc: Brown, Len, linux-pm@lists.linux-foundation.org, Greg KH
In-Reply-To: <6E3BC7F7C9A4BF4286DD4C043110F30B5B7932BF1D@shsmsx502.ccr.corp.intel.com>
On Fri, 2011-08-05 at 09:57 +0800, Liu, ShuoX wrote:
> > On Thursday, August 04, 2011, Greg KH wrote:
> > > On Thu, Aug 04, 2011 at 01:13:38PM +0800, Liu, ShuoX wrote:
> > > > >From a906b0b5b4ff3414ceb9fc7a69a3d7c9d66e46b1 Mon Sep 17
> > 00:00:00 2001
> > > > From: ShuoX Liu <shuox.liu@intel.com>
> > > > Date: Thu, 28 Jul 2011 10:54:22 +0800
> > > > Subject: [PATCH] PM: add statistics sysfs file for suspend to ram.
> > >
> > > What's this stuff here for? That's not needed (hint, I would have to
> > > edit it out by hand to be able to apply this patch.)
> > >
> > > Thanks for resending a version that passes checkpatch.pl and could be
> > > applied, but all of my previous comments still stand. This patch, as
> > > is, is totally unacceptable.
> >
> > Agreed, plus I'd like to know the motivation behind it. That is, we have
> > quite a few debug facilities in that code, so why are they insufficient?
Thanks Greg, Rafael. We are changing the patch based on your comments.
>
> Some explanation from Yanmin,
> "We are enabling power features on Medfield. Some testers and developers
> complain they don't know if system tries suspend-2-ram, and what device
> fails to suspend. They need such info for a quick check. If turning on
> CONFIG_PM_DEBUG, we get too much info and testers need recompile
> the system.
Comparing with PC/notebook, a mobile enters/exits suspend-2-ram (we call it s3 on
Medfield) far more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries s3 over
and over again. As display is off, testers/developers don't know what happens.
Teh system
With the patch, we could know what the bad device is.
The patch doesn't hurt performance as it's just statistics collector.
CONFIG_PM_DEBUG is very useful for finer investigation about what happens behind. What
we provide by the patch is to analyze the issues quickly, even by an ordinary tester.
>
> The patch records the suspend-2-ram fail/success statistics and the last 2
> failed devices. Users could find what device causes the failure quickly."
We are modifying the patch.
1) move the sysfs entry to debugfs;
3) Add an explanation in file Documentation/power/basic-pm-debugging.txt.
2) Add more explanation, especially about the motivation, and how to use it, into
the patch comments.
Thanks again.
Yanmin
^ permalink raw reply
* Re: [PATCH] PM: add statistics sysfs file for suspend to ram
From: Liu, ShuoX @ 2011-08-05 1:57 UTC (permalink / raw)
To: Rafael J. Wysocki, Greg KH
Cc: Brown, Len, linux-pm@lists.linux-foundation.org,
Yanmin_zhang@linux.intel.com
In-Reply-To: <201108041132.35399.rjw@sisk.pl>
> On Thursday, August 04, 2011, Greg KH wrote:
> > On Thu, Aug 04, 2011 at 01:13:38PM +0800, Liu, ShuoX wrote:
> > > >From a906b0b5b4ff3414ceb9fc7a69a3d7c9d66e46b1 Mon Sep 17
> 00:00:00 2001
> > > From: ShuoX Liu <shuox.liu@intel.com>
> > > Date: Thu, 28 Jul 2011 10:54:22 +0800
> > > Subject: [PATCH] PM: add statistics sysfs file for suspend to ram.
> >
> > What's this stuff here for? That's not needed (hint, I would have to
> > edit it out by hand to be able to apply this patch.)
> >
> > Thanks for resending a version that passes checkpatch.pl and could be
> > applied, but all of my previous comments still stand. This patch, as
> > is, is totally unacceptable.
>
> Agreed, plus I'd like to know the motivation behind it. That is, we have
> quite a few debug facilities in that code, so why are they insufficient?
Some explanation from Yanmin,
"We are enabling power features on Medfield. Some testers and developers
complain they don't know if system tries suspend-2-ram, and what device
fails to suspend. They need such info for a quick check. If turning on
CONFIG_PM_DEBUG, we get too much info and testers need recompile
the system.
The patch records the suspend-2-ram fail/success statistics and the last 2
failed devices. Users could find what device causes the failure quickly."
If you guys agree, I will modify the patch as Greg said and resend.
Shuo
^ permalink raw reply
* Crash when suspending Lenovo T510 laptop (2.6.39.3)
From: Jesper Juhl @ 2011-08-05 0:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Len Brown, linux-pm
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2795 bytes --]
Hi
I just experienced a kernel crash when trying to suspend my Lenovo
Thinkpad T510 (model 4384-GJG) laptop.
Normally I just shut the lid and the little moon icon lights up telling me
that the laptop has suspended. This time was different; the moon icon
didn't light up as it usually does, so I opened the lid again and found a
kernel crash dump on the screen. The machine was completely dead at this
point, so all I could do was take a photo of the screen - nothing had made
it to the log files either (checked after a reboot).
The image I took of the screen with the crash info is available here:
http://personal.chaosbits.net/suspend-crash.jpg
The kernel version is 2.6.39.3
The kernel config is attached as '2.6.39.3-config.gz'
The distribution is Arch Linux 64bit.
Here is a partial transcript of the image (typed in manually, so check the
image if you suspect an error - I also left out function addresses/offsets
and other details before/after the backtrace to save me some typing, so
check the image for the full details) :
Call Trace:
? wq_worker_sleeping
schedule
? cfq_put_queue
? cic_free_func
? kmem_cache_free
? put_io_context
do_exit
oops_end
die
do_trap
do_invalid_op
? free_msi_irqs
? find_busiest_group
? pci_conf1_write
pci_disable_msi
e1000e_reset_interrupt_capabillity
__e1000_runtime_suspend
? __switch_to
pci_pm_runtime_suspend
? pci_legacy_suspend_late
rpm_callback
? schedule
rpm_suspend
? linkwatch_do_dev
? pm_schedule_suspend
pm_runtime_work
process_one_work
worker_thread
? manage_workers.isra.29
kthread
kernel_thread_helper
? kthread_worker
? gs_change
I've not experienced this before with this kernel, nor with earlier or
newer ones, so it's not exactely reproducible on demand, so it's anyones
guess when this was introduced (or if it's been there for ages, just
triggers rarely)...
One detail that may be relevant; normally when I suspend the laptop I do
so before unplugging any cables or suspend after not having anything
plugged in for ages (or at all). This time I was in a hurry, so I quickly
unplugged the power, 3 usb cables and the ethernet cable and then quickly
slammed the lid shut. Not sure if that has an impact on triggering this
though. I tried reproducing that scenario 4-5 times, but the laptop
suspended fine when I did that.
If you require further information then please let me know and I'll be
happy to provide it.
I'll of course try to submit more details if it happens again, but if
someone has a good guess as to how to provoke it or an idea for a fix I'd
sure like to know.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 30971 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
From: Kevin Hilman @ 2011-08-04 23:29 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, linux-omap, linux-arm-kernel, Colin Cross
In-Reply-To: <201107240102.09698.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, July 22, 2011, Kevin Hilman wrote:
>> Currently the use of pm_runtime_put_sync() is not safe from
>> interrupts-disabled context because rpm_idle() will release the
>> spinlock and enable interrupts for the idle callbacks. This enables
>> interrupts during a time where interrupts were expected to be
>> disabled, and can have strange side effects on drivers that expected
>> interrupts to be disabled.
>>
>> This is not a bug since the documentation clearly states that only
>> _put_sync_suspend() is safe in IRQ-safe mode.
>>
>> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> mode by releasing the spinlock but not re-enabling interrupts, which
>> is what this patch aims to do.
>>
>> Problem was found when using some buggy drivers that set
>> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> context.
>>
>> The offending drivers have been fixed to use _put_sync_suspend(),
>> But this patch is an RFC to see if it might make sense to allow
>> using _put_sync() from interrupts-disabled context.
>
> OK, I'm going to take this for 3.2.
Rafael,
Since you're planning to merge this, maybe we should consider merging
this as a fix for v3.1, and possibly even for v3.0 stable. That way,
any current drivers using irq_safe and the normal _put_sync() will not
have this problem.
Kevin
^ permalink raw reply
* Re: [GIT PULL] idle patches for Linux 3.1
From: Kevin Hilman @ 2011-08-04 22:57 UTC (permalink / raw)
To: Len Brown; +Cc: linux-pm, Linus Torvalds, linux-kernel
In-Reply-To: <alpine.LFD.2.02.1108040030550.29492@x980>
Len Brown <lenb@kernel.org> writes:
> and I'm here to support them if anything goes wrong.
Here's your first opportuntity for support. :)
I see Linus has already pulled this, but it doesn't compile on ARM or
SH as I just found out, and Trinabh poined out in reply to patch 5/5.
Here's a fix.
Kevin
>From f8c825215f824b01a3f33416198def2fd685c7cf Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@ti.com>
Date: Thu, 4 Aug 2011 15:49:51 -0700
Subject: [PATCH] cpuidle: ARM/SH: fix use of cpuidle_idle_call()
commit a0bfa1373859e9d11dc92561a8667588803e42d8 (cpuidle: stop
depending on pm_idle) introduced a call to cpuidle_call_idle() in the
ARM and SH idle paths, but this function doesn't exist. Use
cpuidle_idle_call()
Reported-by: Trinabh Gupta <trinabh@linux.vnet.ibm.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/kernel/process.c | 2 +-
arch/sh/kernel/idle.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index d7ee0d4..1a347f4 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -197,7 +197,7 @@ void cpu_idle(void)
cpu_relax();
} else {
stop_critical_timings();
- if (cpuidle_call_idle())
+ if (cpuidle_idle_call())
pm_idle();
start_critical_timings();
/*
diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c
index 3c45de1..32114e0 100644
--- a/arch/sh/kernel/idle.c
+++ b/arch/sh/kernel/idle.c
@@ -101,7 +101,7 @@ void cpu_idle(void)
local_irq_disable();
/* Don't trace irqs off for idle */
stop_critical_timings();
- if (cpuidle_call_idle())
+ if (cpuidle_idle_call())
pm_idle();
/*
* Sanity check to ensure that pm_idle() returns
--
1.7.6
^ permalink raw reply related
* Re: [RFC][PATCH] PM / Freezer: Freeze filesystems along with freezing processes (was: Re: PM / hibernate xfs lock up / xfs_reclaim_inodes_ag)
From: Rafael J. Wysocki @ 2011-08-04 22:25 UTC (permalink / raw)
To: Pavel Machek
Cc: Christoph, Theodore Ts'o, Dave Chinner, LKML, xfs,
Christoph Hellwig, Linux PM mailing list, linux-ext4
In-Reply-To: <201108041127.30944.rjw@sisk.pl>
On Thursday, August 04, 2011, Rafael J. Wysocki wrote:
> On Wednesday, August 03, 2011, Pavel Machek wrote:
> > Hi!
> >
> > > Freeze all filesystems during the freezing of tasks by calling
> > > freeze_bdev() for each of them and thaw them during the thawing
> > > of tasks with the help of thaw_bdev().
> > >
> > > This is needed by hibernation, because some filesystems (e.g. XFS)
> > > deadlock with the preallocation of memory used by it if the memory
> > > pressure caused by it is too heavy.
> > >
> > > The additional benefit of this change is that, if something goes
> > > wrong after filesystems have been frozen, they will stay in a
> > > consistent state and journal replays won't be necessary (e.g. after
> > > a failing suspend or resume). In particular, this should help to
> > > solve a long-standing issue that in some cases during resume from
> > > hibernation the boot loader causes the journal to be replied for the
> > > filesystem containing the kernel image and initrd causing it to
> > > become inconsistent with the information stored in the hibernation
> > > image.
> >
> > > +/**
> > > + * freeze_filesystems - Force all filesystems into a consistent state.
> > > + */
> > > +void freeze_filesystems(void)
> > > +{
> > > + struct super_block *sb;
> > > +
> > > + lockdep_off();
> >
> > Ouch. So... why do we need to silence this?
>
> So that it doesn't complain? :-)
>
> I'll need some time to get the exact details here.
So, this is because ext3_freeze() that doesn't call
journal_unlock_updates() on success, which quite frankly looks like
a bug in ext3 to me. At least that's different from what ext4 does
in exactly the same situation (which looks correct).
If ext3_freeze() called journal_unlock_updates() on success too and
the call to journal_unlock_updates() is removed from ext3_unfreeze(),
we wouldn't need that lockdep_off()/lockdep_on() around the loop.
I need someone with ext3/ext4 knowledge to comment here, though.
Moreover, I'm not sure if other filesystems don't do such things.
Anyway, this is just a false-positive, even with the ext3 code as is.
> > > + /*
> > > + * Freeze in reverse order so filesystems dependant upon others are
> > > + * frozen in the right order (eg. loopback on ext3).
> > > + */
> > > + list_for_each_entry_reverse(sb, &super_blocks, s_list) {
> > > + if (!sb->s_root || !sb->s_bdev ||
> > > + (sb->s_frozen == SB_FREEZE_TRANS) ||
> > > + (sb->s_flags & MS_RDONLY) ||
> > > + (sb->s_flags & MS_FROZEN))
> > > + continue;
> >
> > Should we stop NFS from modifying remote server, too?
>
> What do you mean exactly?
>
> > Plus... ext3 writes to read-only filesystems on mount; not sure if it
> > does it later. But RDONLY means 'user cant write to it' not 'bdev will
> > not be modified'. Should we freeze all?
> >
> > How can 'already frozen' happen?
> >
> > > + list_for_each_entry(sb, &super_blocks, s_list)
> > > + if (sb->s_flags & MS_FROZEN) {
> > > + sb->s_flags &= ~MS_FROZEN;
> > > + thaw_bdev(sb->s_bdev, sb);
> > > + }
> >
> > ...because we'll unfreeze it even if we did not freeze it...
>
> So we need not check MS_FROZEN in freeze_filesystems(). OK
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v4 0/3] DEVFREQ, DVFS framework for non-CPU devices
From: Turquette, Mike @ 2011-08-04 21:59 UTC (permalink / raw)
To: MyungJoo Ham
Cc: Len Brown, Greg Kroah-Hartman, Kyungmin Park, Thomas Gleixner,
linux-pm
In-Reply-To: <CAJ0PZbQQkAPHNwzh0tL9BiNAjjMtUOCoKV1JDzUqj0utx8COgg@mail.gmail.com>
On Thu, Aug 4, 2011 at 1:15 AM, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
> On Thu, Aug 4, 2011 at 3:33 AM, Kevin Hilman <khilman@ti.com> wrote:
>> MyungJoo Ham <myungjoo.ham@samsung.com> writes:
>>
>>> On Wed, Aug 3, 2011 at 7:02 AM, Kevin Hilman <khilman@ti.com> wrote:
>>
>> [...]
>>
>>>> Maybe I'm not understanding the usage of it fully, but that seems like
>>>> hard-coding policy into the framework that might not be appropriate.
>>>> For example, what if there are other devices with constraints such that
>>>> they cannot currently scale frequency/voltage?
>>>>
>>>> Mabye MyungJoo can explain in more detail the usecases for tickle?
>>>
>>> Tickle is not for QoS between devices. It is for faster reaction to
>>> (human) user inputs at DVFS side where waiting for DVFS's reaction
>>> takes too much time and reducing polling interval costs too much.
>>
>> This is exactly what quality of service (QoS) is about.
>>
>> The user (whether it's a human user input or another device) has low
>> quality and expects higher quality. It wants to request better quality,
>> so it needs a way to request it.
>>
>> The proposed "tickle" approach proposed here is simply a "request max
>> frequency for duration X" QoS request.
>>
>> Kevin
>>
>
> Ok.. I see.
>
> Now, I can agree with you that tickle is subset of QoS request.
>
> As long as we have QoS request feature on devices with either OPP or
> DEVFREQ, tickling is not needed.
>
> I'll remove tickle in the next revision (along with some bugfixes for
> bugs found recently).
>
>
> Anyway, it appears that clock-rate-wise QoS request may be dealt at
> OPP so that the OPPs meeting the QoS requests w/ frequency or voltage
> specifications are enabled and returned with opp_find_* functions.
> Maybe we will need to separate enable/disable by
> opp_enable()/opp_disable() from enable/disable by QoS requests so that
> the two may have different semantics. Then, QoS requests cannot
> override opp_disable and opp_enable cannot override QoS requests. This
> way, any clock-setting code properly based on OPP (including any
> customized devfreq governors) cannot violate QoS requests.
If devfreq used the QoS API in it's ->target() call then this would
not be an issue, and further illustrates the idea of devfreq simply
being a policy into a proper QoS API.
Regards,
Mike
> How about this concept of getting QoS requests associated with clock rates?
>
>
>
> Cheers!
> MyungJoo.
> --
> MyungJoo Ham, Ph.D.
> Mobile Software Platform Lab,
> Digital Media and Communications (DMC) Business
> Samsung Electronics
> cell: 82-10-6714-2858
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>
^ permalink raw reply
* Re: [PATCH] PM: add statistics sysfs file for suspend to ram
From: Rafael J. Wysocki @ 2011-08-04 19:50 UTC (permalink / raw)
To: linux-pm; +Cc: Liu, ShuoX, gregkh@suse.de, Brown, Len
In-Reply-To: <20110804121728.9280c9af.rdunlap@xenotime.net>
On Thursday, August 04, 2011, Randy Dunlap wrote:
> On Thu, 04 Aug 2011 15:05:10 -0400 (EDT) Len Brown wrote:
>
> > > Record S3 failure time about each reason and the latest two failed
> > > devices' name in S3 progress.
> > > We can check it through /sys/power/suspend_stats.
> >
> > these sound more like debugfs than sysfs things.
>
> debugfs also allows more than one value per file, like I think
> I saw in this patch.
However, I still would like to know what's insufficient in the current
debug stuff in the PM core that makes this new code necessary.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] PM: add statistics sysfs file for suspend to ram
From: Randy Dunlap @ 2011-08-04 19:17 UTC (permalink / raw)
To: Len Brown
Cc: Liu, ShuoX, linux-pm@lists.linux-foundation.org, gregkh@suse.de,
Brown, Len
In-Reply-To: <alpine.LFD.2.02.1108041503440.24626@x980>
On Thu, 04 Aug 2011 15:05:10 -0400 (EDT) Len Brown wrote:
> > Record S3 failure time about each reason and the latest two failed
> > devices' name in S3 progress.
> > We can check it through /sys/power/suspend_stats.
>
> these sound more like debugfs than sysfs things.
debugfs also allows more than one value per file, like I think
I saw in this patch.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
From: Rafael J. Wysocki @ 2011-08-04 19:15 UTC (permalink / raw)
To: Mark Brown; +Cc: Linux PM mailing list, linux-omap, Jean Pihet, markgross
In-Reply-To: <20110804132426.GB14921@sirena.org.uk>
On Thursday, August 04, 2011, Mark Brown wrote:
> On Wed, Aug 03, 2011 at 12:16:17AM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, August 02, 2011, Kevin Hilman wrote:
>
> > > I disagree and think that both are quite realistic (mainly because they
> > > exist today, albiet mostly out of tree because no generic QoS framework
> > > exist. e.g. on OMAP, we have OMAP-specific *kernel* APIs for requesting
> > > per-device wakeup latencies, and drivers and frameworks are using them.)
> >
> > I'm sure there are frameworks using such things. I'm also sure there
> > are frameworks that don't. BTW, the "we have it out of the tree" argument is
> > not very useful, so I'd appreciate it if you didn't use it.
>
> It's useful to know if people have tried things; it doesn't mean it's
> going to be OK for mainline but it is a data point.
>
> > > In this case, the video framework (V4L2) might not want any knobs
> > > exposed to userspace because userspace simply doesn't have the knowledge
> > > to set appropriate constraints. I'm less familiar with audio, but I
> > > believe audio would be similar (sample rate, number of channels, mixing
> > > with other concurrent audio streams, etc. etc. are all known by the
> > > kernel-side code.)
>
> Yeah, that sort of stuff and also data like wakeup latencies required to
> service interrupts.
>
> > I still don't understand what's wrong with allowing user space to _add_
> > requirements. The will only override the drivers' or frameworks' requirements
> > if they are stronger, so the functionality shouldn't be hurt. They may cause
> > some more energy to be used, but if user space wants that, it's pretty much
> > fine by me.
>
> On the one hand that's true. On the other hand that just seems like
> going down a bad road where we have drivers that only work when run with
> a magic userspace that may or may not be published which is just going
> to make people miserable. I'm not sure there are many people who would
> choose to use more power without wanting some functional change so
> presumably any users would be seeking to work around some kernel problem
> and adding the user interface seems to be saying that this is OK,
> expected and a natural part of power optimization.
First off, we're doing this already (user space can block runtime PM, for
one example, because there are systems where runtime PM doesn't work
although it works on other systems with analogous hardware and pretty
much the same set of drivers).
Second, I think there are valid use cases in which user space _really_ knows
better than the kernel. I'm opposed to the idea that users shouldn't be given
control of their systems, because they may not know what they're doing.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] PM: add statistics sysfs file for suspend to ram
From: Len Brown @ 2011-08-04 19:05 UTC (permalink / raw)
To: Liu, ShuoX
Cc: Brown, Len, linux-pm@lists.linux-foundation.org, gregkh@suse.de
In-Reply-To: <6E3BC7F7C9A4BF4286DD4C043110F30B5B790E5741@shsmsx502.ccr.corp.intel.com>
> Record S3 failure time about each reason and the latest two failed
> devices' name in S3 progress.
> We can check it through /sys/power/suspend_stats.
these sound more like debugfs than sysfs things.
-Len Brown
Intel Open Source Technlogy Center
^ permalink raw reply
* Re: [PATCH 5/5] cpuidle: stop depending on pm_idle
From: Trinabh Gupta @ 2011-08-04 17:21 UTC (permalink / raw)
To: Len Brown; +Cc: Kevin Hilman, Len Brown, linux-pm, x86, linux-kernel
In-Reply-To: <619b3f9e65307529dd4bbc98efe9d2f3b632646c.1312400543.git.len.brown@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 8684 bytes --]
On Wed, Aug 3, 2011 at 12:44 PM, Len Brown <lenb@kernel.org> wrote:
> From: Len Brown <len.brown@intel.com>
>
> cpuidle users should call cpuidle_call_idle() directly
> rather than via (pm_idle)() function pointer.
>
> Architecture may choose to continue using (pm_idle)(),
> but cpuidle need not depend on it:
>
> my_arch_cpu_idle()
> ...
> if(cpuidle_call_idle())
> pm_idle();
>
> cc: x86@kernel.org
> cc: Kevin Hilman <khilman@deeprootsystems.com>
> cc: Paul Mundt <lethal@linux-sh.org>
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
> arch/arm/kernel/process.c | 4 +++-
> arch/sh/kernel/idle.c | 6 ++++--
> arch/x86/kernel/process_32.c | 4 +++-
> arch/x86/kernel/process_64.c | 4 +++-
> drivers/cpuidle/cpuidle.c | 38 ++++++++++++++++++--------------------
> include/linux/cpuidle.h | 2 ++
> 6 files changed, 33 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 5e1e541..d7ee0d4 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -30,6 +30,7 @@
> #include <linux/uaccess.h>
> #include <linux/random.h>
> #include <linux/hw_breakpoint.h>
> +#include <linux/cpuidle.h>
>
> #include <asm/cacheflush.h>
> #include <asm/leds.h>
> @@ -196,7 +197,8 @@ void cpu_idle(void)
> cpu_relax();
> } else {
> stop_critical_timings();
> - pm_idle();
> + if (cpuidle_call_idle())
>
Hi Len,
This should be cpuidle_idle_call()
> + pm_idle();
> start_critical_timings();
> /*
> * This will eventually be removed - pm_idle
> diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c
> index 425d604..9c7099e 100644
> --- a/arch/sh/kernel/idle.c
> +++ b/arch/sh/kernel/idle.c
> @@ -16,12 +16,13 @@
> #include <linux/thread_info.h>
> #include <linux/irqflags.h>
> #include <linux/smp.h>
> +#include <linux/cpuidle.h>
> #include <asm/pgalloc.h>
> #include <asm/system.h>
> #include <asm/atomic.h>
> #include <asm/smp.h>
>
> -void (*pm_idle)(void) = NULL;
> +static void (*pm_idle)(void);
>
> static int hlt_counter;
>
> @@ -100,7 +101,8 @@ void cpu_idle(void)
> local_irq_disable();
> /* Don't trace irqs off for idle */
> stop_critical_timings();
> - pm_idle();
> + if (cpuidle_call_idle())
>
Again this should be cpuidle_idle_call()
+ pm_idle();
> /*
> * Sanity check to ensure that pm_idle() returns
> * with IRQs enabled
> diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
> index a3d0dc5..7a3b651 100644
> --- a/arch/x86/kernel/process_32.c
> +++ b/arch/x86/kernel/process_32.c
> @@ -38,6 +38,7 @@
> #include <linux/uaccess.h>
> #include <linux/io.h>
> #include <linux/kdebug.h>
> +#include <linux/cpuidle.h>
>
> #include <asm/pgtable.h>
> #include <asm/system.h>
> @@ -109,7 +110,8 @@ void cpu_idle(void)
> local_irq_disable();
> /* Don't trace irqs off for idle */
> stop_critical_timings();
> - pm_idle();
> + if (cpuidle_idle_call())
> + pm_idle();
> start_critical_timings();
> }
> tick_nohz_restart_sched_tick();
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index ca6f7ab..f693e44 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -37,6 +37,7 @@
> #include <linux/uaccess.h>
> #include <linux/io.h>
> #include <linux/ftrace.h>
> +#include <linux/cpuidle.h>
>
> #include <asm/pgtable.h>
> #include <asm/system.h>
> @@ -136,7 +137,8 @@ void cpu_idle(void)
> enter_idle();
> /* Don't trace irqs off for idle */
> stop_critical_timings();
> - pm_idle();
> + if (cpuidle_idle_call())
> + pm_idle();
> start_critical_timings();
>
> /* In many cases the interrupt that ended idle
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 041df0b..d4c5423 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -25,10 +25,10 @@ DEFINE_PER_CPU(struct cpuidle_device *,
> cpuidle_devices);
>
> DEFINE_MUTEX(cpuidle_lock);
> LIST_HEAD(cpuidle_detected_devices);
> -static void (*pm_idle_old)(void);
>
> static int enabled_devices;
> static int off __read_mostly;
> +static int initialized __read_mostly;
>
> int cpuidle_disabled(void)
> {
> @@ -56,25 +56,23 @@ static int __cpuidle_register_device(struct
> cpuidle_device *dev);
> * cpuidle_idle_call - the main idle loop
> *
> * NOTE: no locks or semaphores should be used here
> + * return non-zero on failure
> */
> -static void cpuidle_idle_call(void)
> +int cpuidle_idle_call(void)
> {
> struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
> struct cpuidle_state *target_state;
> int next_state;
>
> + if (off)
> + return -ENODEV;
> +
> + if (!initialized)
> + return -ENODEV;
> +
> /* check if the device is ready */
> - if (!dev || !dev->enabled) {
> - if (pm_idle_old)
> - pm_idle_old();
> - else
> -#if defined(CONFIG_ARCH_HAS_DEFAULT_IDLE)
> - default_idle();
> -#else
> - local_irq_enable();
> -#endif
> - return;
> - }
> + if (!dev || !dev->enabled)
> + return -EBUSY;
>
> #if 0
> /* shows regressions, re-enable for 2.6.29 */
> @@ -99,7 +97,7 @@ static void cpuidle_idle_call(void)
> next_state = cpuidle_curr_governor->select(dev);
> if (need_resched()) {
> local_irq_enable();
> - return;
> + return 0;
> }
>
> target_state = &dev->states[next_state];
> @@ -124,6 +122,8 @@ static void cpuidle_idle_call(void)
> /* give the governor an opportunity to reflect on the outcome */
> if (cpuidle_curr_governor->reflect)
> cpuidle_curr_governor->reflect(dev);
> +
> + return 0;
> }
>
> /**
> @@ -131,10 +131,10 @@ static void cpuidle_idle_call(void)
> */
> void cpuidle_install_idle_handler(void)
> {
> - if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
> + if (enabled_devices) {
> /* Make sure all changes finished before we switch to new
> idle */
> smp_wmb();
> - pm_idle = cpuidle_idle_call;
> + initialized = 1;
> }
> }
>
> @@ -143,8 +143,8 @@ void cpuidle_install_idle_handler(void)
> */
> void cpuidle_uninstall_idle_handler(void)
> {
> - if (enabled_devices && pm_idle_old && (pm_idle != pm_idle_old)) {
> - pm_idle = pm_idle_old;
> + if (enabled_devices) {
> + initialized = 0;
> cpuidle_kick_cpus();
> }
> }
> @@ -440,8 +440,6 @@ static int __init cpuidle_init(void)
> if (cpuidle_disabled())
> return -ENODEV;
>
> - pm_idle_old = pm_idle;
> -
> ret = cpuidle_add_class_sysfs(&cpu_sysdev_class);
> if (ret)
> return ret;
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index b89f67d..b51629e 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -123,6 +123,7 @@ struct cpuidle_driver {
>
> #ifdef CONFIG_CPU_IDLE
> extern void disable_cpuidle(void);
> +extern int cpuidle_idle_call(void);
>
> extern int cpuidle_register_driver(struct cpuidle_driver *drv);
> struct cpuidle_driver *cpuidle_get_driver(void);
> @@ -137,6 +138,7 @@ extern void cpuidle_disable_device(struct
> cpuidle_device *dev);
>
> #else
> static inline void disable_cpuidle(void) { }
> +static inline int cpuidle_idle_call(void) { return -ENODEV; }
>
> static inline int cpuidle_register_driver(struct cpuidle_driver *drv)
> {return -ENODEV; }
> --
> 1.7.6.396.ge0613
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>
[-- Attachment #1.2: Type: text/html, Size: 11515 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