* Re: 3.1-rc3-git6: Reported regressions from 3.0
From: Linus Torvalds @ 2011-08-28 19:49 UTC (permalink / raw)
To: Dave Jones, Rafael J. Wysocki, Linux Kernel Mailing List,
Maciej Rutecki
In-Reply-To: <20110828193519.GA14132@redhat.com>
On Sun, Aug 28, 2011 at 12:35 PM, Dave Jones <davej@redhat.com> wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
> > Subject : duplicate filename for intel_backlight with the i915 driver
> > Submitter : François Valenduc <francois.valenduc@tvcablenet.be>
> > Date : 2011-08-25 18:51 (4 days old)
> > First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
>
> this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23
Actually, by a2cc797d2d1a ("i915: do not setup intel_backlight ").
That b727d20269e is just my merge commit that brings in the fix (and
the bogus initialization of 'locked') into mainline.
Linus
^ permalink raw reply
* Re: 3.1-rc3-git6: Reported regressions from 3.0
From: Rafael J. Wysocki @ 2011-08-28 19:39 UTC (permalink / raw)
To: Dave Jones
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: <20110828193519.GA14132@redhat.com>
On Sunday, August 28, 2011, Dave Jones wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
> > Subject : duplicate filename for intel_backlight with the i915 driver
> > Submitter : François Valenduc <francois.valenduc@tvcablenet.be>
> > Date : 2011-08-25 18:51 (4 days old)
> > First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
>
> this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23
Thanks, closing.
Rafael
^ permalink raw reply
* Re: 3.1-rc3-git6: Reported regressions from 3.0
From: Dave Jones @ 2011-08-28 19:35 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: <lx6sezwGldO.A.IhF.UBpWOB@chimera>
On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
> Subject : duplicate filename for intel_backlight with the i915 driver
> Submitter : François Valenduc <francois.valenduc@tvcablenet.be>
> Date : 2011-08-25 18:51 (4 days old)
> First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23
Dave
^ permalink raw reply
* [PATCH] spi: Fix builderror in spi-pl022.c
From: Peter Huewe @ 2011-08-28 19:26 UTC (permalink / raw)
To: Russell King
Cc: Grant Likely, linux-kernel, spi-devel-general, linux-pm,
Peter Huewe, linux-arm-kernel
In-Reply-To: <E1Qvo1q-0000qv-TQ@rmk-PC.arm.linux.org.uk>
This patch fixes a build error, introduced by commit (67fc8b9f, "PM: add
runtime PM support to core Primecell driver") which unfortunately was a little
bit incomplete and did contain a typo (11 instead of 22).
I'm not sure how this patch could have been tested back then, if it
doesn't even compile ;)
The build failure was:
drivers/spi/spi-pl022.c:2292: error: 'adev' undeclared (first use in
this function)
drivers/spi/spi-pl022.c:2344: error: 'pl022_suspend' undeclared here
(not in a function)
The build failure appears e.g. for the u8500 and realview defconfig.
LinuxVersion: linux next-20110826
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
drivers/spi/spi-pl022.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 078338f..3520cf9 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2282,14 +2282,14 @@ pl022_remove(struct amba_device *adev)
}
#ifdef CONFIG_SUSPEND
-static int pl011_suspend(struct device *dev)
+static int pl022_suspend(struct device *dev)
{
struct pl022 *pl022 = dev_get_drvdata(dev);
int status = 0;
status = stop_queue(pl022);
if (status) {
- dev_warn(&adev->dev, "suspend cannot stop queue\n");
+ dev_warn(dev, "suspend cannot stop queue\n");
return status;
}
@@ -2298,7 +2298,7 @@ static int pl011_suspend(struct device *dev)
load_ssp_default_config(pl022);
amba_pclk_disable(pl022->adev);
amba_vcore_disable(pl022->adev);
- dev_dbg(&adev->dev, "suspended\n");
+ dev_dbg(dev, "suspended\n");
return 0;
}
--
1.7.3.4
^ permalink raw reply related
* 3.1-rc3-git6: Reported regressions 2.6.39 -> 3.0
From: Rafael J. Wysocki @ 2011-08-28 18:58 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.39 regressions introduced before
3.0, 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.39 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-08-28 71 21 17
2011-08-14 63 22 19
2011-07-10 38 16 13
2011-06-26 22 14 12
2011-06-12 8 7 7
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41562
Subject : acer-wmi: acer aspire 721 bluetooth control doesn't work with kernel 3.0.0
Submitter : sbraz <hi.sbraz@gmail.com>
Date : 2011-08-22 18:32 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41102
Subject : BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
Submitter : Paul Bolle <pebolle@tiscali.nl>
Date : 2011-08-13 22:29 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41092
Subject : INFO: trying to register non-static key (sync_inodes_sb)
Submitter : Paul Bolle <pebolle@tiscali.nl>
Date : 2011-08-13 22:07 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40442
Subject : cpuinfo_max_freq lost 500MHz
Submitter : Harald Dunkel <harri@afaics.de>
Date : 2011-08-02 20:31 (27 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40282
Subject : IP forwarding regression since 3.0-rc6
Submitter : Stephan Seitz <stse+lkml@fsing.rootsland.net>
Date : 2011-07-25 12:51 (35 days old)
Message-ID : <20110725T141145.GA.2ae38.stse@fsing.rootsland.net>
References : http://marc.info/?l=linux-kernel&m=131159880004908&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40262
Subject : PROBLEM: I/O storm from hell on kernel 3.0.0 when touch swap (swapfile or partition)
Submitter : g0re <g0re@null.net>
Date : 2011-07-28 12:40 (32 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40092
Subject : RCU stall in linux-3.0.0
Submitter : Philip Armstrong <phil@kantaka.co.uk>
Date : 2011-07-25 21:44 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40072
Subject : suspend/resume problems w/ kernel 3.0 and a *docked* ThinkPad T400, unless iwlagn unloaded
Submitter : Toralf Förster <toralf.foerster@gmx.de>
Date : 2011-07-23 19:27 (37 days old)
Message-ID : <201107232127.34255.toralf.foerster@gmx.de>
References : http://marc.info/?l=linux-kernel&m=131144928023465&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39922
Subject : WIFI becomes EXTREMELY slow ( ath9k ) making the connection unusable
Submitter : Lukasz Olszewski <lcpak@epoczta.pl>
Date : 2011-07-24 09:20 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39912
Subject : WARNING: at drivers/tty/tty_ldisc.c:766 tty_ldisc_reinit+0x7d/0x90()
Submitter : Vegard Nossum <vegard.nossum@gmail.com>
Date : 2011-07-19 11:33 (41 days old)
Message-ID : <CAOMGZ=HS2EPkYD=5HfkSPpwPqHB5V3q0vaFmoZ8Hh+pMM9phrQ@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=131107522914558&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39832
Subject : HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
Submitter : Andreas Steinmetz <ast@domdv.de>
Date : 2011-07-23 01:36 (37 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39732
Subject : JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 2512725). There's a risk of filesystem corruption in case of system crash.
Submitter : Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Date : 2011-07-22 04:22 (38 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39412
Subject : Win Vista and Win2K8 guests' network breaks down
Submitter : Jay Ren <yongjie.ren@intel.com>
Date : 2011-07-15 15:31 (45 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39192
Subject : firmware_install fails with parallel make
Submitter : Ambroz Bizjak <ambrop7@gmail.com>
Date : 2011-07-12 09:35 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=38922
Subject : Lenovo T420 (Sandy Bridge) Crashes on SD Card gpt partition writing and io errors on insert
Submitter : Peter Vollmer <vollmerpeter@googlemail.com>
Date : 2011-07-07 17:33 (53 days old)
First-Bad-Commit: http://git.kernel.org/linus/a3c7778f8153b9e4eceea6738973280b9e63c618
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=38622
Subject : [radeon cayman regresion] artefacts on screen
Submitter : Marek Hobler, 'neutrinus' <kernellist@neutrinus.com>
Date : 2011-07-01 09:35 (59 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=38582
Subject : T510 43495KG won't resume with 32bit installation
Submitter : Marc Koschewski <marc@osknowledge.org>
Date : 2011-06-30 22:39 (60 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41262
Subject : Terracted T5 does no more work
Submitter : Eric Valette <eric.valette@free.fr>
Date : 2011-08-16 20:45 (13 days old)
Patch : https://bugzilla.kernel.org/attachment.cgi?id=69382
https://bugzilla.kernel.org/attachment.cgi?id=69392
https://bugzilla.kernel.org/attachment.cgi?id=69402
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41232
Subject : Channel switching on Hauppauge Nova-T stick fails randomly
Submitter : <q222@gmx.com>
Date : 2011-08-16 11:33 (13 days old)
Patch : http://git.linuxtv.org/pb/media_tree.git/commitdiff/aeb2d456b746164a4bd19e53de0a6678ca63fcad
http://git.linuxtv.org/pb/media_tree.git/commitdiff/45cbff13693d645fa5dcbba964e802e1746b2e57
http://git.linuxtv.org/pb/media_tree.git/commitdiff/45cbff13693d645fa5dcbba964e802e1746b2e57
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40062
Subject : USB related "unable to handle kernel paging request" in 3.0.0-rc7
Submitter : Tino Keitel <tino.keitel@tikei.de>
Date : 2011-07-22 19:27 (38 days old)
Message-ID : <20110722192722.GA9369@x61.home>
References : http://marc.info/?l=linux-kernel&m=131136334621623&w=2
Patch : https://lkml.org/lkml/2011/8/2/174
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39882
Subject : Kernel oops when turning bluetooth mouse on
Submitter : Lamarque V. Souza <lamarque@gmail.com>
Date : 2011-07-24 02:09 (36 days old)
Patch : https://bugzilla.kernel.org/attachment.cgi?id=70342
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.39 and 3.0, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=36912
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
* [regression] Re: [213/474] x86, hotplug: Use mwait to offline a processor, fix the legacy case
From: Jonathan Nieder @ 2011-08-28 18:40 UTC (permalink / raw)
To: Len Brown
Cc: Greg KH, Robert Scott, x86, Frédéric Boiteux, stable,
Venkatesh Pallipadi, linux-pm, H. Peter Anvin, stable-review
In-Reply-To: <20110317212903.394948496@clark.kroah.org>
Hi,
On 2011-03-17, Greg KH wrote:
> 2.6.33-longterm review patch. If anyone has any objections, please let us know.
[...]
> From: H. Peter Anvin <hpa@linux.intel.com>
>
> upstream ea53069231f9317062910d6e772cca4ce93de8c8
> x86, hotplug: Use mwait to offline a processor, fix the legacy case
>
> Here included also some small follow-on patches to the same code:
[...]
> https://bugzilla.kernel.org/show_bug.cgi?id=5471
>
> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> Signed-off-by: Len Brown <len.brown@intel.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sorry for the sloow response. Unfortunately this is reported to have
broken hibernation on two machines: an EeePC 1002HA and an Ideapad S10-3.
Frédéric writes:
| I've observed that when resuming from hibernation, sometimes my computer was
| returning to Grub2's menu (without any error message), and I had to do a
| "normal" boot on my Debian Squeeze system (with file systems corrections),
| loosing my hibernation's state.
| The fail isn't automatic, but seems to happen more frequently after a while
| my computer was disconnected from AC and battery.
Noticed on Debian squeeze (which is based on v2.6.32.y), confirmed
with unpatched v2.6.32.45 and v2.6.33.18. Backing out the patch
mentioned above avoids trouble. A newer kernel (based on v2.6.39.y)
does _not_ exhibit the same problem, so it looks like the problem was
introduced in backporting. http://bugs.debian.org/622259 has
details.
Ideas?
Thanks,
Jonathan
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* 3.1-rc3-git6: Reported regressions from 3.0
From: Rafael J. Wysocki @ 2011-08-28 18:22 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 regressions from 3.0,
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 regressions from 3.0, 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-08-28 8 4 4
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
Subject : duplicate filename for intel_backlight with the i915 driver
Submitter : François Valenduc <francois.valenduc@tvcablenet.be>
Date : 2011-08-25 18:51 (4 days old)
First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41512
Subject : 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds
Submitter : Carlos R. Mafra <crmafra2@gmail.com>
Date : 2011-08-16 9:42 (13 days old)
Message-ID : <20110816094245.GA2042@Pilar.site>
References : http://marc.info/?l=linux-kernel&m=131348782017435&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41502
Subject : cfq-iosched: a regression
Submitter : Shaohua Li <shaohua.li@intel.com>
Date : 2011-08-16 2:47 (13 days old)
Message-ID : <1313462826.27321.22.camel@sli10-conroe>
References : http://marc.info/?l=linux-kernel&m=131346279329911&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41442
Subject : rcu_sched_state detected stall on CPU 0, when booting on Xen
Submitter : Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Date : 2011-08-21 04:06 (8 days old)
Regressions with patches
------------------------
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 from 3.0,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=40982
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
* [PATCH 3/3] bq24022: Add support for the bq2407x family
From: Heiko Stübner @ 2011-08-28 13:10 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood; +Cc: linux-pm, Philipp Zabel
In-Reply-To: <201108281507.35105.heiko@sntech.de>
The bq2407x family of charger ICs simply supports another machine
specific charging current above 500mA. To use this setting a
second gpio pin is used while the rest of the pins stay the same.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/regulator/Kconfig | 7 ++--
drivers/regulator/bq24022.c | 65 ++++++++++++++++++++++++++++++++++---
include/linux/regulator/bq24022.h | 7 ++++
3 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c7fd2c0..546a7a6 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -67,10 +67,11 @@ config REGULATOR_USERSPACE_CONSUMER
config REGULATOR_BQ24022
tristate "TI bq24022 Dual Input 1-Cell Li-Ion Charger IC"
help
- This driver controls a TI bq24022 Charger attached via
- GPIOs. The provided current regulator can enable/disable
+ This driver controls a TI bq24022 or bq2407x Charger attached
+ via GPIOs. The provided current regulator can enable/disable
charging select between 100 mA and 500 mA charging current
- limit.
+ limit. The bq2407x family also supports a machine specific
+ current limit above 500 mA.
config REGULATOR_MAX1586
tristate "Maxim 1586/1587 voltage regulator"
diff --git a/drivers/regulator/bq24022.c b/drivers/regulator/bq24022.c
index b5a6755..ad6942a 100644
--- a/drivers/regulator/bq24022.c
+++ b/drivers/regulator/bq24022.c
@@ -19,15 +19,20 @@
#include <linux/gpio.h>
#include <linux/regulator/bq24022.h>
#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
struct bq24022 {
struct regulator_dev *rdev;
int gpio_nce;
int gpio_iset2;
+ int gpio_2407x_en2;
int state_nce;
int state_iset2;
+ int state_2407x_en2;
+
+ int max_uA;
};
static int bq24022_set_current_limit(struct regulator_dev *rdev,
@@ -35,12 +40,30 @@ static int bq24022_set_current_limit(struct regulator_dev *rdev,
{
struct bq24022 *bq = rdev_get_drvdata(rdev);
- dev_dbg(rdev_get_dev(rdev), "setting current limit to %s mA\n",
- max_uA >= 500000 ? "500" : "100");
+ if (bq->max_uA && bq->max_uA > 500000
+ && max_uA >= bq->max_uA && bq->gpio_2407x_en2) {
+ dev_dbg(rdev_get_dev(rdev),
+ "setting current limit to %d mA\n",
+ bq->max_uA / 1000);
+ gpio_set_value(bq->gpio_2407x_en2, 1);
+ bq->state_2407x_en2 = 1;
+ gpio_set_value(bq->gpio_iset2, 0);
+ bq->state_iset2 = 0;
+ } else if (max_uA >= 100000) {
+ dev_dbg(rdev_get_dev(rdev), "setting current limit to %s mA\n",
+ max_uA >= 500000 ? "500" : "100");
+ if (bq->gpio_2407x_en2) {
+ gpio_set_value(bq->gpio_2407x_en2, 0);
+ bq->state_2407x_en2 = 0;
+ }
+ bq->state_iset2 = (max_uA >= 500000);
+ gpio_set_value(bq->gpio_iset2, bq->state_iset2);
+ } else {
+ dev_err(rdev_get_dev(rdev), "cannot set current limit below 100 mA\n");
+ return -EINVAL;
+ }
/* REVISIT: maybe return error if min_uA != 0 ? */
- bq->state_iset2 = (max_uA >= 500000);
- gpio_set_value(bq->gpio_iset2, bq->state_iset2);
return 0;
}
@@ -48,7 +71,10 @@ static int bq24022_get_current_limit(struct regulator_dev *rdev)
{
struct bq24022 *bq = rdev_get_drvdata(rdev);
- return bq->state_iset2 ? 500000 : 100000;
+ if (bq->state_2407x_en2)
+ return bq->state_iset2 ? 0 : bq->max_uA;
+ else
+ return bq->state_iset2 ? 500000 : 100000;
}
static int bq24022_enable(struct regulator_dev *rdev)
@@ -122,8 +148,25 @@ static int __init bq24022_probe(struct platform_device *pdev)
pdata->gpio_iset2);
goto err_iset2;
}
+ if (pdata->gpio_2407x_en2) {
+ ret = gpio_request(pdata->gpio_2407x_en2, "charge_mode2");
+ if (ret) {
+ dev_dbg(&pdev->dev, "couldn't request EN2 GPIO: %d\n",
+ pdata->gpio_2407x_en2);
+ goto err_en2;
+ }
+ }
/* set initial current to 100mA and disable regulator */
+ if (pdata->gpio_2407x_en2) {
+ ret = gpio_direction_output(pdata->gpio_2407x_en2, 0);
+ if (ret) {
+ dev_dbg(&pdev->dev, "couldn't set EN2 GPIO: %d\n",
+ pdata->gpio_2407x_en2);
+ goto err_reg;
+ }
+ bq->gpio_2407x_en2 = pdata->gpio_2407x_en2;
+ }
ret = gpio_direction_output(pdata->gpio_iset2, 0);
if (ret) {
dev_dbg(&pdev->dev, "couldn't set ISET2 GPIO: %d\n",
@@ -140,6 +183,13 @@ static int __init bq24022_probe(struct platform_device *pdev)
bq->gpio_nce = pdata->gpio_nce;
bq->state_nce = 1;
+ /* get maximum current from regulator_init_data */
+ if (pdata->init_data) {
+ bq->max_uA = pdata->init_data->constraints.max_uA;
+ dev_dbg(&pdev->dev, "maximum current is %d mA\n",
+ bq->max_uA / 1000);
+ }
+
bq->rdev = regulator_register(&bq24022_desc, &pdev->dev,
pdata->init_data, bq);
if (IS_ERR(bq->rdev)) {
@@ -152,6 +202,9 @@ static int __init bq24022_probe(struct platform_device *pdev)
return 0;
err_reg:
+ if (pdata->gpio_2407x_en2)
+ gpio_free(pdata->gpio_2407x_en2);
+err_en2:
gpio_free(pdata->gpio_iset2);
err_iset2:
gpio_free(pdata->gpio_nce);
@@ -164,6 +217,8 @@ static int __devexit bq24022_remove(struct platform_device *pdev)
struct bq24022 *bq = platform_get_drvdata(pdev);
regulator_unregister(bq->rdev);
+ if (bq->gpio_2407x_en2)
+ gpio_free(bq->gpio_2407x_en2);
gpio_free(bq->gpio_iset2);
gpio_free(bq->gpio_nce);
diff --git a/include/linux/regulator/bq24022.h b/include/linux/regulator/bq24022.h
index a6d0140..39a48e1 100644
--- a/include/linux/regulator/bq24022.h
+++ b/include/linux/regulator/bq24022.h
@@ -16,9 +16,16 @@ struct regulator_init_data;
* bq24022_mach_info - platform data for bq24022
* @gpio_nce: GPIO line connected to the nCE pin, used to enable / disable charging
* @gpio_iset2: GPIO line connected to the ISET2 pin, used to limit charging current to 100 mA / 500 mA
+ * @gpio_2407x_en2: GPIO line connected to the en2 pin of the bq2407x family
+ * Modes of operation for bq2407x:
+ * EN2 = 0, ISET2 = 0: 100mA
+ * EN2 = 0, ISET2 = 1: 500mA
+ * EN2 = 1, ISET2 = 0: max_current
+ * EN2 = 1, ISET2 = 1: Standby (usb suspend)
*/
struct bq24022_mach_info {
int gpio_nce;
int gpio_iset2;
+ int gpio_2407x_en2;
struct regulator_init_data *init_data;
};
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] bq24022: Keep track of gpio states
From: Heiko Stübner @ 2011-08-28 13:09 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood; +Cc: linux-pm, Philipp Zabel
In-Reply-To: <201108281507.35105.heiko@sntech.de>
gpio_get_value is not definied for output-gpios and can therefore not be
used for the is_enabled and get_current_limit methods of the bq24022.
This patch introduces a private struct to keep track of the values set.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/regulator/bq24022.c | 67 +++++++++++++++++++++++++++++-------------
1 files changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/regulator/bq24022.c b/drivers/regulator/bq24022.c
index 973af08..b5a6755 100644
--- a/drivers/regulator/bq24022.c
+++ b/drivers/regulator/bq24022.c
@@ -15,56 +15,69 @@
#include <linux/platform_device.h>
#include <linux/err.h>
#include <linux/module.h>
+#include <linux/slab.h>
#include <linux/gpio.h>
#include <linux/regulator/bq24022.h>
#include <linux/regulator/driver.h>
+struct bq24022 {
+ struct regulator_dev *rdev;
+
+ int gpio_nce;
+ int gpio_iset2;
+
+ int state_nce;
+ int state_iset2;
+};
static int bq24022_set_current_limit(struct regulator_dev *rdev,
int min_uA, int max_uA)
{
- struct bq24022_mach_info *pdata = rdev_get_drvdata(rdev);
+ struct bq24022 *bq = rdev_get_drvdata(rdev);
dev_dbg(rdev_get_dev(rdev), "setting current limit to %s mA\n",
max_uA >= 500000 ? "500" : "100");
/* REVISIT: maybe return error if min_uA != 0 ? */
- gpio_set_value(pdata->gpio_iset2, max_uA >= 500000);
+ bq->state_iset2 = (max_uA >= 500000);
+ gpio_set_value(bq->gpio_iset2, bq->state_iset2);
return 0;
}
static int bq24022_get_current_limit(struct regulator_dev *rdev)
{
- struct bq24022_mach_info *pdata = rdev_get_drvdata(rdev);
+ struct bq24022 *bq = rdev_get_drvdata(rdev);
- return gpio_get_value(pdata->gpio_iset2) ? 500000 : 100000;
+ return bq->state_iset2 ? 500000 : 100000;
}
static int bq24022_enable(struct regulator_dev *rdev)
{
- struct bq24022_mach_info *pdata = rdev_get_drvdata(rdev);
+ struct bq24022 *bq = rdev_get_drvdata(rdev);
dev_dbg(rdev_get_dev(rdev), "enabling charger\n");
- gpio_set_value(pdata->gpio_nce, 0);
+ gpio_set_value(bq->gpio_nce, 0);
+ bq->state_nce = 0;
return 0;
}
static int bq24022_disable(struct regulator_dev *rdev)
{
- struct bq24022_mach_info *pdata = rdev_get_drvdata(rdev);
+ struct bq24022 *bq = rdev_get_drvdata(rdev);
dev_dbg(rdev_get_dev(rdev), "disabling charger\n");
- gpio_set_value(pdata->gpio_nce, 1);
+ gpio_set_value(bq->gpio_nce, 1);
+ bq->state_nce = 1;
return 0;
}
static int bq24022_is_enabled(struct regulator_dev *rdev)
{
- struct bq24022_mach_info *pdata = rdev_get_drvdata(rdev);
+ struct bq24022 *bq = rdev_get_drvdata(rdev);
- return !gpio_get_value(pdata->gpio_nce);
+ return !bq->state_nce;
}
static struct regulator_ops bq24022_ops = {
@@ -85,12 +98,18 @@ static struct regulator_desc bq24022_desc = {
static int __init bq24022_probe(struct platform_device *pdev)
{
struct bq24022_mach_info *pdata = pdev->dev.platform_data;
- struct regulator_dev *bq24022;
+ struct bq24022 *bq;
int ret;
if (!pdata || !pdata->gpio_nce || !pdata->gpio_iset2)
return -EINVAL;
+ bq = kzalloc(sizeof(struct bq24022), GFP_KERNEL);
+ if (!bq) {
+ dev_err(&pdev->dev, "cannot allocate memory\n");
+ return -ENOMEM;
+ }
+
ret = gpio_request(pdata->gpio_nce, "ncharge_en");
if (ret) {
dev_dbg(&pdev->dev, "couldn't request nCE GPIO: %d\n",
@@ -103,27 +122,32 @@ static int __init bq24022_probe(struct platform_device *pdev)
pdata->gpio_iset2);
goto err_iset2;
}
+
+ /* set initial current to 100mA and disable regulator */
ret = gpio_direction_output(pdata->gpio_iset2, 0);
if (ret) {
dev_dbg(&pdev->dev, "couldn't set ISET2 GPIO: %d\n",
pdata->gpio_iset2);
goto err_reg;
}
+ bq->gpio_iset2 = pdata->gpio_iset2;
ret = gpio_direction_output(pdata->gpio_nce, 1);
if (ret) {
dev_dbg(&pdev->dev, "couldn't set nCE GPIO: %d\n",
pdata->gpio_nce);
goto err_reg;
}
+ bq->gpio_nce = pdata->gpio_nce;
+ bq->state_nce = 1;
- bq24022 = regulator_register(&bq24022_desc, &pdev->dev,
- pdata->init_data, pdata);
- if (IS_ERR(bq24022)) {
+ bq->rdev = regulator_register(&bq24022_desc, &pdev->dev,
+ pdata->init_data, bq);
+ if (IS_ERR(bq->rdev)) {
dev_dbg(&pdev->dev, "couldn't register regulator\n");
- ret = PTR_ERR(bq24022);
+ ret = PTR_ERR(bq->rdev);
goto err_reg;
}
- platform_set_drvdata(pdev, bq24022);
+ platform_set_drvdata(pdev, bq);
dev_dbg(&pdev->dev, "registered regulator\n");
return 0;
@@ -137,12 +161,13 @@ err_ce:
static int __devexit bq24022_remove(struct platform_device *pdev)
{
- struct bq24022_mach_info *pdata = pdev->dev.platform_data;
- struct regulator_dev *bq24022 = platform_get_drvdata(pdev);
+ struct bq24022 *bq = platform_get_drvdata(pdev);
- regulator_unregister(bq24022);
- gpio_free(pdata->gpio_iset2);
- gpio_free(pdata->gpio_nce);
+ regulator_unregister(bq->rdev);
+ gpio_free(bq->gpio_iset2);
+ gpio_free(bq->gpio_nce);
+
+ kfree(bq);
return 0;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/3] bq24022: Evaluate returns of gpio_direction_output-calls
From: Heiko Stübner @ 2011-08-28 13:08 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood; +Cc: linux-pm, Philipp Zabel
In-Reply-To: <201108281507.35105.heiko@sntech.de>
It wasn't done before.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/regulator/bq24022.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/bq24022.c b/drivers/regulator/bq24022.c
index e24d1b7..973af08 100644
--- a/drivers/regulator/bq24022.c
+++ b/drivers/regulator/bq24022.c
@@ -104,7 +104,17 @@ static int __init bq24022_probe(struct platform_device *pdev)
goto err_iset2;
}
ret = gpio_direction_output(pdata->gpio_iset2, 0);
+ if (ret) {
+ dev_dbg(&pdev->dev, "couldn't set ISET2 GPIO: %d\n",
+ pdata->gpio_iset2);
+ goto err_reg;
+ }
ret = gpio_direction_output(pdata->gpio_nce, 1);
+ if (ret) {
+ dev_dbg(&pdev->dev, "couldn't set nCE GPIO: %d\n",
+ pdata->gpio_nce);
+ goto err_reg;
+ }
bq24022 = regulator_register(&bq24022_desc, &pdev->dev,
pdata->init_data, pdata);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/3] bq24022: Add support for bq2407x family
From: Heiko Stübner @ 2011-08-28 13:07 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood; +Cc: linux-pm, Philipp Zabel
The bq2407x family is quite similar to the bq24022 charger.
As suggested by MyungJoo Ham it should be possible to implement
support for it inside the bq24022 driver instead of adding a new one.
The first two patches fix small things Mark Brown identified in my
submission of a separate bq2407x driver that also exist in the bq24022
while the third implements the bq2407x specifics.
Heiko Stuebner (3):
bq24022: Evaluate returns of gpio_direction_output-calls
bq24022: Keep track of gpio states
bq24022: Add support for the bq2407x family
drivers/regulator/Kconfig | 7 +-
drivers/regulator/bq24022.c | 138 ++++++++++++++++++++++++++++++-------
include/linux/regulator/bq24022.h | 7 ++
3 files changed, 125 insertions(+), 27 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [GIT PULL] Power management fixes for 3.1
From: Rafael J. Wysocki @ 2011-08-28 12:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux PM mailing list, linux-omap, linux-sh
Hi Linus,
Please pull power management fixes for 3.1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-fixes
They include:
* Fixes related to the sh-sci driver which uses runtime PM helpers in
such a way that they may be run with interrupts off, but it doesn't
tell the core about that (so the core happily enables interrupts when
they should be off), and which also causes pm_clk_suspend() and
pm_clk_resume() to be run with interrupts off (so they shouldn't use
a mutex).
* shi7372 LCDC suspend fix from Magnus Damm.
* OMAP suspend callbacks fix from Kevin Hilman.
* Runtime PM documentation correction.
Thanks!
Documentation/power/runtime_pm.txt | 3 +-
arch/arm/mach-shmobile/board-ap4evb.c | 1 +
arch/arm/mach-shmobile/board-mackerel.c | 1 +
arch/arm/mach-shmobile/clock-sh7372.c | 2 +
arch/arm/plat-omap/omap_device.c | 3 +-
drivers/base/power/clock_ops.c | 40 +++++++++++++++++--------------
drivers/tty/serial/sh-sci.c | 1 +
7 files changed, 30 insertions(+), 21 deletions(-)
---------------
Kevin Hilman (1):
OMAP: omap_device: only override _noirq methods, not normal suspend/resume
Magnus Damm (2):
ARM: mach-shmobile: sh7372 LCDC1 suspend fix
ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental)
Rafael J. Wysocki (3):
PM: Use spinlock instead of mutex in clock management functions
sh-sci / PM: Use power.irq_safe
PM / Runtime: Correct documentation of pm_runtime_irq_safe()
^ permalink raw reply
* Re: [PATCH v8 0/5] DEVFREQ, DVFS Framework for Non-CPU Devices.
From: Rafael J. Wysocki @ 2011-08-27 20:35 UTC (permalink / raw)
To: MyungJoo Ham, Mike Turquette
Cc: Len Brown, Greg Kroah-Hartman, Kyungmin Park, linux-pm,
Thomas Gleixner
In-Reply-To: <1314174131-14194-1-git-send-email-myungjoo.ham@samsung.com>
Mike, are patches [3-5/5] in this revision fine by you?
Rafael
On Wednesday, August 24, 2011, MyungJoo Ham wrote:
> The patchset revision v8 has minor updates since v7 and v6.
> - Allow governors to have their own sysfs interface and init/exit callbacks.
>
> The patches 1/5 (OPP notifier) and 2/5 (DEVFREQ core) have no changes since v7.
> There has been reordering between "add common sysfs interfaces" patch
> and "add basic governors" (3/5 and 5/5)
> "add internal interfaces for governors (4/5)" patch has been newly
> introduced at v8 patchset.
>
> For a usage example, please look at
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/devfreq
>
> In the above git tree, DVFS (dynamic voltage and frequency scaling) mechanism
> is applied to the memory bus of Exynos4210 for Exynos4210-NURI boards.
> In the example, the LPDDR2 DRAM frequency changes between 133, 266, and 400MHz
> and other related clocks simply follow the determined DDR RAM clock.
>
> The DEVFREQ driver for Exynos4210 memory bus is at
> /drivers/devfreq/exynos4210_memorybus.c in the git tree.
>
> In the dd (writing and reading 360MiB) test with NURI board, the memory
> throughput was not changed (the performance is not deteriorated) while
> the SoC power consumption has been reduced by 1%. When the memory access
> is not that intense while the CPU is heavily used, the SoC power consumption
> has been reduced by 6%. The power consumption has been compared with the
> case using the conventional Exynos4210 CPUFREQ driver, which sets memory
> bus frequency according to the CPU core frequency. Besides, when the CPU core
> running slow and the memory access is intense, the performance (memory
> throughput) has been increased by 11% (with higher SoC power consumption of
> 5%). The tested governor is "simple-ondemand".
>
> MyungJoo Ham (5):
> PM / OPP: Add OPP availability change notifier.
> PM: Introduce DEVFREQ: generic DVFS framework with device-specific
> OPPs
> PM / DEVFREQ: add common sysfs interfaces
> PM / DEVFREQ: add internal interfaces for governors
> PM / DEVFREQ: add basic governors
>
> Documentation/ABI/testing/sysfs-devices-power | 46 +++
> drivers/Kconfig | 2 +
> drivers/Makefile | 2 +
> drivers/base/power/opp.c | 29 ++
> drivers/devfreq/Kconfig | 75 ++++
> drivers/devfreq/Makefile | 5 +
> drivers/devfreq/devfreq.c | 463 +++++++++++++++++++++++++
> drivers/devfreq/governor.h | 20 +
> drivers/devfreq/governor_performance.c | 24 ++
> drivers/devfreq/governor_powersave.c | 24 ++
> drivers/devfreq/governor_simpleondemand.c | 88 +++++
> drivers/devfreq/governor_userspace.c | 119 +++++++
> include/linux/devfreq.h | 150 ++++++++
> include/linux/opp.h | 12 +
> 14 files changed, 1059 insertions(+), 0 deletions(-)
> create mode 100644 drivers/devfreq/Kconfig
> create mode 100644 drivers/devfreq/Makefile
> create mode 100644 drivers/devfreq/devfreq.c
> create mode 100644 drivers/devfreq/governor.h
> create mode 100644 drivers/devfreq/governor_performance.c
> create mode 100644 drivers/devfreq/governor_powersave.c
> create mode 100644 drivers/devfreq/governor_simpleondemand.c
> create mode 100644 drivers/devfreq/governor_userspace.c
> create mode 100644 include/linux/devfreq.h
>
>
^ permalink raw reply
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
From: Alan Stern @ 2011-08-27 19:42 UTC (permalink / raw)
To: Santosh
Cc: Tero Kristo, Felipe Balbi, Partha Basak, Govindraj.R,
Keshava Munegowda, linux-pm, linux-omap
In-Reply-To: <4E5903FA.5050101@ti.com>
On Sat, 27 Aug 2011, Santosh wrote:
> On Saturday 27 August 2011 07:31 PM, Alan Stern wrote:
> > On Sat, 27 Aug 2011, Santosh wrote:
> >
> >> I might be wrong here, but after discussion with Govindraj on this
> >> issue, it seems there is a flaw in the way OMAP chain handler
> >> handling the child interrupts.
> >>
> >> On OMAP, we have special interrupt wakeup source at PRCM level and
> >> many devices can trigger wakeup from low power via this common
> >> interrupt source. The common interrupt source upon wakeup from low
> >> power state, decodes the source of interrupt and based on that
> >> source, calls the respective device ISR directly.
> >>
> >> The issue I see here is, the ISR on _a_ device (UART in this case)
> >> is happening even before UART resume and DPM resume has been completed.
> >> If this is the case, then it is surely asking for trouble. Because not
> >> just clocks, but even driver state machine is already in suspend state
> >> when the ISR is called.
> >
> > If the driver state machine is in the suspend state when the ISR is
> > called, then the ISR should realize it is handling a wakeup event
> > instead of a normal I/O event. All it needs to do is turn off the
> > interrupt source; the event itself will be taken care of during the
> > device's resume callback.
> >
> Good point but the ISR is called as a function call and not real
> hardware event so no need to turn-off the source in the child
> ISR. Parent ISR will clear the source anyways.
>
> But the intention here is to record the event for the child.
In that case the ISR only has to record the event.
> I mean for UART wakeup, the received character should be
> extracted. If not done, UART will loose that character because
> the event is lost. So not sure how the event will be taken
> care during resume callback. Could you elaborate bit more on
> last comment please?
The resume callback routine must check to see if an event was recorded.
If one was, the routine must see whether a character was received while
the system was asleep and extract the character from the UART. (It
probably won't hurt to do this even if an event wasn't recorded.)
Alan Stern
^ permalink raw reply
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
From: Santosh @ 2011-08-27 14:49 UTC (permalink / raw)
To: Alan Stern
Cc: Tero Kristo, Felipe Balbi, Partha Basak, Govindraj.R,
Keshava Munegowda, linux-pm, linux-omap
In-Reply-To: <Pine.LNX.4.44L0.1108270958320.17264-100000@netrider.rowland.org>
On Saturday 27 August 2011 07:31 PM, Alan Stern wrote:
> On Sat, 27 Aug 2011, Santosh wrote:
>
>> I might be wrong here, but after discussion with Govindraj on this
>> issue, it seems there is a flaw in the way OMAP chain handler
>> handling the child interrupts.
>>
>> On OMAP, we have special interrupt wakeup source at PRCM level and
>> many devices can trigger wakeup from low power via this common
>> interrupt source. The common interrupt source upon wakeup from low
>> power state, decodes the source of interrupt and based on that
>> source, calls the respective device ISR directly.
>>
>> The issue I see here is, the ISR on _a_ device (UART in this case)
>> is happening even before UART resume and DPM resume has been completed.
>> If this is the case, then it is surely asking for trouble. Because not
>> just clocks, but even driver state machine is already in suspend state
>> when the ISR is called.
>
> If the driver state machine is in the suspend state when the ISR is
> called, then the ISR should realize it is handling a wakeup event
> instead of a normal I/O event. All it needs to do is turn off the
> interrupt source; the event itself will be taken care of during the
> device's resume callback.
>
Good point but the ISR is called as a function call and not real
hardware event so no need to turn-off the source in the child
ISR. Parent ISR will clear the source anyways.
But the intention here is to record the event for the child.
I mean for UART wakeup, the received character should be
extracted. If not done, UART will loose that character because
the event is lost. So not sure how the event will be taken
care during resume callback. Could you elaborate bit more on
last comment please?
Regards
Santosh
^ permalink raw reply
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
From: Alan Stern @ 2011-08-27 14:01 UTC (permalink / raw)
To: Santosh
Cc: Tero Kristo, Felipe Balbi, Partha Basak, Govindraj.R,
Keshava Munegowda, linux-pm, linux-omap
In-Reply-To: <4E588EEA.7090004@ti.com>
On Sat, 27 Aug 2011, Santosh wrote:
> I might be wrong here, but after discussion with Govindraj on this
> issue, it seems there is a flaw in the way OMAP chain handler
> handling the child interrupts.
>
> On OMAP, we have special interrupt wakeup source at PRCM level and
> many devices can trigger wakeup from low power via this common
> interrupt source. The common interrupt source upon wakeup from low
> power state, decodes the source of interrupt and based on that
> source, calls the respective device ISR directly.
>
> The issue I see here is, the ISR on _a_ device (UART in this case)
> is happening even before UART resume and DPM resume has been completed.
> If this is the case, then it is surely asking for trouble. Because not
> just clocks, but even driver state machine is already in suspend state
> when the ISR is called.
If the driver state machine is in the suspend state when the ISR is
called, then the ISR should realize it is handling a wakeup event
instead of a normal I/O event. All it needs to do is turn off the
interrupt source; the event itself will be taken care of during the
device's resume callback.
Alan Stern
^ permalink raw reply
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
From: Santosh @ 2011-08-27 6:30 UTC (permalink / raw)
To: Alan Stern
Cc: Tero Kristo, Felipe Balbi, Partha Basak, Govindraj.R,
Keshava Munegowda, linux-pm, linux-omap
In-Reply-To: <Pine.LNX.4.44L0.1108261429340.2275-100000@netrider.rowland.org>
Alen,
On Saturday 27 August 2011 12:06 AM, Alan Stern wrote:
> On Fri, 26 Aug 2011, Govindraj.R wrote:
>
>> Hello,
>>
>> During system_wide_suspend pm runtime is disabled.
>> I.e. __pm_runtime_disable is called from __device_suspend.
>> Now, if a wakeup interrupt is triggered and the wakeup device irq handler
>> is called even before device_resume and pm_runtime_enable happens,
>> the device irq_handler proceeds to enable clock with runtime API to
>> handle wakeup event.
>>
>> Wouldn't this result in system wide abort since the pm_runtime is not enabled
>> yet from dpm_resume?
>> As we end up accessing regs after doing runtime get_sync.
>>
>> Looks like this scenario is not handled currently.
>> Or Am I missing something here?
>
> I don't have the complete picture, but it seems that the IRQ handler
> needs to check the return code from pm_runtime_get_sync(). If the call
> fails then the handler shouldn't try to access the device registers.
>
> In the case of a genuine wakeup event, the event should be handled
> later on as part of the resume or resume_noirq processing.
>
> However, this does raise a potential problem. What happens if the
> clocks are needed in order to turn off the IRQ source? Runtime PM
> won't allow the clocks to be enabled until after interrupts have been
> enabled, and by then it will be too late -- the source will have caused
> an interrupt storm.
>
I might be wrong here, but after discussion with Govindraj on this
issue, it seems there is a flaw in the way OMAP chain handler
handling the child interrupts.
On OMAP, we have special interrupt wakeup source at PRCM level and
many devices can trigger wakeup from low power via this common
interrupt source. The common interrupt source upon wakeup from low
power state, decodes the source of interrupt and based on that
source, calls the respective device ISR directly.
The issue I see here is, the ISR on _a_ device (UART in this case)
is happening even before UART resume and DPM resume has been completed.
If this is the case, then it is surely asking for trouble. Because not
just clocks, but even driver state machine is already in suspend state
when the ISR is called.
Regards
Santosh
^ permalink raw reply
* Re: Function to tell S1 standby from STR
From: Maksim Rayskiy @ 2011-08-26 23:00 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm
In-Reply-To: <201108270045.41314.rjw@sisk.pl>
Hi,
On Fri, Aug 26, 2011 at 3:45 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Hi,
>
> On Saturday, August 27, 2011, Maksim Rayskiy wrote:
>> Hi,
>>
>> How can a driver in a suspend/resume call tell if the request is for
>> STR or S1? On SoCs I am working with drivers need to take some extra
>> steps to preserve context when STR is requested.
>>
>> I had to add platform-dependent api to do that, but I figured I am not
>> the only one having to deal with this. There are some comments in
>> arch/arm/mach-at91/pm.c regarding having to treat S1 and S3
>> differently because of wakeup source dependency on clock.
>>
>> And unfortunately these differences has to be taken care of in the
>> drivers, not platform code, because in some cases only device driver
>> knows what represents the hardware context that needs to be saved.
>
> Why not to save the same stuff for "S1" and "S3"?
One of the reasons is speed - you want recovery from S1 be as fast as
possible, restoring S3 context would slow things down.
The other reason is that device comes up in entirely different states,
so it has to be treated differently. It is not only a
matter of saving stuff, you may have to go through different
re-initialization sequence.
If you look at PCI EHCI resume code, you will see that it treats
complete power down and suspend not in the same way. Unfortunately,
for some devices it is hard to tell for sure where it is coming from -
S1 or S3.
Maksim.
^ permalink raw reply
* Re: Function to tell S1 standby from STR
From: Rafael J. Wysocki @ 2011-08-26 22:45 UTC (permalink / raw)
To: Maksim Rayskiy; +Cc: linux-pm
In-Reply-To: <CAFVyGY7NE4P4hZWSkzOhYbD-vX6b6oZT9y15LeZsQeh8S-u8iA@mail.gmail.com>
Hi,
On Saturday, August 27, 2011, Maksim Rayskiy wrote:
> Hi,
>
> How can a driver in a suspend/resume call tell if the request is for
> STR or S1? On SoCs I am working with drivers need to take some extra
> steps to preserve context when STR is requested.
>
> I had to add platform-dependent api to do that, but I figured I am not
> the only one having to deal with this. There are some comments in
> arch/arm/mach-at91/pm.c regarding having to treat S1 and S3
> differently because of wakeup source dependency on clock.
>
> And unfortunately these differences has to be taken care of in the
> drivers, not platform code, because in some cases only device driver
> knows what represents the hardware context that needs to be saved.
Why not to save the same stuff for "S1" and "S3"?
Rafael
^ permalink raw reply
* Function to tell S1 standby from STR
From: Maksim Rayskiy @ 2011-08-26 22:32 UTC (permalink / raw)
To: linux-pm
Hi,
How can a driver in a suspend/resume call tell if the request is for
STR or S1? On SoCs I am working with drivers need to take some extra
steps to preserve context when STR is requested.
I had to add platform-dependent api to do that, but I figured I am not
the only one having to deal with this. There are some comments in
arch/arm/mach-at91/pm.c regarding having to treat S1 and S3
differently because of wakeup source dependency on clock.
And unfortunately these differences has to be taken care of in the
drivers, not platform code, because in some cases only device driver
knows what represents the hardware context that needs to be saved.
Regards,
Maksim.
^ permalink raw reply
* Re: [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
From: Rafael J. Wysocki @ 2011-08-26 20:56 UTC (permalink / raw)
To: markgross; +Cc: Linux PM mailing list, linux-omap, Jean Pihet
In-Reply-To: <20110826165427.GC9437@gvim.org>
On Friday, August 26, 2011, mark gross wrote:
> On Fri, Aug 26, 2011 at 11:25:13AM +0900, MyungJoo Ham wrote:
> > On Fri, Jul 1, 2011 at 12:11 AM, <jean.pihet@newoldbits.com> wrote:
> > > @@ -129,19 +146,19 @@ static const struct file_operations pm_qos_power_fops = {
> > > /* unlocked internal variant */
> > > static inline int pm_qos_get_value(struct pm_qos_object *o)
> > > {
> > > - if (plist_head_empty(&o->requests))
> > > + if (plist_head_empty(o->requests))
> > > return o->default_value;
> > >
> > > switch (o->type) {
> > > - case PM_QOS_MIN:
> > > - return plist_first(&o->requests)->prio;
> > > + case PM_QOS_MIN:
> > > + return plist_first(o->requests)->prio;
> > >
> > > - case PM_QOS_MAX:
> > > - return plist_last(&o->requests)->prio;
> > > + case PM_QOS_MAX:
> > > + return plist_last(o->requests)->prio;
> > >
> > > - default:
> > > - /* runtime check for not using enum */
> > > - BUG();
> > > + default:
> > > + /* runtime check for not using enum */
> > > + BUG();
> > > }
> > > }
> >
> > Hello,
> >
> >
> > Sorry to jump in this late, but, I've got a question in choosing QoS
> > value from the list with pm_qos_get_value function and pm_qos_type.
> >
> > For QoS objects such as network throughput, wouldn't "PM_QOS_ADD" be
> > more appropriate than PM_QOS_MAX?
> > If A is requesting 10MB/s on NIC-X and B is requesting 5MB/s on NIC-X,
> > I guess PM QOS should say NIC-X that it needs to provide 15MB/s, not
> > 10MB/s. Or, are we assuming that A and B will never put streams at the
> > same time?
>
> This was brought up a few years back as well. The reason we kept the
> aggregate QoS for network Throughput as a max instead of a sum was that
> there where already a number of interfaces for network shaping and we
> didn't have a good answer to the problem of what to do when the
> throughput qos requested exceeds hardware capabilities.
>
> Now that I have more experience with handsets I'm not sure it makes any
> practical difference to sum or max the throughput qos requests. So if
> someone would like it to aggregate throughputs by summation of requests
> that could be done.
>
> It turns out its the latency requests that are really used.
Moreover, the throughput QoS is really difficult to handle, because
quite often there's no good mapping between energy-saving measures one
can use and the resulting throughput.
Thanks,
Rafael
^ permalink raw reply
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
From: Rafael J. Wysocki @ 2011-08-26 20:52 UTC (permalink / raw)
To: Govindraj.R
Cc: Tero Kristo, Felipe Balbi, Partha Basak, Keshava Munegowda,
linux-pm, linux-omap
In-Reply-To: <1314363693-20831-1-git-send-email-govindraj.raja@ti.com>
On Friday, August 26, 2011, Govindraj.R wrote:
> Hello,
>
> During system_wide_suspend pm runtime is disabled.
> I.e. __pm_runtime_disable is called from __device_suspend.
> Now, if a wakeup interrupt is triggered and the wakeup device irq handler
> is called even before device_resume and pm_runtime_enable happens,
> the device irq_handler proceeds to enable clock with runtime API to
> handle wakeup event.
>
> Wouldn't this result in system wide abort since the pm_runtime is not enabled
> yet from dpm_resume?
> As we end up accessing regs after doing runtime get_sync.
>
> Looks like this scenario is not handled currently.
> Or Am I missing something here?
To be precise, what do you mean by "wakeup interrupt"?
Rafael
^ permalink raw reply
* Sysfs nodes deleted and recreated on SMP suspend
From: Jeff Ohlstein @ 2011-08-26 20:08 UTC (permalink / raw)
To: linux-pm; +Cc: LKML
So I have been working with the cpufreq sysfs nodes on an SMP system,
and one thing I noticed is that they go away each time I suspend and
resume. This is due to the use of the hotplug mechanism for suspend. I
am able to handle these failures by checking for the error and reopening
the file, but having to do this each time the system suspends seems
unnecessary to me.
Does anyone see any value in making these nodes stay around, at least in
the suspend case of hotplug? I understand that they should go away on
systems where a cpu can actually be physically removed, but if we are
just suspending it seems like we should be as transparent to userspace
as possible.
Jeff
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
From: Alan Stern @ 2011-08-26 18:36 UTC (permalink / raw)
To: Govindraj.R
Cc: Partha Basak, Tero Kristo, Felipe Balbi, Keshava Munegowda,
linux-pm, linux-omap
In-Reply-To: <1314363693-20831-1-git-send-email-govindraj.raja@ti.com>
On Fri, 26 Aug 2011, Govindraj.R wrote:
> Hello,
>
> During system_wide_suspend pm runtime is disabled.
> I.e. __pm_runtime_disable is called from __device_suspend.
> Now, if a wakeup interrupt is triggered and the wakeup device irq handler
> is called even before device_resume and pm_runtime_enable happens,
> the device irq_handler proceeds to enable clock with runtime API to
> handle wakeup event.
>
> Wouldn't this result in system wide abort since the pm_runtime is not enabled
> yet from dpm_resume?
> As we end up accessing regs after doing runtime get_sync.
>
> Looks like this scenario is not handled currently.
> Or Am I missing something here?
I don't have the complete picture, but it seems that the IRQ handler
needs to check the return code from pm_runtime_get_sync(). If the call
fails then the handler shouldn't try to access the device registers.
In the case of a genuine wakeup event, the event should be handled
later on as part of the resume or resume_noirq processing.
However, this does raise a potential problem. What happens if the
clocks are needed in order to turn off the IRQ source? Runtime PM
won't allow the clocks to be enabled until after interrupts have been
enabled, and by then it will be too late -- the source will have caused
an interrupt storm.
Alan Stern
^ permalink raw reply
* Re: [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
From: mark gross @ 2011-08-26 16:54 UTC (permalink / raw)
To: MyungJoo Ham; +Cc: markgross, Linux PM mailing list, linux-omap, Jean Pihet
In-Reply-To: <CAJ0PZbRCvoh8-rJAR92Ak_JPk4FyR0dp_OeKOUkWtD5AdFsPCw@mail.gmail.com>
On Fri, Aug 26, 2011 at 11:25:13AM +0900, MyungJoo Ham wrote:
> On Fri, Jul 1, 2011 at 12:11 AM, <jean.pihet@newoldbits.com> wrote:
> > @@ -129,19 +146,19 @@ static const struct file_operations pm_qos_power_fops = {
> > /* unlocked internal variant */
> > static inline int pm_qos_get_value(struct pm_qos_object *o)
> > {
> > - if (plist_head_empty(&o->requests))
> > + if (plist_head_empty(o->requests))
> > return o->default_value;
> >
> > switch (o->type) {
> > - case PM_QOS_MIN:
> > - return plist_first(&o->requests)->prio;
> > + case PM_QOS_MIN:
> > + return plist_first(o->requests)->prio;
> >
> > - case PM_QOS_MAX:
> > - return plist_last(&o->requests)->prio;
> > + case PM_QOS_MAX:
> > + return plist_last(o->requests)->prio;
> >
> > - default:
> > - /* runtime check for not using enum */
> > - BUG();
> > + default:
> > + /* runtime check for not using enum */
> > + BUG();
> > }
> > }
>
> Hello,
>
>
> Sorry to jump in this late, but, I've got a question in choosing QoS
> value from the list with pm_qos_get_value function and pm_qos_type.
>
> For QoS objects such as network throughput, wouldn't "PM_QOS_ADD" be
> more appropriate than PM_QOS_MAX?
> If A is requesting 10MB/s on NIC-X and B is requesting 5MB/s on NIC-X,
> I guess PM QOS should say NIC-X that it needs to provide 15MB/s, not
> 10MB/s. Or, are we assuming that A and B will never put streams at the
> same time?
This was brought up a few years back as well. The reason we kept the
aggregate QoS for network Throughput as a max instead of a sum was that
there where already a number of interfaces for network shaping and we
didn't have a good answer to the problem of what to do when the
throughput qos requested exceeds hardware capabilities.
Now that I have more experience with handsets I'm not sure it makes any
practical difference to sum or max the throughput qos requests. So if
someone would like it to aggregate throughputs by summation of requests
that could be done.
It turns out its the latency requests that are really used.
The network qos parameters also have a problem with discriminating
between what physical interface the QoS is for. This limitation in the
ABI is partially addressed with some of the work that Jean Pihet's
patches are doing.
--mark
^ 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