Linux Power Management development
 help / color / mirror / Atom feed
* Re: [Update][PATCH 6/10] PM / Domains: System-wide transitions support for generic domains (v5)
From: Rafael J. Wysocki @ 2011-07-11 19:39 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: linux-sh, Greg Kroah-Hartman, LKML, Linux PM mailing list
In-Reply-To: <87oc10zv4g.fsf@ti.com>

On Monday, July 11, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> [...]
> 
> >
> > There's one more case to consider, namely devices that are runtime
> > suspended, set up to wake up the system from sleep states
> > (ie. device_may_wakeup(dev) returns "true") and such that
> > genpd->active_wakeup(dev) returns "true" for them, because they need
> > to be resumed at this point too (arguably, it makes a little sense to
> > runtime suspend such devices, but that's possible in principle).
> >
> > So, IMO, the patch should look like this:
> >
> > ---
> >  drivers/base/power/domain.c |   19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> >> Index: linux-2.6/drivers/base/power/domain.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/base/power/domain.c
> > +++ linux-2.6/drivers/base/power/domain.c
> > @@ -486,6 +486,22 @@ static void pm_genpd_sync_poweroff(struc
> >  }
> >  
> >  /**
> > + * resume_needed - Check whether to resume a device before system suspend.
> > + * @dev: Device to handle.
> > + * @genpd: PM domain the device belongs to.
> > + */
> > +static bool resume_needed(struct device *dev, struct generic_pm_domain *genpd)
> > +{
> > +	bool active_wakeup;
> > +
> > +	if (!device_can_wakeup(dev))
> > +		return false;
> > +
> > +	active_wakeup = genpd->active_wakeup && genpd->active_wakeup(dev);
> > +	return device_may_wakeup(dev) ? active_wakeup : !active_wakeup;
> 
> This also returns true and causes a resume if active_wakeup = false and
> device_may_wakeup() = false.  That doesn't seem right.

This is on purpose. :-)  If active_wakeup is false, the device may signal
remote wakeup while suspended.  So, if active_wakeup is false and the device
is suspended, we have to assume that the device has been set up to signal
remote wakeup for runtime PM (if it is not suspended, attempting to resume it
will not have any effect).  Now, if device_may_wakeup() returns false in
addition to that, we may need to change the device's wakeup settings, so the
driver's callbacks should be invoked during suspend, so we're resuming the
device (we can't just leave it suspended and then invoke the driver's callbacks
in the hope they'll do the right thing).

I don't really think we can do anything else without using new device flags.

> > +}
> > +
> > +/**
> >   * pm_genpd_prepare - Start power transition of a device in a PM domain.
> >   * @dev: Device to start the transition of.
> >   *
> > @@ -519,6 +535,9 @@ static int pm_genpd_prepare(struct devic
> >  		return -EBUSY;
> >  	}
> >  
> > +	if (resume_needed(dev, genpd))
> > +		pm_runtime_resume(dev);
> > +
> >  	genpd_acquire_lock(genpd);
> >  
> >  	if (genpd->prepared_count++ == 0)
> 
> IIUC, if a device is runtime suspended when a system suspend happens,
> the device will be runtime resumed, but never re-suspended.

It will be resuspended by the pm_runtime_idle() in pm_genpd_complete()
(added by one of the new patches I've been posting for the last few days).

> Should resumes by the PM core be done with a get (and a corresponding
> put in .complete())?

Not necessarily. :-)

Thanks,
Rafael

^ permalink raw reply

* Re: PM domain using _noirq methods to "finish" pending runtime PM transistions
From: Kevin Hilman @ 2011-07-11 19:24 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: linux-pm, linux-omap
In-Reply-To: <201107092302.06618.rjw@sisk.pl>

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> Hi,
>
> On Saturday, July 09, 2011, Kevin Hilman wrote:
>> Hi Rafael,
>> 
>> So I'm now experimenting with your suggestion of using the noirq
>> callbacks of the PM domain to ensure device low-power state transitions
>> for the cases where runtime PM has been disabled from userspace (or a
>> driver has used runtime PM calls in it's suspend/resume path but they
>> have no effect since runtime PM is disabled.)
>> 
>> Before I get too far, I want to be sure I understood your suggestion
>> correctly, and run my current implemtation past you.
>> 
>> For starters, I just set the driver's noirq callbacks to point to the
>> runtime PM callbacks.
>> 
>> Then, in the PM domain's suspend_noirq, I basically do
>> 
>> 	ret = pm_generic_suspend_noirq(dev);
>> 	if (!ret && !(dev->power.runtime_status == RPM_SUSPENDED))
>> 		magic_device_power_down(dev); /* shared with pm_domain runtime PM methods */
>>                 priv->flags |= MAGIC_DEVICE_SUSPENDED;
>> 	}
>> 	return ret;
>> 
>> and in the PM domain's resume_norq, I basically do:
>> 
>> 	if ((priv->flags & MAGIC_DEVICE_SUSPENDED) &&
>> 	    !(dev->power.runtime_status == RPM_SUSPENDED)) {
>> 		priv->flags &= ~OMAP_DEVICE_SUSPENDED;
>> 		magic_device_power_up(dev);
>> 	}
>> 	return pm_generic_resume_noirq(dev);
>> 
>> Note: The MAGIC_DEVICE_SUSPENDED flag is used so resume_noirq only
>> reenables devices that were disabled by suspend_noirq so that devices
>> which were disabled by runtime PM are left untouched (similar to how
>> you've implmented generic PM domains.)
>> 
>> Since the driver's noirq callbacks point to the runtime PM callbacks
>> this all works quite well. 
>> 
>> I believe this was basically the suggestion you were recommending, right?
>
> That's correct.
>
>> However, what I need is for the driver's runtime PM callbacks not to be
>> called unconditionally, but only if the PM domain's noirq methods are
>> actually going to disable/power-down the device (e.g. it's not already
>> runtime suspended.)
>> 
>> The first obvious solution is to create new driver noirq methods that
>> check if the device is not already RPM_SUSPENDED and only then call the
>> runtime PM callbacks.   That works, but hey, it's a Friday night so I
>> decided to take it to the next level...
>> 
>> Instead of making all the drivers add new noirq methods that just
>> conditionally call the runtime PM methods, what if I just handle it in
>> the PM domain?  IOW, what if I just call pm_generic_runtime_* from the
>> PM domain's noirq methods?  e.g. call pm_generic_runtime_suspend() just
>> before magic_device_power_down() and call pm_generic_runtime_resume()
>> just after magic_device_power_up()?
>
> That should be fine.
>
>> I tested this today with a handful of our drivers that do all their PM
>> in terms of the runtime PM API (including get_sync/put_sync in their
>> suspend path) and they all work as expected without modification.
>> 
>> I know it's not much to add a couple new callbacks to each of these
>> drivers, but if I can handle it at the PM domain level, I'd rather allow
>> the drivers to stay simple.
>> 
>> What do you think?
>
> I don't see anything wrong with your approach. :-)

Thanks.

> PS
> I wonder what you think about this patch:
> https://patchwork.kernel.org/patch/959672/

I responded to that thread.

Kevin

^ permalink raw reply

* Re: pm_runtime_suspended() can be false if RPM_SUSPENDED
From: Kevin Hilman @ 2011-07-11 19:24 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: linux-pm, Linux OMAP
In-Reply-To: <201107091219.06089.rjw@sisk.pl>

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> Hi,
>
> On Saturday, July 09, 2011, Kevin Hilman wrote:
>> Hi Rafael,
>> 
>> Just curious why pm_runtime_suspended() requires the device to be
>> enabled for it to return true:
>> 
>> static inline bool pm_runtime_suspended(struct device *dev)
>> {
>> 	return dev->power.runtime_status == RPM_SUSPENDED
>> 		&& !dev->power.disable_depth;
>> }
>> 
>> I must be misunderstanding something, but I would consider a device that
>> has been runtime suspended before runtime PM was disabled to still be
>> runtime suspended.
>
> The problem is that while the runtime PM of the device is disabled
> (ie. dev->power.disable_depth > 0), its status may be switched from
> RPM_SUSPENDED to RPM_ACTIVE on the fly, using pm_runtime_set_active()
> (and the other way around) and it doesn't reflect the real status in
> principle.  

OK, I guess this is the root of the confusion.  Namely, that
dev->power.runtime_status doesn't necessarily reflect the actual device
state.

> So it was a tough choice what to do about that and I decided
> to go with returning false (in many cases runtime PM disabled means the
> device is always operational).

And with your recent changes (pm_runtime_disable() in suspend path), it
also be very common that 

>> I just noticed this when testing with your pm-domains branch.  when I
>> noticed that an 'if (pm_runtime_suspended(dev))' check in my PM domain's
>> ->suspend_noirq() was always failing since it's after the PM core calls
>> pm_runtime_disable().  I had to change my PM domain code to only check
>> dev->power.runtime_status for it to work.
>
> Well, at this point I'm kind of cautious about changing pm_runtime_suspended(),
> so perhaps we need a separate callback returnig true in the status is
> RPM_SUSPENDED regardless of the value of power.disable_depth, like
> pm_runtime_status_suspended() or something similar.

OK, but documentation would probably be needed to describe why you might
use one vs. the other.

However, based on the pm_runtime_set_active() problem you mentioned
above, I'm not sure this will help either, since what the PM domain's
noirq callback will want to do will be based on the actual device
hardware state, not on the PM core's view of the device state.

Kevin

^ permalink raw reply

* Re: [RFC] Unprepare callback for cpuidle_device
From: Vaidyanathan Srinivasan @ 2011-07-11 19:08 UTC (permalink / raw)
  To: asinghal; +Cc: linux-pm, johlstei
In-Reply-To: <473338c2d56302337f83871ce1c201e4.squirrel@www.codeaurora.org>

* asinghal@codeaurora.org <asinghal@codeaurora.org> [2011-07-11 10:26:56]:

> hello Deepthi,
>           please see my replies inline:
> 
> 
> > Hi Amar,
> >
> > On Friday 08 July 2011 01:22 AM, asinghal@codeaurora.org wrote:
> >> Hello Trinabh,
> >>               i cannot use the enter callback due to the following
> >> reason:
> >>
> >> the residency calculation(tick)nohz_get_sleep_length) and the idle state
> >> selection happens in the menu governor. The enter callback is called
> >> with
> >> the selected state.
> >
> >   One would first execute prepare then call select and enter .
> >   So in the newer proposed code, there is no prepare routine. One would
> >   just execute select() and then enter() (Prepare functionality is part of
> > the
> >   enter routine itself) Is it not possible to cancel the timer,
> >   calculate the execute nohz_get_sleep in enter routine again,
> >   then select the idle state depending on the time . Automatically promote
> > or demote
> >   idle state based on the latest value returned in the driver ?
> >
> Cancelling the timer and calculating the sleep length again in the enter
> callback is possible; but what does not make sense is calling the select
> routine again ; definitely the select routine of the governor needs to be
> called only once.  And actually, the sleep length is calculated in the

Can you promote the idle state within the driver based on the new
information provided by tick_nohz_get_sleep_length() after canceling
the timer?  This will be a hack... but better than calling select()
again.  You are right, we need to design in such a way that select()
makes the right choice.

> function tick_nohz_stop_sched_tick.( so shld the prepare callback be moved
> before that in cpu_idle ??)

The prepare callback is in the right place now... if you cancel the
timer in prepare, then subsequent select() which calls
tick_nohz_get_sleep_length() will get the correct idle time.  Your
problem is in restarting the timer in case we abort the idle.  The
current place of prepare is fine and more over we are heading in the
direction to deprecate the prepare itself.

> I am looking for a nice way to cancel and restart the high resolution
> timers in the idle code; even if that means rearranging the cpu_idle code.

Slight difference, you can cancel and restart within the driver, the
problem is that you want the ->select() to be executed _after_
canceling your hrtimer because it will predict idle much shorter
otherwise.  This is where the cpuidle framework should help.

> Another way i was looking to solve this issue was add deferrable feature
> to HR timers; if someone has thoughts on that please chime in.

This seems to be a much better idea, where the
tick_nohz_get_sleep_length() can automatically skip your deferred
hrtimer with a hope that it will be canceled.  We don't have
a mechanism to actually defer it.

You can try to add deferred flag in hrtimer_mode { } similar to how
pinned was added.  Enhance tick_nohz_get_sleep_length() to skip over
deferred hrtimer as well.

But the number of users for this feature will be very little to
justify the complexity.

--Vaidy

^ permalink raw reply

* Re: [RFC] Unprepare callback for cpuidle_device
From: asinghal @ 2011-07-11 17:26 UTC (permalink / raw)
  To: Deepthi Dharwar; +Cc: linux-pm, asinghal, johlstei
In-Reply-To: <4E170010.2000403@linux.vnet.ibm.com>

hello Deepthi,
          please see my replies inline:


> Hi Amar,
>
> On Friday 08 July 2011 01:22 AM, asinghal@codeaurora.org wrote:
>> Hello Trinabh,
>>               i cannot use the enter callback due to the following
>> reason:
>>
>> the residency calculation(tick)nohz_get_sleep_length) and the idle state
>> selection happens in the menu governor. The enter callback is called
>> with
>> the selected state.
>
>   One would first execute prepare then call select and enter .
>   So in the newer proposed code, there is no prepare routine. One would
>   just execute select() and then enter() (Prepare functionality is part of
> the
>   enter routine itself) Is it not possible to cancel the timer,
>   calculate the execute nohz_get_sleep in enter routine again,
>   then select the idle state depending on the time . Automatically promote
> or demote
>   idle state based on the latest value returned in the driver ?
>
Cancelling the timer and calculating the sleep length again in the enter
callback is possible; but what does not make sense is calling the select
routine again ; definitely the select routine of the governor needs to be
called only once.  And actually, the sleep length is calculated in the
function tick_nohz_stop_sched_tick.( so shld the prepare callback be moved
before that in cpu_idle ??)

I am looking for a nice way to cancel and restart the high resolution
timers in the idle code; even if that means rearranging the cpu_idle code.

Another way i was looking to solve this issue was add deferrable feature
to HR timers; if someone has thoughts on that please chime in.

thanks,
amar




>> So cancelling the hrtimer that would affect the residency value
>> calculated
>> in the menu governor, in the enter callback is not possible. The timer
>> needs to be cancelled before the select call is made.
>>
>> thanks,
>> amar
>>
>>
>>
>>> On 07/06/2011 04:23 PM, asinghal@codeaurora.org wrote:
>>>> We plan to use high resolution timers in one of our modules, with the
>>>> requirement that we cancel these timers when the cpu goes idle and
>>>> restart
>>>> them when the cpu comes out of idle.
>>>>
>>>> We are cancelling the timers in cpuidle prepare callback. The problem
>>>> is
>>>> that if the need_resched() call in drivers/cpuidle/cpuidle.c returns
>>>> true,
>>>> how do we restart the timer? If the call returns false, we can restart
>>>> the
>>>> timer in the cpuidle enter callback.
>>>
>>> Hi Amar,
>>>
>>> I think you should not use cpuidle prepare callback at all. It may be
>>> removed soon (see https://lkml.org/lkml/2011/6/6/261) and I think
>>> there are better ways to achieve what you are trying to do.
>>>
>>> I think everything should go into the enter routines (the idle routines
>>> provided by the driver). That way you would not have to worry about
>>> need_resched() in cpuidle.c. Also it would be a cleaner implementation
>>> as you wouldn't touch generic cpuidle code.
>>>
>>>>
>>>> The solution to the problem that we have in mind is adding an
>>>> unprepare
>>>> callback to the cpuidle_device struct, and calling it if
>>>> needs_resched()
>>>> returns true. Another option is to implement deferred timers for
>>>> hrtimers.
>>>> Which of the two options is the better solution, or is there another
>>>> feasible alternative?
>>>
>>> As i said, everything should go inside enter routine and
>>> you wouldn't have to use/implement prepare/unprepare callbacks.
>>>
>>> Thanks
>>> -Trinabh
>>>
>>
>>
>> _______________________________________________
>> 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: [Update][PATCH 6/10] PM / Domains: System-wide transitions support for generic domains (v5)
From: Kevin Hilman @ 2011-07-11 15:37 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: linux-sh, Greg Kroah-Hartman, LKML, Linux PM mailing list
In-Reply-To: <201107091615.38915.rjw@sisk.pl>

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

[...]

>
> There's one more case to consider, namely devices that are runtime
> suspended, set up to wake up the system from sleep states
> (ie. device_may_wakeup(dev) returns "true") and such that
> genpd->active_wakeup(dev) returns "true" for them, because they need
> to be resumed at this point too (arguably, it makes a little sense to
> runtime suspend such devices, but that's possible in principle).
>
> So, IMO, the patch should look like this:
>
> ---
>  drivers/base/power/domain.c |   19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
>> Index: linux-2.6/drivers/base/power/domain.c
> ===================================================================
> --- linux-2.6.orig/drivers/base/power/domain.c
> +++ linux-2.6/drivers/base/power/domain.c
> @@ -486,6 +486,22 @@ static void pm_genpd_sync_poweroff(struc
>  }
>  
>  /**
> + * resume_needed - Check whether to resume a device before system suspend.
> + * @dev: Device to handle.
> + * @genpd: PM domain the device belongs to.
> + */
> +static bool resume_needed(struct device *dev, struct generic_pm_domain *genpd)
> +{
> +	bool active_wakeup;
> +
> +	if (!device_can_wakeup(dev))
> +		return false;
> +
> +	active_wakeup = genpd->active_wakeup && genpd->active_wakeup(dev);
> +	return device_may_wakeup(dev) ? active_wakeup : !active_wakeup;

This also returns true and causes a resume if active_wakeup = false and
device_may_wakeup() = false.  That doesn't seem right.

> +}
> +
> +/**
>   * pm_genpd_prepare - Start power transition of a device in a PM domain.
>   * @dev: Device to start the transition of.
>   *
> @@ -519,6 +535,9 @@ static int pm_genpd_prepare(struct devic
>  		return -EBUSY;
>  	}
>  
> +	if (resume_needed(dev, genpd))
> +		pm_runtime_resume(dev);
> +
>  	genpd_acquire_lock(genpd);
>  
>  	if (genpd->prepared_count++ == 0)

IIUC, if a device is runtime suspended when a system suspend happens,
the device will be runtime resumed, but never re-suspended.

Should resumes by the PM core be done with a get (and a corresponding
put in .complete())?

Kevin

^ permalink raw reply

* Re: [PATCH v2] Input: enable i8042-level wakeup control
From: Daniel Drake @ 2011-07-11 13:22 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: dilinger, dtor, linux-pm, dmitry.torokhov, linux-input
In-Reply-To: <201107102300.14064.rjw@sisk.pl>

Hi Rafael, many thanks for looking at this.

2011/7/10 Rafael J. Wysocki <rjw@sisk.pl>:
>> @@ -1602,6 +1611,15 @@ static int input_dev_resume(struct device *dev)
>>  {
>>       struct input_dev *input_dev = to_input_dev(dev);
>>
>> +     /*
>> +      * If this device is a child of serio, which is a child of i8042, and
>> +      * i8042 wakeup is enabled (i.e. this input device was not suspended),
>> +      * do nothing.
>> +      */
>> +     if (dev->parent && dev->parent->parent
>> +                     && device_may_wakeup(dev->parent->parent))
>> +             return 0;
>> +
>
> You check exactly the same condition in two places with very similar comments.
> I'd put it into a bool function and add a kerneldoc description to it instead.

OK, I agree. I was hoping that you'd be able to point out a better way
of doing this though - I think you'd agree that this code is not very
nice. But maybe explaining it better and hiding it away in its own
function is the best approach we have.

It is a strange case, because the device hierarchy is as follows:

i8042 -> serio -> input

Yet the kernel sees the i8042 and input devices as somewhat
independent devices on different busses, so each one has its own
independent suspend/resume implementation called from the PM layer.
And in this particular case, I need to make the i8042 controller
communicate the fact that its grandchild input device should not be
suspended or reset.

> The fact that you need provide several empty definitions of
> i8042_platform_suspend() is a bit worrisome.  Have you considered using a
> different approach?

This seems quite the norm in i8042-land - those .h files already
include a number of empty functions that were presumably added just
because a small selection of the other supported arches needed to do
something. Nevertheless I'd be happy to convert these drivers to a new
"struct i8042_platform_ops" type system if that helps with the merge
of this patch.

Thanks,
Daniel

^ permalink raw reply

* Re: Runtime PM discussion notes
From: Tony Lindgren @ 2011-07-11 11:32 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-pm, linux-omap
In-Reply-To: <20110711112619.GH5092@opensource.wolfsonmicro.com>

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 04:21]:
> On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:
> 
> > > Right, but it can be interesting to tell the PMIC that we went into this
> > > mode.  Possibly cpuidle will end up doing this as a result of signals
> > > generated as the CPU core goes down, but at that point it's just s2ram
> > > by another name.
> 
> > All PMIC devices should be shut down when not in use, so I don't know
> > what else you would configure in the PMIC. Maybe you have something else
> > there to configure? Just curious what kind of mess you have to deal with
> > compared to the mess I need to deal with :)
> 
> The interesting bits are things like being able to kill lots of the SoC
> core supplies when the RAM is in retention mode - the CPU needs to go
> through its shutdown procedures.

I see. I've seen cases these are pre-programmed to the PMIC and then
automatically triggered based on some event like WFI.
 
> > Also, hitting deeper sleep states from idle is not same as suspend to ram.
> > With suspend to ram the system timer is killed while timers behave in a
> > normal way when hitting deeper sleep states from idle.
> 
> Actually, it just occurred to me that if we're waiting for a system
> timer and can hand that off to a suitable timer in the PMIC then we can
> do a suspend to RAM for the deep idle state from the hardware point of
> view.

Cool, it would be nice to have a Linux generic way for programming a
separate hardware wake-up timer. Not RTC, but some more accurate timer that
might be too slow to access for general purpose usage.

Regards,

Tony

^ permalink raw reply

* Re: Runtime PM discussion notes
From: Mark Brown @ 2011-07-11 11:26 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-pm, linux-omap
In-Reply-To: <20110711111424.GV5783@atomide.com>

On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:

> > Right, but it can be interesting to tell the PMIC that we went into this
> > mode.  Possibly cpuidle will end up doing this as a result of signals
> > generated as the CPU core goes down, but at that point it's just s2ram
> > by another name.

> All PMIC devices should be shut down when not in use, so I don't know
> what else you would configure in the PMIC. Maybe you have something else
> there to configure? Just curious what kind of mess you have to deal with
> compared to the mess I need to deal with :)

The interesting bits are things like being able to kill lots of the SoC
core supplies when the RAM is in retention mode - the CPU needs to go
through its shutdown procedures.

> Also, hitting deeper sleep states from idle is not same as suspend to ram.
> With suspend to ram the system timer is killed while timers behave in a
> normal way when hitting deeper sleep states from idle.

Actually, it just occurred to me that if we're waiting for a system
timer and can hand that off to a suitable timer in the PMIC then we can
do a suspend to RAM for the deep idle state from the hardware point of
view.

^ permalink raw reply

* Re: Runtime PM discussion notes
From: Tony Lindgren @ 2011-07-11 11:14 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-pm, linux-omap
In-Reply-To: <20110711110435.GF5092@opensource.wolfsonmicro.com>

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:
> On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:
> 
> > > At least the Nexus S doesn't implmeent any of the deep idle
> > > infrastructure.  However, I'd expect that you can achieve some power
> > > saving from entering system suspend as if *everything* is off then the
> > > PMIC can be suspended which can enable additional power savings.  Unless
> > > I'm missing something that'd be hard to hit with cpuidle only stuff.
> 
> > You should be able to hit the same states from idle no problem. At that
> > point the only things on are memory in retention and some wake-up timer.
> > Even the timer could be off if you have hardware wake-up events, but then
> > system timer won't work the noral way naturally.
> 
> Right, but it can be interesting to tell the PMIC that we went into this
> mode.  Possibly cpuidle will end up doing this as a result of signals
> generated as the CPU core goes down, but at that point it's just s2ram
> by another name.

All PMIC devices should be shut down when not in use, so I don't know
what else you would configure in the PMIC. Maybe you have something else
there to configure? Just curious what kind of mess you have to deal with
compared to the mess I need to deal with :)

Also, hitting deeper sleep states from idle is not same as suspend to ram.
With suspend to ram the system timer is killed while timers behave in a
normal way when hitting deeper sleep states from idle.
 
> > The only way power down everything in suspend to disk :) Most PMICs have
> > some functionality always on so they can charge the battery when it's
> > empty.
> 
> With some PMICs the truly always on functionality is *very* minimal and
> doesn't include chargers, it can be pretty much limited to wake sources
> (including power status changes which might start charging if power
> appears).

Sure.

Tony

^ permalink raw reply

* Re: Runtime PM discussion notes
From: Mark Brown @ 2011-07-11 11:04 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-pm, linux-omap
In-Reply-To: <20110711095812.GT5783@atomide.com>

On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:

> > At least the Nexus S doesn't implmeent any of the deep idle
> > infrastructure.  However, I'd expect that you can achieve some power
> > saving from entering system suspend as if *everything* is off then the
> > PMIC can be suspended which can enable additional power savings.  Unless
> > I'm missing something that'd be hard to hit with cpuidle only stuff.

> You should be able to hit the same states from idle no problem. At that
> point the only things on are memory in retention and some wake-up timer.
> Even the timer could be off if you have hardware wake-up events, but then
> system timer won't work the noral way naturally.

Right, but it can be interesting to tell the PMIC that we went into this
mode.  Possibly cpuidle will end up doing this as a result of signals
generated as the CPU core goes down, but at that point it's just s2ram
by another name.

> The only way power down everything in suspend to disk :) Most PMICs have
> some functionality always on so they can charge the battery when it's
> empty.

With some PMICs the truly always on functionality is *very* minimal and
doesn't include chargers, it can be pretty much limited to wake sources
(including power status changes which might start charging if power
appears).

^ permalink raw reply

* Re: Runtime PM discussion notes
From: Tony Lindgren @ 2011-07-11  9:58 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-pm, linux-omap
In-Reply-To: <20110709040622.GH26900@sirena.org.uk>

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:
> On Tue, Jun 28, 2011 at 01:47:47PM -0600, Paul Walmsley wrote:
> > On Fri, 24 Jun 2011, Arve Hj?nnev?g wrote:
> > > On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
> 
> > > > "On the hardware that shipped we enter the same power state from idle
> > > > and suspend, so the only power savings we get from suspend that we
> > > > don't get in idle is from not respecting the scheduler and timers."
> 
> > > This is no longer the case. Both the Nexus-S and Xoom enter lower
> > > power states from suspend than idle.
> 
> > Just out of curiosity, is that due to some kind of hardware limitation on 
> > those platforms, or is it because the software infrastructure for dynamic 
> > deep idle hasn't been fully implemented in that subarchitecture code?
> 
> At least the Nexus S doesn't implmeent any of the deep idle
> infrastructure.  However, I'd expect that you can achieve some power
> saving from entering system suspend as if *everything* is off then the
> PMIC can be suspended which can enable additional power savings.  Unless
> I'm missing something that'd be hard to hit with cpuidle only stuff.

You should be able to hit the same states from idle no problem. At that
point the only things on are memory in retention and some wake-up timer.
Even the timer could be off if you have hardware wake-up events, but then
system timer won't work the noral way naturally.

The only way power down everything in suspend to disk :) Most PMICs have
some functionality always on so they can charge the battery when it's
empty.

Regards,

Tony

^ permalink raw reply

* Re: [PATCH] PM: Reintroduce dropped call to check_wakeup_irqs
From: Rafael J. Wysocki @ 2011-07-11  8:46 UTC (permalink / raw)
  To: Colin Cross; +Cc: linux-pm, Greg Kroah-Hartman, Thomas Gleixner, linux-kernel
In-Reply-To: <1310342666-2493-1-git-send-email-ccross@android.com>

On Monday, July 11, 2011, Colin Cross wrote:
> Patch 2e711c04dbbf7a7732a3f7073b1fc285d12b369d
> (PM: Remove sysdev suspend, resume and shutdown operations)
> deleted sysdev_suspend, which was being relied on to call
> check_wakeup_irqs in suspend.  If check_wakeup_irqs is not
> called, wake interrupts that are pending when suspend is
> entered may be lost.  It also breaks IRQCHIP_MASK_ON_SUSPEND,
> which is handled in check_wakeup_irqs.
> 
> This patch adds a call to check_wakeup_irqs in syscore_suspend,
> similar to what was deleted in sysdev_suspend.
> 
> CC: Rafael J. Wysocki <rjw@sisk.pl>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Greg Kroah-Hartman <gregkh@suse.de>
> Signed-off-by: Colin Cross <ccross@android.com>

Thanks a lot for the patch and sorry for the breakage.

I'll push it to Linus later today (hopefully, that's not to late for 3.0).

Thanks,
Rafael


> ---
>  drivers/base/syscore.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/base/syscore.c b/drivers/base/syscore.c
> index c126db3..9b8bbe0 100644
> --- a/drivers/base/syscore.c
> +++ b/drivers/base/syscore.c
> @@ -9,6 +9,7 @@
>  #include <linux/syscore_ops.h>
>  #include <linux/mutex.h>
>  #include <linux/module.h>
> +#include <linux/interrupt.h>
>  
>  static LIST_HEAD(syscore_ops_list);
>  static DEFINE_MUTEX(syscore_ops_lock);
> @@ -48,6 +49,13 @@ int syscore_suspend(void)
>  	struct syscore_ops *ops;
>  	int ret = 0;
>  
> +	pr_debug("Checking wake-up interrupts\n");
> +
> +	/* Return error code if there are any wake-up interrupts pending */
> +	ret = check_wakeup_irqs();
> +	if (ret)
> +		return ret;
> +
>  	WARN_ONCE(!irqs_disabled(),
>  		"Interrupts enabled before system core suspend.\n");
>  
> 

^ permalink raw reply

* Re: [PATCH]mmc: remove MMC bus legacy suspend/resume method
From: Rafael J. Wysocki @ 2011-07-11  8:45 UTC (permalink / raw)
  To: Chuanxiao Dong; +Cc: linux-pm, linux-mmc
In-Reply-To: <20110711061726.GA19185@intel.com>

On Monday, July 11, 2011, Chuanxiao Dong wrote:
> MMC bus suspend/resume was using legacy method. In system entering
> S3 patch, the suspend/resume function cannot be called since MMC
> bus also implemented the new suspend/resume method (dev_pm_ops struct).
> So if dev_pm_ops is defined but .suspend/.resume callbacks not implemented,
> mmc_queue will not be suspended/resumed.
> 
> This patch will remove the legacy suspend/resume method and change to
> use the new method totally.
> 
> Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
> ---
>  drivers/mmc/card/block.c |    2 +-
>  drivers/mmc/core/bus.c   |   24 +++++++++++-------------
>  include/linux/mmc/card.h |    2 +-
>  3 files changed, 13 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 38d0149..224f1bb 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1549,7 +1549,7 @@ static void mmc_blk_remove(struct mmc_card *card)
>  }
>  
>  #ifdef CONFIG_PM
> -static int mmc_blk_suspend(struct mmc_card *card, pm_message_t state)
> +static int mmc_blk_suspend(struct mmc_card *card)
>  {
>  	struct mmc_blk_data *part_md;
>  	struct mmc_blk_data *md = mmc_get_drvdata(card);
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> index 393d817..03be6d0 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -120,14 +120,14 @@ static int mmc_bus_remove(struct device *dev)
>  	return 0;
>  }
>  
> -static int mmc_bus_suspend(struct device *dev, pm_message_t state)
> +static int mmc_bus_suspend(struct device *dev)
>  {
>  	struct mmc_driver *drv = to_mmc_driver(dev->driver);
>  	struct mmc_card *card = mmc_dev_to_card(dev);
>  	int ret = 0;
>  
>  	if (dev->driver && drv->suspend)
> -		ret = drv->suspend(card, state);
> +		ret = drv->suspend(card);
>  	return ret;
>  }
>  
> @@ -163,20 +163,20 @@ static int mmc_runtime_idle(struct device *dev)
>  	return pm_runtime_suspend(dev);
>  }
>  
> +#else /* !CONFIG_PM_RUNTIME */
> +#define mmc_runtime_suspend	NULL
> +#define mmc_runtime_resume	NULL
> +#define mmc_runtime_idle	NULL
> +#endif /* !CONFIG_PM_RUNTIME */
> +
>  static const struct dev_pm_ops mmc_bus_pm_ops = {
>  	.runtime_suspend	= mmc_runtime_suspend,
>  	.runtime_resume		= mmc_runtime_resume,
>  	.runtime_idle		= mmc_runtime_idle,
> +	.suspend		= mmc_bus_suspend,
> +	.resume			= mmc_bus_resume,
>  };

Please define hibernate callbacks too, for example by using the
SIMPLE_DEV_PM_OPS() convenience macro, defined in include/linux/pm.h.

Thanks,
Rafael


> -#define MMC_PM_OPS_PTR	(&mmc_bus_pm_ops)
> -
> -#else /* !CONFIG_PM_RUNTIME */
> -
> -#define MMC_PM_OPS_PTR	NULL
> -
> -#endif /* !CONFIG_PM_RUNTIME */
> -
>  static struct bus_type mmc_bus_type = {
>  	.name		= "mmc",
>  	.dev_attrs	= mmc_dev_attrs,
> @@ -184,9 +184,7 @@ static struct bus_type mmc_bus_type = {
>  	.uevent		= mmc_bus_uevent,
>  	.probe		= mmc_bus_probe,
>  	.remove		= mmc_bus_remove,
> -	.suspend	= mmc_bus_suspend,
> -	.resume		= mmc_bus_resume,
> -	.pm		= MMC_PM_OPS_PTR,
> +	.pm		= &mmc_bus_pm_ops,
>  };
>  
>  int mmc_register_bus(void)
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index b460fc2..978f395 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -393,7 +393,7 @@ struct mmc_driver {
>  	struct device_driver drv;
>  	int (*probe)(struct mmc_card *);
>  	void (*remove)(struct mmc_card *);
> -	int (*suspend)(struct mmc_card *, pm_message_t);
> +	int (*suspend)(struct mmc_card *);
>  	int (*resume)(struct mmc_card *);
>  };
>  
> 

^ permalink raw reply

* [PATCH]mmc: remove MMC bus legacy suspend/resume method
From: Chuanxiao Dong @ 2011-07-11  6:17 UTC (permalink / raw)
  To: linux-mmc, linux-pm

MMC bus suspend/resume was using legacy method. In system entering
S3 patch, the suspend/resume function cannot be called since MMC
bus also implemented the new suspend/resume method (dev_pm_ops struct).
So if dev_pm_ops is defined but .suspend/.resume callbacks not implemented,
mmc_queue will not be suspended/resumed.

This patch will remove the legacy suspend/resume method and change to
use the new method totally.

Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
---
 drivers/mmc/card/block.c |    2 +-
 drivers/mmc/core/bus.c   |   24 +++++++++++-------------
 include/linux/mmc/card.h |    2 +-
 3 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 38d0149..224f1bb 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1549,7 +1549,7 @@ static void mmc_blk_remove(struct mmc_card *card)
 }
 
 #ifdef CONFIG_PM
-static int mmc_blk_suspend(struct mmc_card *card, pm_message_t state)
+static int mmc_blk_suspend(struct mmc_card *card)
 {
 	struct mmc_blk_data *part_md;
 	struct mmc_blk_data *md = mmc_get_drvdata(card);
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 393d817..03be6d0 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -120,14 +120,14 @@ static int mmc_bus_remove(struct device *dev)
 	return 0;
 }
 
-static int mmc_bus_suspend(struct device *dev, pm_message_t state)
+static int mmc_bus_suspend(struct device *dev)
 {
 	struct mmc_driver *drv = to_mmc_driver(dev->driver);
 	struct mmc_card *card = mmc_dev_to_card(dev);
 	int ret = 0;
 
 	if (dev->driver && drv->suspend)
-		ret = drv->suspend(card, state);
+		ret = drv->suspend(card);
 	return ret;
 }
 
@@ -163,20 +163,20 @@ static int mmc_runtime_idle(struct device *dev)
 	return pm_runtime_suspend(dev);
 }
 
+#else /* !CONFIG_PM_RUNTIME */
+#define mmc_runtime_suspend	NULL
+#define mmc_runtime_resume	NULL
+#define mmc_runtime_idle	NULL
+#endif /* !CONFIG_PM_RUNTIME */
+
 static const struct dev_pm_ops mmc_bus_pm_ops = {
 	.runtime_suspend	= mmc_runtime_suspend,
 	.runtime_resume		= mmc_runtime_resume,
 	.runtime_idle		= mmc_runtime_idle,
+	.suspend		= mmc_bus_suspend,
+	.resume			= mmc_bus_resume,
 };
 
-#define MMC_PM_OPS_PTR	(&mmc_bus_pm_ops)
-
-#else /* !CONFIG_PM_RUNTIME */
-
-#define MMC_PM_OPS_PTR	NULL
-
-#endif /* !CONFIG_PM_RUNTIME */
-
 static struct bus_type mmc_bus_type = {
 	.name		= "mmc",
 	.dev_attrs	= mmc_dev_attrs,
@@ -184,9 +184,7 @@ static struct bus_type mmc_bus_type = {
 	.uevent		= mmc_bus_uevent,
 	.probe		= mmc_bus_probe,
 	.remove		= mmc_bus_remove,
-	.suspend	= mmc_bus_suspend,
-	.resume		= mmc_bus_resume,
-	.pm		= MMC_PM_OPS_PTR,
+	.pm		= &mmc_bus_pm_ops,
 };
 
 int mmc_register_bus(void)
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index b460fc2..978f395 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -393,7 +393,7 @@ struct mmc_driver {
 	struct device_driver drv;
 	int (*probe)(struct mmc_card *);
 	void (*remove)(struct mmc_card *);
-	int (*suspend)(struct mmc_card *, pm_message_t);
+	int (*suspend)(struct mmc_card *);
 	int (*resume)(struct mmc_card *);
 };
 
-- 
1.7.3.4

^ permalink raw reply related

* [PATCH] PM: Reintroduce dropped call to check_wakeup_irqs
From: Colin Cross @ 2011-07-11  0:04 UTC (permalink / raw)
  To: linux-pm; +Cc: Thomas Gleixner, Greg Kroah-Hartman, linux-kernel, Colin Cross

Patch 2e711c04dbbf7a7732a3f7073b1fc285d12b369d
(PM: Remove sysdev suspend, resume and shutdown operations)
deleted sysdev_suspend, which was being relied on to call
check_wakeup_irqs in suspend.  If check_wakeup_irqs is not
called, wake interrupts that are pending when suspend is
entered may be lost.  It also breaks IRQCHIP_MASK_ON_SUSPEND,
which is handled in check_wakeup_irqs.

This patch adds a call to check_wakeup_irqs in syscore_suspend,
similar to what was deleted in sysdev_suspend.

CC: Rafael J. Wysocki <rjw@sisk.pl>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Colin Cross <ccross@android.com>
---
 drivers/base/syscore.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/base/syscore.c b/drivers/base/syscore.c
index c126db3..9b8bbe0 100644
--- a/drivers/base/syscore.c
+++ b/drivers/base/syscore.c
@@ -9,6 +9,7 @@
 #include <linux/syscore_ops.h>
 #include <linux/mutex.h>
 #include <linux/module.h>
+#include <linux/interrupt.h>
 
 static LIST_HEAD(syscore_ops_list);
 static DEFINE_MUTEX(syscore_ops_lock);
@@ -48,6 +49,13 @@ int syscore_suspend(void)
 	struct syscore_ops *ops;
 	int ret = 0;
 
+	pr_debug("Checking wake-up interrupts\n");
+
+	/* Return error code if there are any wake-up interrupts pending */
+	ret = check_wakeup_irqs();
+	if (ret)
+		return ret;
+
 	WARN_ONCE(!irqs_disabled(),
 		"Interrupts enabled before system core suspend.\n");
 
-- 
1.7.4.1

^ permalink raw reply related

* Re: [PATCH v2] Input: enable i8042-level wakeup control
From: Rafael J. Wysocki @ 2011-07-10 21:00 UTC (permalink / raw)
  To: Daniel Drake; +Cc: dilinger, dtor, linux-pm, dmitry.torokhov, linux-input
In-Reply-To: <20110709211321.5FE139D401C@zog.reactivated.net>

Hi,

On Saturday, July 09, 2011, Daniel Drake wrote:
> The OLPC XO laptop is able to use the PS/2 controller as a wakeup source.
> When used as a wakeup source, the key press/mouse motion must not be lost.
> 
> Add infrastructure to allow controllers to be marked as wakeup-capable,
> and avoid doing power control/reset on the i8042/serio/input devices when
> running in this mode. Default behaviour is unchanged - hardware platforms
> must explicitly enable this functionality if they can support it.
> 
> Signed-off-by: Daniel Drake <dsd@laptop.org>
> ---
>  drivers/input/input.c                 |   18 +++++++++++
>  drivers/input/serio/i8042-io.h        |    4 ++
>  drivers/input/serio/i8042-ip22io.h    |    4 ++
>  drivers/input/serio/i8042-jazzio.h    |    4 ++
>  drivers/input/serio/i8042-ppcio.h     |    4 ++
>  drivers/input/serio/i8042-snirm.h     |    4 ++
>  drivers/input/serio/i8042-sparcio.h   |    4 ++
>  drivers/input/serio/i8042-x86ia64io.h |    4 ++
>  drivers/input/serio/i8042.c           |   54 ++++++++++++++++++++++++++++++--
>  drivers/input/serio/serio.c           |   28 ++++++++++++++--
>  10 files changed, 120 insertions(+), 8 deletions(-)
> 
> A followup patch will come soon, hooking this into OLPC's embedded controller:
> http://dev.laptop.org/~dsd/20110114/0015-i8042-Enable-OLPC-s-EC-based-i8042-wakeup-control.patch
> The underlying infrastructure for this work has now been merged in linux-next.
> 
> On last submission, Dmitry was worried about this functionality not working
> at all on other platforms. I agree, it will only work where the hardware
> has been specifically designed with this consideration. v2 of the patch
> therefore removes the module param option, meaning that it will only be
> activated on platforms that explicitly enable it at the code level.
> 
> v2 also performs a more extensive job. We avoid resetting the device
> at the input_device level during suspend/resume - but this is ugly. Rafael,
> is there a better way? Please see the input.c hunks. We also disable
> i8042 interrupts when going into suspend, to avoid races handling interrupts
> in the wrong order during resume.
> 
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index da38d97..81a87bc 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -1588,6 +1588,15 @@ static int input_dev_suspend(struct device *dev)
>  {
>  	struct input_dev *input_dev = to_input_dev(dev);
>  
> +	/*
> +	 * If this device is a child of serio, which is a child of i8042, and
> +	 * i8042 wakeup is enabled (i.e. this input device is not being
> +	 * suspended), do nothing.
> +	 */
> +	if (dev->parent && dev->parent->parent
> +			&& device_may_wakeup(dev->parent->parent))
> +		return 0;
> +
>  	mutex_lock(&input_dev->mutex);
>  
>  	if (input_dev->users)
> @@ -1602,6 +1611,15 @@ static int input_dev_resume(struct device *dev)
>  {
>  	struct input_dev *input_dev = to_input_dev(dev);
>  
> +	/*
> +	 * If this device is a child of serio, which is a child of i8042, and
> +	 * i8042 wakeup is enabled (i.e. this input device was not suspended),
> +	 * do nothing.
> +	 */
> +	if (dev->parent && dev->parent->parent
> +			&& device_may_wakeup(dev->parent->parent))
> +		return 0;
> +

You check exactly the same condition in two places with very similar comments.
I'd put it into a bool function and add a kerneldoc description to it instead.

>  	input_reset_device(input_dev);
>  
>  	return 0;
> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
> index 5d48bb6..296633c 100644
> --- a/drivers/input/serio/i8042-io.h
> +++ b/drivers/input/serio/i8042-io.h
> @@ -92,4 +92,8 @@ static inline void i8042_platform_exit(void)
>  #endif
>  }
>  
> +static inline void i8042_platform_suspend(struct device *dev, bool may_wakeup)
> +{
> +}
> +
>  #endif /* _I8042_IO_H */
> diff --git a/drivers/input/serio/i8042-ip22io.h b/drivers/input/serio/i8042-ip22io.h
> index ee1ad27..c5b76a4 100644
> --- a/drivers/input/serio/i8042-ip22io.h
> +++ b/drivers/input/serio/i8042-ip22io.h
> @@ -73,4 +73,8 @@ static inline void i8042_platform_exit(void)
>  #endif
>  }
>  
> +static inline void i8042_platform_suspend(struct device *dev, bool may_wakeup)
> +{
> +}
> +
>  #endif /* _I8042_IP22_H */
> diff --git a/drivers/input/serio/i8042-jazzio.h b/drivers/input/serio/i8042-jazzio.h
> index 13fd710..a11913a 100644
> --- a/drivers/input/serio/i8042-jazzio.h
> +++ b/drivers/input/serio/i8042-jazzio.h
> @@ -66,4 +66,8 @@ static inline void i8042_platform_exit(void)
>  #endif
>  }
>  
> +static inline void i8042_platform_suspend(struct device *dev, bool may_wakeup)
> +{
> +}
> +
>  #endif /* _I8042_JAZZ_H */
> diff --git a/drivers/input/serio/i8042-ppcio.h b/drivers/input/serio/i8042-ppcio.h
> index f708c75..c9f4292 100644
> --- a/drivers/input/serio/i8042-ppcio.h
> +++ b/drivers/input/serio/i8042-ppcio.h
> @@ -52,6 +52,10 @@ static inline void i8042_platform_exit(void)
>  {
>  }
>  
> +static inline void i8042_platform_suspend(struct device *dev, bool may_wakeup)
> +{
> +}
> +
>  #else
>  
>  #include "i8042-io.h"
> diff --git a/drivers/input/serio/i8042-snirm.h b/drivers/input/serio/i8042-snirm.h
> index 409a934..96d034f 100644
> --- a/drivers/input/serio/i8042-snirm.h
> +++ b/drivers/input/serio/i8042-snirm.h
> @@ -72,4 +72,8 @@ static inline void i8042_platform_exit(void)
>  
>  }
>  
> +static inline void i8042_platform_suspend(struct device *dev, bool may_wakeup)
> +{
> +}
> +
>  #endif /* _I8042_SNIRM_H */
> diff --git a/drivers/input/serio/i8042-sparcio.h b/drivers/input/serio/i8042-sparcio.h
> index 395a9af..e5381d3 100644
> --- a/drivers/input/serio/i8042-sparcio.h
> +++ b/drivers/input/serio/i8042-sparcio.h
> @@ -154,4 +154,8 @@ static inline void i8042_platform_exit(void)
>  }
>  #endif /* !CONFIG_PCI */
>  
> +static inline void i8042_platform_suspend(struct device *dev, bool may_wakeup)
> +{
> +}

The fact that you need provide several empty definitions of
i8042_platform_suspend() is a bit worrisome.  Have you considered using a
different approach?

Rafael

^ permalink raw reply

* [PATCH 2/2] ARM / shmobile: Use pm_genpd_poweroff_unused()
From: Rafael J. Wysocki @ 2011-07-10 20:47 UTC (permalink / raw)
  To: Linux PM mailing list; +Cc: LKML, Linux-SH
In-Reply-To: <201107102246.05107.rjw@sisk.pl>

From: Rafael J. Wysocki <rjw@sisk.pl>

Make shmobile use pm_genpd_poweroff_unused() instead of the
open-coded powering off PM domains without devices in use.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/include/mach/common.h |    1 -
 arch/arm/mach-shmobile/pm-sh7372.c           |   13 -------------
 arch/arm/mach-shmobile/pm_runtime.c          |    6 ++----
 3 files changed, 2 insertions(+), 18 deletions(-)

Index: linux-2.6/arch/arm/mach-shmobile/include/mach/common.h
===================================================================
--- linux-2.6.orig/arch/arm/mach-shmobile/include/mach/common.h
+++ linux-2.6/arch/arm/mach-shmobile/include/mach/common.h
@@ -12,7 +12,6 @@ extern struct platform_suspend_ops shmob
 struct cpuidle_device;
 extern void (*shmobile_cpuidle_modes[])(void);
 extern void (*shmobile_cpuidle_setup)(struct cpuidle_device *dev);
-extern void (*shmobile_runtime_pm_late_init)(void);
 
 extern void sh7367_init_irq(void);
 extern void sh7367_add_early_devices(void);
Index: linux-2.6/arch/arm/mach-shmobile/pm-sh7372.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-shmobile/pm-sh7372.c
+++ linux-2.6/arch/arm/mach-shmobile/pm-sh7372.c
@@ -126,17 +126,6 @@ static bool pd_active_wakeup(struct devi
 	return true;
 }
 
-static void sh7372_late_pm_domain_off(void)
-{
-	/* request power down of unused pm domains */
-	queue_work(pm_wq, &sh7372_a4lc.genpd.power_off_work);
-	queue_work(pm_wq, &sh7372_a4mp.genpd.power_off_work);
-	queue_work(pm_wq, &sh7372_d4.genpd.power_off_work);
-	queue_work(pm_wq, &sh7372_a3rv.genpd.power_off_work);
-	queue_work(pm_wq, &sh7372_a3ri.genpd.power_off_work);
-	queue_work(pm_wq, &sh7372_a3sg.genpd.power_off_work);
-}
-
 void sh7372_init_pm_domain(struct sh7372_pm_domain *sh7372_pd)
 {
 	struct generic_pm_domain *genpd = &sh7372_pd->genpd;
@@ -157,8 +146,6 @@ void sh7372_init_pm_domain(struct sh7372
 		genpd->power_on = pd_power_up;
 	}
 	genpd->power_on(&sh7372_pd->genpd);
-
-	shmobile_runtime_pm_late_init = sh7372_late_pm_domain_off;
 }
 
 void sh7372_add_device_to_domain(struct sh7372_pm_domain *sh7372_pd,
Index: linux-2.6/arch/arm/mach-shmobile/pm_runtime.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-shmobile/pm_runtime.c
+++ linux-2.6/arch/arm/mach-shmobile/pm_runtime.c
@@ -14,6 +14,7 @@
 #include <linux/kernel.h>
 #include <linux/io.h>
 #include <linux/pm_runtime.h>
+#include <linux/pm_domain.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/sh_clk.h>
@@ -57,12 +58,9 @@ static int __init sh_pm_runtime_init(voi
 }
 core_initcall(sh_pm_runtime_init);
 
-void (*shmobile_runtime_pm_late_init)(void);
-
 static int __init sh_pm_runtime_late_init(void)
 {
-	if (shmobile_runtime_pm_late_init)
-		shmobile_runtime_pm_late_init();
+	pm_genpd_poweroff_unused();
 	return 0;
 }
 late_initcall(sh_pm_runtime_late_init);

^ permalink raw reply

* [PATCH 1/2] PM / Domains: Introduce function to power off all unused PM domains
From: Rafael J. Wysocki @ 2011-07-10 20:46 UTC (permalink / raw)
  To: Linux PM mailing list; +Cc: LKML, Linux-SH
In-Reply-To: <201107102246.05107.rjw@sisk.pl>

From: Rafael J. Wysocki <rjw@sisk.pl>

Add a new function pm_genpd_poweroff_unused() queuing up the
execution of pm_genpd_poweroff() for every initialized generic PM
domain.  Calling it will cause every generic PM domain without
devices in use to be powered off.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/base/power/domain.c |   21 +++++++++++++++++++++
 include/linux/pm_domain.h   |    3 +++
 2 files changed, 24 insertions(+)

Index: linux-2.6/include/linux/pm_domain.h
===================================================================
--- linux-2.6.orig/include/linux/pm_domain.h
+++ linux-2.6/include/linux/pm_domain.h
@@ -24,6 +24,7 @@ struct dev_power_governor {
 
 struct generic_pm_domain {
 	struct dev_pm_domain domain;	/* PM domain operations */
+	struct list_head gpd_list_node;	/* Node in the global PM domains list */
 	struct list_head sd_node;	/* Node in the parent's subdomain list */
 	struct generic_pm_domain *parent;	/* Parent PM domain */
 	struct list_head sd_list;	/* List of dubdomains */
@@ -71,6 +72,7 @@ extern int pm_genpd_remove_subdomain(str
 extern void pm_genpd_init(struct generic_pm_domain *genpd,
 			  struct dev_power_governor *gov, bool is_off);
 extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
+extern void pm_genpd_poweroff_unused(void);
 #else
 static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
 				      struct device *dev)
@@ -98,6 +100,7 @@ static inline int pm_genpd_poweron(struc
 {
 	return -ENOSYS;
 }
+static inline void pm_genpd_poweroff_unused(void) {}
 #endif
 
 #endif /* _LINUX_PM_DOMAIN_H */
Index: linux-2.6/drivers/base/power/domain.c
===================================================================
--- linux-2.6.orig/drivers/base/power/domain.c
+++ linux-2.6/drivers/base/power/domain.c
@@ -16,6 +16,9 @@
 #include <linux/sched.h>
 #include <linux/suspend.h>
 
+static LIST_HEAD(gpd_list);
+static DEFINE_MUTEX(gpd_list_lock);
+
 #ifdef CONFIG_PM
 
 static struct generic_pm_domain *dev_to_genpd(struct device *dev)
@@ -1241,4 +1244,22 @@ void pm_genpd_init(struct generic_pm_dom
 	genpd->domain.ops.restore_noirq = pm_genpd_restore_noirq;
 	genpd->domain.ops.restore = pm_genpd_restore;
 	genpd->domain.ops.complete = pm_genpd_complete;
+	mutex_lock(&gpd_list_lock);
+	list_add(&genpd->gpd_list_node, &gpd_list);
+	mutex_unlock(&gpd_list_lock);
+}
+
+/**
+ * pm_genpd_poweroff_unused - Power off all PM domains with no devices in use.
+ */
+void pm_genpd_poweroff_unused(void)
+{
+	struct generic_pm_domain *genpd;
+
+	mutex_lock(&gpd_list_lock);
+
+	list_for_each_entry(genpd, &gpd_list, gpd_list_node)
+		genpd_queue_power_off_work(genpd);
+
+	mutex_unlock(&gpd_list_lock);
 }

^ permalink raw reply

* [PATCH 0/2] PM / Domains: Add code for powering off all unused PM domains
From: Rafael J. Wysocki @ 2011-07-10 20:46 UTC (permalink / raw)
  To: Linux PM mailing list, Magnus Damm; +Cc: LKML, Linux-SH

Hi,

The following two patches are on top of the branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6.git pm-domains

and the patchset I sent earlier today:

https://lkml.org/lkml/2011/7/10/27

and this patch: https://patchwork.kernel.org/patch/961202/

They introduce a mechanism allowing platforms to power off all of the PM
domains that don't contain devices in use in one shot.  The first patch
adds core support for that and the second one makes shmobile use it
instead of its own code.

Thanks,
Rafael

^ permalink raw reply

* [PATCH 7 v2] PM / Domains: Queue up power off work only if it is not pending
From: Rafael J. Wysocki @ 2011-07-10 12:29 UTC (permalink / raw)
  To: Linux PM mailing list; +Cc: Greg KH, LKML, MyungJoo Ham
In-Reply-To: <201107101059.30322.rjw@sisk.pl>

From: Rafael J. Wysocki <rjw@sisk.pl>

In theory it is possible that pm_genpd_poweroff() for two different
subdomains of the same parent domain will attempt to queue up the
execution of pm_genpd_poweroff() for the parent twice in a row.  This
would lead to unpleasant consequences, so prevent it from happening
by checking if genpd->power_off_work is pending before attempting to
queue it up.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---

One more patch to the "PM / Domains: Generic PM domains improvements" series,
the changelog should explain everything. :-)

Thanks,
Rafael

---
 drivers/base/power/domain.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/base/power/domain.c
===================================================================
--- linux-2.6.orig/drivers/base/power/domain.c
+++ linux-2.6/drivers/base/power/domain.c
@@ -213,6 +213,19 @@ static bool genpd_abort_poweroff(struct
 }
 
 /**
+ * genpd_queue_power_off_work - Queue up the execution of pm_genpd_poweroff().
+ * @genpd: PM domait to power off.
+ *
+ * Queue up the execution of pm_genpd_poweroff() unless it's already been done
+ * before.
+ */
+static void genpd_queue_power_off_work(struct generic_pm_domain *genpd)
+{
+	if (!work_pending(&genpd->power_off_work))
+		queue_work(pm_wq, &genpd->power_off_work);
+}
+
+/**
  * pm_genpd_poweroff - Remove power from a given PM domain.
  * @genpd: PM domain to power down.
  *
@@ -304,7 +317,7 @@ static int pm_genpd_poweroff(struct gene
 	if (parent) {
 		genpd_sd_counter_dec(parent);
 		if (parent->sd_count == 0)
-			queue_work(pm_wq, &parent->power_off_work);
+			genpd_queue_power_off_work(parent);
 
 		genpd_release_lock(parent);
 	}

^ permalink raw reply

* Re: [PATCH 8/8] ARM / shmobile: Support for I/O PM domains for SH7372 (v5)
From: Laurent Pinchart @ 2011-07-10 11:45 UTC (permalink / raw)
  To: Magnus Damm; +Cc: linux-sh, Greg Kroah-Hartman, LKML, Linux PM mailing list
In-Reply-To: <BANLkTi=u_eyGZt9e0CuVpyz9B08HarEyVw@mail.gmail.com>

Hi Magnus,

On Wednesday 15 June 2011 16:17:15 Magnus Damm wrote:
> On Wed, Jun 15, 2011 at 6:16 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Tuesday, June 14, 2011, Magnus Damm wrote:
> >> On Sun, Jun 12, 2011 at 5:40 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > From: Rafael J. Wysocki <rjw@sisk.pl>
> >> > 
> >> > Use the generic power domains support introduced by the previous
> >> > patch to implement support for power domains on SH7372.
> >> > 
> >> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> >> > ---
> >> 
> >> Thanks for your work on this. I just tried this on my Mackerel board,
> >> but I can't seem to get the pd_power_up() and pd_power_down()
> >> callbacks to be executed. It is probably a misconfiguration from my
> >> side.
> > 
> > They trigger for me e.g. after doing
> > 
> > # echo 3 > /sys/devices/platform/sh_mobile_lcdc_fb.0/graphics/fb0/blank
> > 
> > Attached is the .config I've been using.
> 
> Thanks, I can trigger using sysfs and your kernel configuration.
> 
> However, I assumed it also would work when the sceen saver kicked in.
> I recall it being fbcon that controls the screen save, perhaps
> something else. So just wait a bit and see if you also can reproduce
> it. The console gets black but the power is still on...

That's because, by default, the VT layer will use FB_BLANK_NORMAL mode when 
blanking the console. Switching that to FB_BLANK_VSYNC_SUSPEND, 
FB_BLANK_HSYNC_SUSPEND or FB_BLANK_POWERDOWN with TIOCLINUX(TIOC_SETVESABLANK) 
results in the device being runtime-suspended when the console is blanked.

> Also forcing to go back to powered-on state (see below) doesn't work that
> well: # echo 0 >
> /sys/devices/platform/sh_mobile_lcdc_fb.0/graphics/fb0/blank
> 
> It looks like we loose the panning information somehow. Most likely a LCDC
> driver bug. Unless the driver callbacks are not being invoked as expected.
>
> Also, there is garbage in on the screen if FB_SH_MOBILE_MERAM is
> enabled. The MERAM hardware is a 1.5 MiB memory block that can be used
> as a LCD cache. It sits in the same hardware power domain as the
> LCDCs. I don't think the MERAM software supports power down
> unfortunately. Disabling MERAM support removes the garbage on the
> screen.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* Re: 3.0-rc6-git6: Reported regressions from 2.6.39
From: Rafael J. Wysocki @ 2011-07-10 11:12 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Linux SCSI List, Linux ACPI, Network Development,
	Linux Wireless List, Linux Kernel Mailing List, DRI,
	Florian Mickler, Andrew Morton, Kernel Testers List,
	Linus Torvalds, Linux PM List, Maciej Rutecki
In-Reply-To: <1310295277.3942.1.camel@jlt3.sipsolutions.net>

On Sunday, July 10, 2011, Johannes Berg wrote:
> On Sun, 2011-07-10 at 12:19 +0200, Rafael J. Wysocki wrote:
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=38702
> > Subject		: 3.0.0-rc4-git6 - INFO: possible circular locking dependency detected - (&rdev->mtx){+.+.+.}, at: [<ffffffffa00e27e0>] cfg80211_netdev_notifier_call+0x275/0x4ff [cfg80211]
> > Submitter	: Miles Lane <miles.lane@gmail.com>
> > Date		: 2011-06-26 21:54 (15 days old)
> > Message-ID	: <BANLkTikztsFnPkJZ7VxRC-zsitwCCvVmeg@mail.gmail.com>
> > References	: http://marc.info/?l=linux-kernel&m=130912559804336&w=2
> 
> Should be fixed by c10841ca722a0bc960dc541c51582773f9a24f98 which was
> part of John's latest pull request and is in net-2.6 now on its way up.

Thanks, closing.

Rafael

^ permalink raw reply

* 3.0-rc6-git6: Reported regressions 2.6.38 -> 2.6.39
From: Rafael J. Wysocki @ 2011-07-10 10:54 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Linux SCSI List, Linux ACPI, Network Development,
	Linux Wireless List, DRI, Florian Mickler, Andrew Morton,
	Kernel Testers List, Linus Torvalds, Linux PM List,
	Maciej Rutecki

This message contains a list of some post-2.6.38 regressions introduced before
2.6.39, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved post-2.6.38 regressions, please let us know
either and we'll add them to the list.  Also, please let us know if any
of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2011-07-10       99       26          24
  2011-06-27       94       25          23
  2011-06-12       81       21          18
  2011-05-15       50       12          11
  2011-04-30       38       17          16
  2011-04-17       17       11          10


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=38842
Subject		: panic in elv_completed_request on safe remove usb hard drive
Submitter	: leniviy <basinilya@gmail.com>
Date		: 2011-07-06 09:20 (5 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=38742
Subject		: After hard power-off, btrfs cannot be recovered except booting 2.6.38 or below kernel
Submitter	: Ryan Underwood <nemesis@icequake.net>
Date		: 2011-07-03 18:57 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=38572
Subject		: New NFS: directory XXX contains a readdir loop seems to be triggered by well-behaving server
Submitter	: Petr Vandrovec <petr@vandrovec.name>
Date		: 2011-06-30 19:38 (11 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=38132
Subject		: [Warning] 2.6.39.x latencytop
Submitter	: Andrew Watts <akwatts@ymail.com>
Date		: 2011-06-14 17:07 (27 days old)
Message-ID	: <80098.5633.qm@web111013.mail.gq1.yahoo.com>
References	: http://marc.info/?l=linux-kernel&m=130807128506490&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=38102
Subject		: BUG kmalloc-2048: Poison overwritten
Submitter	: Alexey Zaytsev <alexey.zaytsev@gmail.com>
Date		: 2011-06-23 17:33 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37772
Subject		: Sometimes, sound disappears and doesn't want to idle.
Submitter	:  <merkil@savhon.org>
Date		: 2011-06-17 22:06 (24 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37752
Subject		: Kernel Panic in drm_vblank_put+0x13/0x50 on P4 HT machine with 82915G/GV/910GL Integrated Graphics Controller
Submitter	: Martin Rogge <marogge@onlinehome.de>
Date		: 2011-06-17 13:02 (24 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37712
Subject		: reboot  / "shutdown -r now" hangs ;  works fine on 2.6.38.7-1
Submitter	: Dave Hooper <dave@beermex.com>
Date		: 2011-06-16 20:50 (25 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37692
Subject		: Linux 2.6.39.x fails to boot - unable to mount root fs
Submitter	: Dan Dart <dandart@googlemail.com>
Date		: 2011-06-16 18:55 (25 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37622
Subject		: Poor wireless performance with Intel 4965AGN with iwl-legacy/iwl4965
Submitter	:  <MDstr_1@hotmail.com>
Date		: 2011-06-16 11:22 (25 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37472
Subject		: Lenovo U160 (i915 black screen)
Submitter	: Robse <rob-se@live.de>
Date		: 2011-06-14 15:17 (27 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37322
Subject		: high load, unresponsive system spinning in rcu_kthread
Submitter	: Ferenc Wágner <wferi@niif.hu>
Date		: 2011-06-12 14:53 (29 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37312
Subject		: Intel 5100 wifi stopped working with 2.6.39.1
Submitter	: Thibault Dory <dory.thibault@gmail.com>
Date		: 2011-06-12 12:43 (29 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37292
Subject		: kernel BUG at fs/ecryptfs/read_write.c:47!
Submitter	:  <rems14@lestoutous.com>
Date		: 2011-06-12 10:25 (29 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=37042
Subject		: linux 3.0.0-rc2 libata-eh.c:4018 ata_scsi_port_error_handler+0x80/0x53d on s2disk
Submitter	: Alex Zhavnerchik <alex.vizor@gmail.com>
Date		: 2011-06-09 08:22 (32 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=36952
Subject		: [2.6.39] CIFS write failures where 2.6.38 works
Submitter	: Helge Hafting <helge.hafting@hist.no>
Date		: 2011-06-01 10:11 (40 days old)
Message-ID	: <4DE6103E.6010100@hist.no>
References	: http://marc.info/?l=linux-kernel&m=130692387613423&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=36392
Subject		: 2.6.39, 3.0-rc2 Intel DRI Regression: Black Screen after trying to play video
Submitter	: Dennis Jansen <dennis.jansen@web.de>
Date		: 2011-06-01 04:41 (40 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=36332
Subject		: Intel gpu turns external monitor off when X starts
Submitter	: rocko <rockorequin@hotmail.com>
Date		: 2011-05-31 02:53 (41 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=36182
Subject		: Erroneous package power limit notification since kernel 2.6.39
Submitter	: Olaf Freyer <aaron667@gmx.net>
Date		: 2011-05-22 13:01 (50 days old)
Message-ID	: <4DD9092A.4080507@gmx.net>
References	: http://marc.info/?l=linux-kernel&m=130606930631131&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=35922
Subject		: SND_USB_AUDIO recording device not initializing correctly
Submitter	:  <bjoern.online@gmail.com>
Date		: 2011-05-26 10:30 (46 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=35662
Subject		: softlockup with kernel 2.6.39
Submitter	: Hussam Al-Tayeb <ht990332@gmail.com>
Date		: 2011-05-23 08:13 (49 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=35242
Subject		: NULL pointer dereference in intel_sdvo_write_cmd (was Black screen after boot)
Submitter	: Ko Mi <chaostya.test@hotmail.com>
Date		: 2011-05-17 10:27 (55 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=35142
Subject		: 2.6.39-rc7-git1 boot error message (no crash)
Submitter	: werner <w.landgraf@ru.ru>
Date		: 2011-05-11 4:58 (61 days old)
Message-ID	: <web-520830057@zbackend1.aha.ru>
References	: http://marc.info/?l=linux-kernel&m=130512952706444&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=34942
Subject		: [Bug] Kdump does not work when panic triggered due to MCE
Submitter	: K.Prasad <prasad@linux.vnet.ibm.com>
Date		: 2011-05-06 16:54 (66 days old)
Message-ID	: <20110506165412.GB2719@in.ibm.com>
References	: http://marc.info/?l=linux-kernel&m=130470087226270&w=2


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=35642
Subject		: On resume, I sometimes get a kernel oops with led_trigger_unregister_simple
Submitter	: Sven-Hendrik Haase <sh@lutzhaase.com>
Date		: 2011-05-23 00:15 (49 days old)
Patch		: https://patchwork.kernel.org/patch/927582/
		  https://patchwork.kernel.org/patch/927612/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=33242
Subject		: Lockdep splat in autofs with 2.6.39-rc2
Submitter	: Nick Bowler <nbowler@elliptictech.com>
Date		: 2011-04-07 19:44 (95 days old)
Message-ID	: <20110407194403.GA29404@elliptictech.com>
References	: http://marc.info/?l=linux-kernel&m=130220545614682&w=2
Patch		: http://marc.info/?l=linux-kernel&m=130342115008659&w=2


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.38 and 2.6.39, unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=32012

Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.

Thanks!

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

^ permalink raw reply

* Re: 3.0-rc6-git6: Reported regressions from 2.6.39
From: Johannes Berg @ 2011-07-10 10:54 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux SCSI List, Linux ACPI, Network Development,
	Linux Wireless List, Linux Kernel Mailing List, DRI,
	Florian Mickler, Andrew Morton, Kernel Testers List,
	Linus Torvalds, Linux PM List, Maciej Rutecki
In-Reply-To: <Y7LyOsOBwFM.A.kJG.kBYGOB@chimera>

On Sun, 2011-07-10 at 12:19 +0200, Rafael J. Wysocki wrote:

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=38702
> Subject		: 3.0.0-rc4-git6 - INFO: possible circular locking dependency detected - (&rdev->mtx){+.+.+.}, at: [<ffffffffa00e27e0>] cfg80211_netdev_notifier_call+0x275/0x4ff [cfg80211]
> Submitter	: Miles Lane <miles.lane@gmail.com>
> Date		: 2011-06-26 21:54 (15 days old)
> Message-ID	: <BANLkTikztsFnPkJZ7VxRC-zsitwCCvVmeg@mail.gmail.com>
> References	: http://marc.info/?l=linux-kernel&m=130912559804336&w=2

Should be fixed by c10841ca722a0bc960dc541c51582773f9a24f98 which was
part of John's latest pull request and is in net-2.6 now on its way up.

johannes

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox