* [PATCH] PM: HIBERNATION: skip the swap size check if the snapshot image size is anticipative
From: Barry Song @ 2011-11-04 7:37 UTC (permalink / raw)
To: linux-pm, pavel, rjw
Cc: workgroup.linux, Xiangzhen Ye, linux-kernel, linux-arm-kernel,
Barry Song
From: Barry Song <Baohua.Song@csr.com>
Current swsusp requires swap partitions even larger than real saved pages
due to the worst compress ratio:
but for an embedded system, which has limited storage space, then it might
can't give the big size partition to save snapshot.
In the another way, some embedded systems can definitely know the most size
needed for snapshot since they run some specific application lists.
So this patch provides the possibility for bootloader to tell kernel even
the system has a little snapshot partition, but it is still enough.
For example, if the system need to save 120MB memory, origin swsusp will require
a 130MB partition to save snapshot. but if users know 30MB is enough for them(
compressed image will be less than 30MB), they just make a 30MB partition.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Cc: Xiangzhen Ye <Xiangzhen.Ye@csr.com>
---
this is another patch after I provide resumewait/resumedelay kernel params
to make swsusp support embedded systems better.
This patch is tested on CSR SiRFprimaII platform.
Documentation/kernel-parameters.txt | 7 +++++++
kernel/power/swap.c | 13 +++++++++++++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index a0c5c5f..2ad2e9c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2277,6 +2277,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
in <PAGE_SIZE> units (needed only for swap files).
See Documentation/power/swsusp-and-swap-files.txt
+ swapenough [SWSUSP]
+ Tell kernel the swap partition size is enough and let kernel
+ skip checking whether the swap partition has enough size to
+ save snapshot.
+ It is used for embedded systems, typically using NAND and SD
+ card, which have not large space.
+
resumedelay= [HIBERNATION] Delay (in seconds) to pause before attempting to
read the resume files
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index 11a594c..97c30b5 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -36,6 +36,8 @@
#define HIBERNATE_SIG "S1SUSPEND"
+static int swapenough;
+
/*
* The swap map is a data structure used for keeping track of each page
* written to a swap partition. It consists of many swap_map_page
@@ -772,6 +774,9 @@ static int enough_swap(unsigned int nr_pages, unsigned int flags)
unsigned int free_swap = count_swap_pages(root_swap, 1);
unsigned int required;
+ if (swapenough)
+ return 1;
+
pr_debug("PM: Free swap pages: %u\n", free_swap);
required = PAGES_FOR_IO + ((flags & SF_NOCOMPRESS_MODE) ?
@@ -1449,3 +1454,11 @@ static int swsusp_header_init(void)
}
core_initcall(swsusp_header_init);
+
+static int __init swapenough_setup(char *str)
+{
+ swapenough = 1;
+ return 1;
+}
+
+__setup("swapenough", swapenough_setup);
--
1.7.1
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply related
* [PATCH] PM: HIBERNATION: skip the swap size check if the snapshot image size is anticipative
From: Barry Song @ 2011-11-04 7:36 UTC (permalink / raw)
To: linux-pm, pavel, rjw
Cc: Xiangzhen Ye, linux-kernel, linux-arm-kernel, Barry Song
From: Barry Song <Baohua.Song@csr.com>
Current swsusp requires swap partitions even larger than real saved pages
due to the worst compress ratio:
but for an embedded system, which has limited storage space, then it might
can't give the big size partition to save snapshot.
In the another way, some embedded systems can definitely know the most size
needed for snapshot since they run some specific application lists.
So this patch provides the possibility for bootloader to tell kernel even
the system has a little snapshot partition, but it is still enough.
For example, if the system need to save 120MB memory, origin swsusp will require
a 130MB partition to save snapshot. but if users know 30MB is enough for them(
compressed image will be less than 30MB), they just make a 30MB partition.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Cc: Xiangzhen Ye <Xiangzhen.Ye@csr.com>
---
this is another patch after I provide resumewait/resumedelay kernel params
to make swsusp support embedded systems better.
This patch is tested on CSR SiRFprimaII platform.
Documentation/kernel-parameters.txt | 7 +++++++
kernel/power/swap.c | 13 +++++++++++++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index a0c5c5f..2ad2e9c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2277,6 +2277,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
in <PAGE_SIZE> units (needed only for swap files).
See Documentation/power/swsusp-and-swap-files.txt
+ swapenough [SWSUSP]
+ Tell kernel the swap partition size is enough and let kernel
+ skip checking whether the swap partition has enough size to
+ save snapshot.
+ It is used for embedded systems, typically using NAND and SD
+ card, which have not large space.
+
resumedelay= [HIBERNATION] Delay (in seconds) to pause before attempting to
read the resume files
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index 11a594c..97c30b5 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -36,6 +36,8 @@
#define HIBERNATE_SIG "S1SUSPEND"
+static int swapenough;
+
/*
* The swap map is a data structure used for keeping track of each page
* written to a swap partition. It consists of many swap_map_page
@@ -772,6 +774,9 @@ static int enough_swap(unsigned int nr_pages, unsigned int flags)
unsigned int free_swap = count_swap_pages(root_swap, 1);
unsigned int required;
+ if (swapenough)
+ return 1;
+
pr_debug("PM: Free swap pages: %u\n", free_swap);
required = PAGES_FOR_IO + ((flags & SF_NOCOMPRESS_MODE) ?
@@ -1449,3 +1454,11 @@ static int swsusp_header_init(void)
}
core_initcall(swsusp_header_init);
+
+static int __init swapenough_setup(char *str)
+{
+ swapenough = 1;
+ return 1;
+}
+
+__setup("swapenough", swapenough_setup);
--
1.7.1
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply related
* [PATCH] ACPI: Export FADT pm_profile integer value to userspace
From: Thomas Renninger @ 2011-11-04 2:33 UTC (permalink / raw)
To: linux-acpi; +Cc: linux-pm
There are a lot userspace approaches to detect the usage of the
platform (laptop, workstation, server, ...) and adjust kernel tunables
accordingly (io/process scheduler, power management, ...).
These approaches need constant maintaining and are ugly to implement
(detect PCMCIA controller -> laptop,
does not work on recent systems anymore, ...)
On ACPI systems there is an easy and reliable way (if implemented
in BIOS and most recent platforms have this value set).
-> export it to userspace.
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: lenb@kernel.org
---
Documentation/ABI/stable/sysfs-acpi-pmprofile | 22 ++++++++++++++++++++++
drivers/acpi/sysfs.c | 14 +++++++++++++-
2 files changed, 35 insertions(+), 1 deletions(-)
create mode 100644 Documentation/ABI/stable/sysfs-acpi-pmprofile
diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile
new file mode 100644
index 0000000..964c7a8
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile
@@ -0,0 +1,22 @@
+What: /sys/firmware/acpi/pm_profile
+Date: 03-Nov-2011
+KernelVersion: v3.2
+Contact: linux-acpi@vger.kernel.org
+Description: The ACPI pm_profile sysfs interface exports the platform
+ power management (and performance) requirement expectations
+ as provided by BIOS. The integer value is directly passed as
+ retrieved from the FADT ACPI table.
+Values: For possible values see ACPI specification:
+ 5.2.9 Fixed ACPI Description Table (FADT)
+ Field: Preferred_PM_Profile
+
+ Currently these values are defined by spec:
+ 0 Unspecified
+ 1 Desktop
+ 2 Mobile
+ 3 Workstation
+ 4 Enterprise Server
+ 5 SOHO Server
+ 6 Appliance PC
+ 7 Performance Server
+ >7 Reserved
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index c538d0e..9f66181 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -706,11 +706,23 @@ static void __exit interrupt_stats_exit(void)
return;
}
+static ssize_t
+acpi_show_profile(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", acpi_gbl_FADT.preferred_profile);
+}
+
+static const struct device_attribute pm_profile_attr =
+ __ATTR(pm_profile, S_IRUGO, acpi_show_profile, NULL);
+
int __init acpi_sysfs_init(void)
{
int result;
result = acpi_tables_sysfs_init();
-
+ if (result)
+ return result;
+ result = sysfs_create_file(acpi_kobj, &pm_profile_attr.attr);
return result;
}
--
1.7.6.1
^ permalink raw reply related
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Tejun Heo @ 2011-11-03 21:39 UTC (permalink / raw)
To: Andrew Watts; +Cc: linux-pm, Dmitry Torokhov, linux-kernel
In-Reply-To: <20111103184559.GA3295@zeus>
Hello, Andrew.
On Thu, Nov 03, 2011 at 01:46:19PM -0500, Andrew Watts wrote:
> On Thu, Nov 03, 2011 at 08:59:56AM -0700, Tejun Heo wrote:
> > Andrew, just in case, can you please double check that you're
> > reverting only that single commit (not all the ones afterwards) and
> > the test results? If they're all okay, can you please trigger the
> > problem, wait a while, trigger sysrq-t and attach the kernel log?
>
> Hi Tejun.
>
> I am only reverting 8ee294cd9def0004887da7f44b80563493b0a097 though I first
> revert part of 1d64b655dc083df5c5ac39945ccbbc6532903bf1 so it reverts
> cleanly.
>
> I am very sure of my test results; normally I get 4-5 bad resumes on a 20
> hibernate loop and get no bad resumes with the commit reverted. I have
> been very thorough in my testing to ensure I am not generating false
> positives or false negatives (repeating the loops many times).
Thanks. Yeah, this is odd & interesting.
> Below is the output you asked for (sysrq t).
>
> Thanks.
>
> ~ Andy
>
> ======================
>
>
> kernel: [ 345.226523] SysRq : Show State
> kernel: [ 345.226531] task PC stack pid father
> kernel: [ 345.226535] init S f4a47b68 5488 1 0 0x00000000
> kernel: [ 345.226765] kthreadd S 00000000 7172 2 0 0x00000000
This is missing all stack traces. Can you please turn on
FRAME_POINTER and adjust log level such that all stack dumps are
included too?
Thank you.
--
tejun
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Andrew Watts @ 2011-11-03 18:46 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-pm, Dmitry Torokhov, linux-kernel
In-Reply-To: <20111103155956.GG4417@google.com>
On Thu, Nov 03, 2011 at 08:59:56AM -0700, Tejun Heo wrote:
> Andrew, just in case, can you please double check that you're
> reverting only that single commit (not all the ones afterwards) and
> the test results? If they're all okay, can you please trigger the
> problem, wait a while, trigger sysrq-t and attach the kernel log?
Hi Tejun.
I am only reverting 8ee294cd9def0004887da7f44b80563493b0a097 though I first
revert part of 1d64b655dc083df5c5ac39945ccbbc6532903bf1 so it reverts
cleanly.
I am very sure of my test results; normally I get 4-5 bad resumes on a 20
hibernate loop and get no bad resumes with the commit reverted. I have
been very thorough in my testing to ensure I am not generating false
positives or false negatives (repeating the loops many times).
Below is the output you asked for (sysrq t).
Thanks.
~ Andy
======================
kernel: [ 345.226523] SysRq : Show State
kernel: [ 345.226531] task PC stack pid father
kernel: [ 345.226535] init S f4a47b68 5488 1 0 0x00000000
kernel: [ 345.226765] kthreadd S 00000000 7172 2 0 0x00000000
kernel: [ 345.226819] ksoftirqd/0 S 0000003f 7472 3 2 0x00000000
kernel: [ 345.226887] kworker/u:0 S 00000000 6404 5 2 0x00000000
kernel: [ 345.226956] rcu_kthread S c10ce899 7324 6 2 0x00000000
kernel: [ 345.227032] watchdog/0 S 0000000b 7616 7 2 0x00000000
kernel: [ 345.227096] cpuset S f5c55f58 7696 8 2 0x00000000
kernel: [ 345.227160] khelper S f5c57f58 7696 9 2 0x00000000
kernel: [ 345.227224] kworker/u:1 S 00000000 5800 10 2 0x00000000
kernel: [ 345.227284] netns S f5c69f58 7660 13 2 0x00000000
kernel: [ 345.227348] sync_supers S f5ca5fbc 7712 227 2 0x00000000
kernel: [ 345.227425] bdi-default S f5ca7e70 7392 229 2 0x00000000
kernel: [ 345.227507] kblockd S f5cd7f58 7660 231 2 0x00000000
kernel: [ 345.227509] ata_sff S f5cf1f58 7660 318 2 0x00000000
kernel: [ 345.227509] khubd S c13f0020 5844 328 2 0x00000000
kernel: [ 345.227509] md S f5ce1f58 7660 335 2 0x00000000
kernel: [ 345.227509] cfg80211 S f5cfdf58 7660 345 2 0x00000000
kernel: [ 345.227509] kworker/0:1 S f49ae800 6248 346 2 0x00000000
kernel: [ 345.227509] rpciod S f5ce5f58 7660 444 2 0x00000000
kernel: [ 345.227509] khungtaskd S 00000000 7564 461 2 0x00000000
kernel: [ 345.227509] kswapd0 S f5d25ea8 7444 467 2 0x00000000
kernel: [ 345.227509] fsnotify_mark S 00000000 7668 532 2 0x00000000
kernel: [ 345.227509] nfsiod S f5f05f58 7660 544 2 0x00000000
kernel: [ 345.227509] crypto S f5f19f58 7660 549 2 0x00000000
kernel: [ 345.227509] ttm_swap S f5f13f58 7660 628 2 0x00000000
kernel: [ 345.227509] kworker/0:2 S 000ce000 6776 768 2 0x00000000
kernel: [ 345.227509] kpsmoused S f577ff58 7660 776 2 0x00000000
kernel: [ 345.227509] kjournald S 0000004f 6524 834 2 0x00000000
kernel: [ 345.227509] udevd S f500de68 6192 866 1 0x00000000
kernel: [ 345.227509] kworker/0:3 S f5115f20 6860 1043 2 0x00000000
kernel: [ 345.227509] pccardd S f52dff24 7344 1048 2 0x00000000
kernel: [ 345.227509] pccardd S f530bf24 7344 1050 2 0x00000000
kernel: [ 345.227509] flush-3:0 S c10d787b 6432 1116 2 0x00000000
kernel: [ 345.227509] syslogd S 00000000 6164 1167 1 0x00000000
kernel: [ 345.227509] klogd S 00000058 6612 1171 1 0x00000000
kernel: [ 345.227509] inetd S 00000000 6440 1283 1 0x00000000
kernel: [ 345.227509] sshd S 00000000 6332 1286 1 0x00000000
kernel: [ 345.227509] acpid S f539daf4 6248 1293 1 0x00000000
kernel: [ 345.227509] dbus-daemon S 00000000 6356 1301 1 0x00000000
kernel: [ 345.227509] hald S f5c649e0 6180 1306 1 0x00000000
kernel: [ 345.227509] hald S f77d82c4 7076 1308 1 0x00000000
kernel: [ 345.227509] hald-runner S c11f5171 6356 1307 1306 0x00000000
kernel: [ 345.227509] hald-addon-inpu S 0222270e 6356 1342 1307 0x00000000
kernel: [ 345.227509] hald-addon-gene S 00000010 6592 1344 1307 0x00000000
kernel: [ 345.227509] hald-addon-acpi S 00000001 6572 1356 1307 0x00000000
kernel: [ 345.227509] crond S f53cdf40 6632 1363 1 0x00000000
kernel: [ 345.227509] atd S f53d1fb4 6532 1365 1 0x00000000
kernel: [ 345.227509] sendmail S f53f1f40 6268 1368 1 0x00000000
kernel: [ 345.227509] sendmail S f517c800 6176 1371 1 0x00000000
kernel: [ 345.227509] udevd S f53dde8c 6592 1377 866 0x00000000
kernel: [ 345.227509] udevd S f57a8000 6924 1378 866 0x00000000
kernel: [ 345.227509] vnstatd S 00000000 6556 1421 1 0x00000000
kernel: [ 345.227509] auditd S f5cb3d90 6584 1427 1 0x00000000
kernel: [ 345.227509] auditd S c1029e3c 6072 1428 1 0x00000000
kernel: [ 345.227509] kauditd S f481bf2c 7440 1430 2 0x00000000
kernel: [ 345.227509] bash S f5009b80 5844 1613 1 0x00000080
kernel: [ 345.227509] agetty S f53e3e04 6748 1614 1 0x00000080
kernel: [ 345.227509] agetty S f53e5e04 6748 1615 1 0x00000080
kernel: [ 345.227509] agetty S f4819e04 6748 1616 1 0x00000080
kernel: [ 345.227509] agetty S f53f3e04 6704 1617 1 0x00000080
kernel: [ 345.227509] agetty S f4971e04 6404 1618 1 0x00000080
kernel: [ 345.227509] startx S f5ddb700 6308 1633 1613 0x00000080
kernel: [ 345.227509] xinit S f49b5f9c 6592 1649 1633 0x00000080
kernel: [ 345.227509] X S f49d5944 5468 1650 1649 0x00400080
kernel: [ 345.227509] sh S f51e7180 6480 1658 1649 0x00000080
kernel: [ 345.227509] xscreensaver S f53f1f40 5800 1664 1658 0x00000080
kernel: [ 345.227509] ssh-agent S 00000000 6440 1667 1 0x00000080
kernel: [ 345.227509] dbus-launch S 00000000 6440 1672 1 0x00000080
kernel: [ 345.227509] dbus-daemon S 00000000 6356 1674 1 0x00000080
kernel: [ 345.227509] xfce4-session S f4a0daf4 5800 1676 1658 0x00000080
kernel: [ 345.227509] xfconfd S 00000033 5728 1678 1 0x00000080
kernel: [ 345.227509] xfwm4 S c11f5234 5896 1683 1 0x00000080
kernel: [ 345.227509] xfce4-panel S c11f5234 5800 1685 1 0x00000080
kernel: [ 345.227509] xfce4-panel S 00000000 7360 1745 1 0x00000080
kernel: [ 345.227509] Thunar S f53f1f40 5800 1687 1 0x00000080
kernel: [ 345.227509] xfsettingsd S 00000010 6592 1688 1 0x00000080
kernel: [ 345.227509] xfdesktop S f53f1f40 5800 1690 1 0x00000080
kernel: [ 345.227509] gkrellm S f29e981d 5728 1694 1 0x00000080
kernel: [ 345.227509] tilda S 00000010 5876 1696 1 0x00000080
kernel: [ 345.227509] tilda S 00000000 7360 1720 1 0x00000080
kernel: [ 345.227509] autocutsel S c11f5234 6200 1698 1 0x00000080
kernel: [ 345.227509] orage S c11f5171 5728 1700 1 0x00000080
kernel: [ 345.227509] gam_server S 00000246 5728 1702 1 0x00000080
kernel: [ 345.227509] devilspie S f4aafaf4 6312 1706 1 0x00000080
kernel: [ 345.227509] xterm S 00000000 5728 1710 1 0x00000080
kernel: [ 345.227509] xfce4-settings- S f4ad1b00 6356 1715 1 0x00000080
kernel: [ 345.227509] xfce4-menu-plug S 00200246 6268 1717 1685 0x00000080
kernel: [ 345.227509] gnome-pty-helpe S 00000003 6532 1718 1696 0x00000080
kernel: [ 345.227509] bash S f4ae1e04 6704 1719 1696 0x00000080
kernel: [ 345.227509] tail S f3c03fb4 5800 1724 1710 0x00000080
kernel: [ 345.227509] gvfsd S f3c07af0 5800 1726 1 0x00000080
kernel: [ 345.227509] xfce4-weather-p S f4aa3b68 5800 1729 1685 0x00000080
kernel: [ 345.227509] xfce4-notes-plu S f3c05af4 5800 1730 1685 0x00000080
kernel: [ 345.227509] xfce4-battery-p S f4aed630 6180 1731 1685 0x00000080
kernel: [ 345.227509] xfce4-mixer-plu S 00000000 6200 1732 1685 0x00000080
kernel: [ 345.227509] task0 S 00000000 6484 1740 1685 0x00000080
kernel: [ 345.227509] gvfs-fuse-daemo S c1029e3c 7176 1736 1 0x00000080
kernel: [ 345.227509] gvfs-fuse-daemo S f4aebdc4 6944 1737 1 0x00000080
kernel: [ 345.227509] gvfs-fuse-daemo S f4aeef04 7268 1738 1 0x00000080
kernel: [ 345.227509] gvfs-fuse-daemo S 00000000 6592 1739 1 0x00000080
kernel: [ 345.227509] xterm S f3c69aa0 6160 1744 1 0x00000080
kernel: [ 345.227509] bash S f3c0cb00 6876 1747 1744 0x00000080
kernel: [ 345.227509] bash S 7f1c0300 5728 1763 1747 0x00000080
kernel: [ 345.227509] flush-0:18 S f3d13f24 7616 1809 2 0x00000080
kernel: [ 345.227509] kworker/u:2 S 00000000 6768 1810 2 0x00000080
kernel: [ 345.227509] kworker/u:3 S 00000000 6552 1811 2 0x00000080
kernel: [ 345.227509] kworker/u:4 S 00000000 6768 1812 2 0x00000080
kernel: [ 345.227509] kworker/u:5 S 00000000 6768 1813 2 0x00000080
kernel: [ 345.227509] kworker/u:6 S 00000000 6768 1814 2 0x00000080
kernel: [ 345.227509] kworker/u:7 S 00000000 7124 1815 2 0x00000080
kernel: [ 345.227509] kworker/u:8 S 00000000 6864 1816 2 0x00000080
kernel: [ 345.227509] kworker/u:9 S 00000000 6356 1817 2 0x00000080
kernel: [ 345.227509] kworker/u:10 S 00000000 6864 1818 2 0x00000080
kernel: [ 345.227509] kworker/u:11 S 00000000 6600 1819 2 0x00000080
kernel: [ 345.227509] kworker/u:12 S 00000000 7356 1820 2 0x00000080
kernel: [ 345.227509] kworker/u:13 S 00000000 6356 1821 2 0x00000080
kernel: [ 345.227509] kworker/u:14 S 00000000 7356 1822 2 0x00000080
kernel: [ 345.227509] kworker/u:15 S 00000000 7356 1823 2 0x00000080
kernel: [ 345.227509] kworker/u:16 S 00000000 7136 1824 2 0x00000080
kernel: [ 345.227509] kworker/u:17 S 00000000 6600 1825 2 0x00000080
kernel: [ 345.227509] kworker/u:18 S 00000000 7356 1826 2 0x00000080
kernel: [ 345.227509] kworker/u:19 S 00000000 7136 1827 2 0x00000080
kernel: [ 345.227509] kworker/u:20 S 00000000 6600 1828 2 0x00000080
kernel: [ 345.227509] kworker/u:21 S 00000000 6356 1829 2 0x00000080
kernel: [ 345.227509] kworker/u:22 S 00000000 7136 1830 2 0x00000080
kernel: [ 345.227509] kworker/u:23 S 00000000 6864 1831 2 0x00000080
kernel: [ 345.227509] kworker/u:24 S 00000000 7120 1832 2 0x00000080
kernel: [ 345.227509] kworker/u:25 S 00000000 6768 1833 2 0x00000080
kernel: [ 345.227509] kworker/u:26 S 00000000 7356 1834 2 0x00000080
kernel: [ 345.227509] kworker/u:27 S 00000000 6768 1835 2 0x00000080
kernel: [ 345.227509] kworker/u:28 S 00000000 6404 1836 2 0x00000080
kernel: [ 345.227509] kworker/u:29 S 00000000 7224 1837 2 0x00000080
kernel: [ 345.227509] kworker/u:30 S 00000000 6404 1838 2 0x00000080
kernel: [ 345.227509] kworker/u:31 S 00000000 6768 1839 2 0x00000080
kernel: [ 345.227509] kworker/u:32 S 00000000 6568 1840 2 0x00000080
kernel: [ 345.227509] kworker/u:33 S 00000000 6768 1841 2 0x00000080
kernel: [ 345.227509] kworker/u:34 S 00000000 6404 1842 2 0x00000080
kernel: [ 345.227509] kworker/u:35 S 00000000 7248 1850 2 0x00000080
kernel: [ 345.227509] kworker/u:36 S 00000000 6404 1851 2 0x00000080
kernel: [ 345.227509] kworker/u:37 S 00000000 6768 1852 2 0x00000080
kernel: [ 345.227509] kworker/u:38 S 00000000 6568 1853 2 0x00000080
kernel: [ 345.227509] kworker/u:39 S 00000000 7356 1854 2 0x00000080
kernel: [ 345.227509] kworker/u:40 S 00000000 7356 1855 2 0x00000080
kernel: [ 345.227509] kworker/u:41 S 00000000 7672 1864 2 0x00000080
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Tejun Heo @ 2011-11-03 15:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-pm, Andrew Watts, linux-kernel
In-Reply-To: <20111102163109.GA29430@core.coreip.homeip.net>
Hello,
On Wed, Nov 02, 2011 at 09:31:09AM -0700, Dmitry Torokhov wrote:
> On Wed, Nov 02, 2011 at 11:02:09AM -0500, Andrew Watts wrote:
> > On Tue, Nov 01, 2011 at 10:46:58PM -0700, Dmitry Torokhov wrote:
> > >
> > > Are you hibernating from text console or X? Can you try plugging in USB
> > > keyboard and see if you are getting input? What about ssh into the box?
> >
> > Forgot to answer a few of your questions. Plugging in a USB keyboard does
> > not help.
>
> OK, it looks like you do have input, what you do not have is X
> functioning.
>
> I am not sure why radeon reports lockup with that patch; serio uses
> system_long_wq to schedule its long-playing works and the only other
> user of system_long_wq seems to be sata, but then concurrency management
> should take care of them sharing the workqueue.
>
> Tejun, do you have any ideas here?
Not at all. Dang, I was feeling pretty sure that it was some missing
queue_work somewhere. So, input is working fine but X locks up
because of that change? That's just odd.
Andrew, just in case, can you please double check that you're
reverting only that single commit (not all the ones afterwards) and
the test results? If they're all okay, can you please trigger the
problem, wait a while, trigger sysrq-t and attach the kernel log?
Thank you.
--
tejun
^ permalink raw reply
* Re: [PATCH 1/3 v3] ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210/4212
From: Sylwester Nawrocki @ 2011-11-03 10:24 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'linux-samsung-soc', 'Russell King - ARM Linux',
'Sylwester Nawrocki', 'Kyungmin Park', linux-pm,
'linux-arm-kernel'
In-Reply-To: <013301cc99cd$8d5a6a00$a80f3e00$%kim@samsung.com>
Hi Kgene,
On 11/03/2011 03:09 AM, Kukjin Kim wrote:
> As I said, I don't think we should control/gate the clocks with regarding power domain.
As far as I know there is a plan to let the drivers override start/stop_device callbacks,
moreover the clock control can be disabled globally by not implementing start/stop_device
callbacks or per device by not adding clkdev entities to the device clock list at runtime
PM core. So IMHO, there is/going to be enough flexibility.
> It should be controlled by each regarding device driver and in addition, as I know,
> to handle block of clock is not recommended on EXYNOS4 now.
What do you mean by this ? I couldn't find such information in any documentation.
Shouldn't "clock gate block" registers be touched by boot loader and the kernel?
Our boot loaders disable all clocks, and if the global clock gate is not enabled
by the kernel there is no chance any multimedia device will work.
Should the global clock block gate be always enabled then ? I'm afraid it is not
optimal form power management POV.
--
Thanks,
Sylwester
^ permalink raw reply
* Re: [PATCH 3/3 v3] ARM: EXYNOS4: Delete the power domain code depend on samsung SoC
From: Kukjin Kim @ 2011-11-03 2:09 UTC (permalink / raw)
To: 'Chanwoo Choi'
Cc: 'Sylwester Nawrocki', 'linux-samsung-soc',
'Russell King - ARM Linux', 'Kyungmin Park',
linux-pm, 'linux-arm-kernel'
In-Reply-To: <4EA690F4.6040608@samsung.com>
Chanwoo Choi wrote:
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos4/Kconfig | 5 -
> arch/arm/mach-exynos4/Makefile | 1 -
> arch/arm/mach-exynos4/dev-pd.c | 139 -------------------------------
> arch/arm/plat-samsung/Kconfig | 8 --
> arch/arm/plat-samsung/Makefile | 4 -
> arch/arm/plat-samsung/include/plat/pd.h | 30 -------
> arch/arm/plat-samsung/pd.c | 95 ---------------------
> 7 files changed, 0 insertions(+), 282 deletions(-)
> delete mode 100644 arch/arm/mach-exynos4/dev-pd.c
> delete mode 100644 arch/arm/plat-samsung/include/plat/pd.h
> delete mode 100644 arch/arm/plat-samsung/pd.c
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index d042e53..3c16ab0 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -47,11 +47,6 @@ config EXYNOS4_SETUP_FIMD0
> help
> Common setup code for FIMD0.
>
> -config EXYNOS4_DEV_PD
> - bool
> - help
> - Compile in platform device definitions for Power Domain
> -
> config EXYNOS4_DEV_SYSMMU
> bool
> help
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index d73a4e7..2cad115 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -42,7 +42,6 @@ obj-$(CONFIG_MACH_SMDK4412) += mach-
> smdk4x12.o
>
> obj-y += dev-audio.o
> obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
> -obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
> obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
> obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
>
> diff --git a/arch/arm/mach-exynos4/dev-pd.c b/arch/arm/mach-exynos4/dev-pd.c
> deleted file mode 100644
> index 3273f25..0000000
> --- a/arch/arm/mach-exynos4/dev-pd.c
> +++ /dev/null
> @@ -1,139 +0,0 @@
> -/* linux/arch/arm/mach-exynos4/dev-pd.c
> - *
> - * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
> - * http://www.samsung.com
> - *
> - * EXYNOS4 - Power Domain support
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> -*/
> -
> -#include <linux/io.h>
> -#include <linux/kernel.h>
> -#include <linux/platform_device.h>
> -#include <linux/delay.h>
> -
> -#include <mach/regs-pmu.h>
> -
> -#include <plat/pd.h>
> -
> -static int exynos4_pd_enable(struct device *dev)
> -{
> - struct samsung_pd_info *pdata = dev->platform_data;
> - u32 timeout;
> -
> - __raw_writel(S5P_INT_LOCAL_PWR_EN, pdata->base);
> -
> - /* Wait max 1ms */
> - timeout = 10;
> - while ((__raw_readl(pdata->base + 0x4) & S5P_INT_LOCAL_PWR_EN)
> - != S5P_INT_LOCAL_PWR_EN) {
> - if (timeout == 0) {
> - printk(KERN_ERR "Power domain %s enable failed.\n",
> - dev_name(dev));
> - return -ETIMEDOUT;
> - }
> - timeout--;
> - udelay(100);
> - }
> -
> - return 0;
> -}
> -
> -static int exynos4_pd_disable(struct device *dev)
> -{
> - struct samsung_pd_info *pdata = dev->platform_data;
> - u32 timeout;
> -
> - __raw_writel(0, pdata->base);
> -
> - /* Wait max 1ms */
> - timeout = 10;
> - while (__raw_readl(pdata->base + 0x4) & S5P_INT_LOCAL_PWR_EN) {
> - if (timeout == 0) {
> - printk(KERN_ERR "Power domain %s disable failed.\n",
> - dev_name(dev));
> - return -ETIMEDOUT;
> - }
> - timeout--;
> - udelay(100);
> - }
> -
> - return 0;
> -}
> -
> -struct platform_device exynos4_device_pd[] = {
> - {
> - .name = "samsung-pd",
> - .id = 0,
> - .dev = {
> - .platform_data = &(struct samsung_pd_info) {
> - .enable = exynos4_pd_enable,
> - .disable = exynos4_pd_disable,
> - .base = S5P_PMU_MFC_CONF,
> - },
> - },
> - }, {
> - .name = "samsung-pd",
> - .id = 1,
> - .dev = {
> - .platform_data = &(struct samsung_pd_info) {
> - .enable = exynos4_pd_enable,
> - .disable = exynos4_pd_disable,
> - .base = S5P_PMU_G3D_CONF,
> - },
> - },
> - }, {
> - .name = "samsung-pd",
> - .id = 2,
> - .dev = {
> - .platform_data = &(struct samsung_pd_info) {
> - .enable = exynos4_pd_enable,
> - .disable = exynos4_pd_disable,
> - .base = S5P_PMU_LCD0_CONF,
> - },
> - },
> - }, {
> - .name = "samsung-pd",
> - .id = 3,
> - .dev = {
> - .platform_data = &(struct samsung_pd_info) {
> - .enable = exynos4_pd_enable,
> - .disable = exynos4_pd_disable,
> - .base = S5P_PMU_LCD1_CONF,
> - },
> - },
> - }, {
> - .name = "samsung-pd",
> - .id = 4,
> - .dev = {
> - .platform_data = &(struct samsung_pd_info) {
> - .enable = exynos4_pd_enable,
> - .disable = exynos4_pd_disable,
> - .base = S5P_PMU_TV_CONF,
> - },
> - },
> - }, {
> - .name = "samsung-pd",
> - .id = 5,
> - .dev = {
> - .platform_data = &(struct samsung_pd_info) {
> - .enable = exynos4_pd_enable,
> - .disable = exynos4_pd_disable,
> - .base = S5P_PMU_CAM_CONF,
> - },
> - },
> - }, {
> - .name = "samsung-pd",
> - .id = 6,
> - .dev = {
> - .platform_data = &(struct samsung_pd_info) {
> - .enable = exynos4_pd_enable,
> - .disable = exynos4_pd_disable,
> - .base = S5P_PMU_GPS_CONF,
> - },
> - },
> - },
> -};
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index 74714c1..f29c443 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -335,12 +335,4 @@ config SAMSUNG_WAKEMASK
> and above. This code allows a set of interrupt to wakeup-mask
> mappings. See <plat/wakeup-mask.h>
>
> -comment "Power Domain"
> -
> -config SAMSUNG_PD
> - bool "Samsung Power Domain"
> - depends on PM_RUNTIME
> - help
> - Say Y here if you want to control Power Domain by Runtime PM.
> -
> endif
> diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
> index a524fab..bd60e56 100644
> --- a/arch/arm/plat-samsung/Makefile
> +++ b/arch/arm/plat-samsung/Makefile
> @@ -48,10 +48,6 @@ obj-$(CONFIG_SAMSUNG_PM_CHECK) += pm-
> check.o
>
> obj-$(CONFIG_SAMSUNG_WAKEMASK) += wakeup-mask.o
>
> -# PD support
> -
> -obj-$(CONFIG_SAMSUNG_PD) += pd.o
> -
> # PWM support
>
> obj-$(CONFIG_HAVE_PWM) += pwm.o
> diff --git a/arch/arm/plat-samsung/include/plat/pd.h b/arch/arm/plat-
> samsung/include/plat/pd.h
> deleted file mode 100644
> index abb4bc3..0000000
> --- a/arch/arm/plat-samsung/include/plat/pd.h
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -/* linux/arch/arm/plat-samsung/include/plat/pd.h
> - *
> - * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
> - * http://www.samsung.com
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> -*/
> -
> -#ifndef __ASM_PLAT_SAMSUNG_PD_H
> -#define __ASM_PLAT_SAMSUNG_PD_H __FILE__
> -
> -struct samsung_pd_info {
> - int (*enable)(struct device *dev);
> - int (*disable)(struct device *dev);
> - void __iomem *base;
> -};
> -
> -enum exynos4_pd_block {
> - PD_MFC,
> - PD_G3D,
> - PD_LCD0,
> - PD_LCD1,
> - PD_TV,
> - PD_CAM,
> - PD_GPS
> -};
> -
> -#endif /* __ASM_PLAT_SAMSUNG_PD_H */
> diff --git a/arch/arm/plat-samsung/pd.c b/arch/arm/plat-samsung/pd.c
> deleted file mode 100644
> index efe1d56..0000000
> --- a/arch/arm/plat-samsung/pd.c
> +++ /dev/null
> @@ -1,95 +0,0 @@
> -/* linux/arch/arm/plat-samsung/pd.c
> - *
> - * Copyright (c) 2010 Samsung Electronics Co., Ltd.
> - * http://www.samsung.com
> - *
> - * Samsung Power domain support
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> -*/
> -
> -#include <linux/init.h>
> -#include <linux/module.h>
> -#include <linux/platform_device.h>
> -#include <linux/err.h>
> -#include <linux/pm_runtime.h>
> -
> -#include <plat/pd.h>
> -
> -static int samsung_pd_probe(struct platform_device *pdev)
> -{
> - struct samsung_pd_info *pdata = pdev->dev.platform_data;
> - struct device *dev = &pdev->dev;
> -
> - if (!pdata) {
> - dev_err(dev, "no device data specified\n");
> - return -ENOENT;
> - }
> -
> - pm_runtime_set_active(dev);
> - pm_runtime_enable(dev);
> -
> - dev_info(dev, "power domain registered\n");
> - return 0;
> -}
> -
> -static int __devexit samsung_pd_remove(struct platform_device *pdev)
> -{
> - struct device *dev = &pdev->dev;
> -
> - pm_runtime_disable(dev);
> - return 0;
> -}
> -
> -static int samsung_pd_runtime_suspend(struct device *dev)
> -{
> - struct samsung_pd_info *pdata = dev->platform_data;
> - int ret = 0;
> -
> - if (pdata->disable)
> - ret = pdata->disable(dev);
> -
> - dev_dbg(dev, "suspended\n");
> - return ret;
> -}
> -
> -static int samsung_pd_runtime_resume(struct device *dev)
> -{
> - struct samsung_pd_info *pdata = dev->platform_data;
> - int ret = 0;
> -
> - if (pdata->enable)
> - ret = pdata->enable(dev);
> -
> - dev_dbg(dev, "resumed\n");
> - return ret;
> -}
> -
> -static const struct dev_pm_ops samsung_pd_pm_ops = {
> - .runtime_suspend = samsung_pd_runtime_suspend,
> - .runtime_resume = samsung_pd_runtime_resume,
> -};
> -
> -static struct platform_driver samsung_pd_driver = {
> - .driver = {
> - .name = "samsung-pd",
> - .owner = THIS_MODULE,
> - .pm = &samsung_pd_pm_ops,
> - },
> - .probe = samsung_pd_probe,
> - .remove = __devexit_p(samsung_pd_remove),
> -};
> -
> -static int __init samsung_pd_init(void)
> -{
> - int ret;
> -
> - ret = platform_driver_register(&samsung_pd_driver);
> - if (ret)
> - printk(KERN_ERR "%s: failed to add PD driver\n", __func__);
> -
> - return ret;
> -}
> -arch_initcall(samsung_pd_init);
> --
> 1.7.0.4
Well, I can't agree on this because you removed power domain codes which can be used for all of Samsung stuff for only EXYNOS4's generic power domain even though it was used for only EXYNOS4.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [PATCH 1/3 v3] ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210/4212
From: Kukjin Kim @ 2011-11-03 2:09 UTC (permalink / raw)
To: 'Chanwoo Choi'
Cc: 'Sylwester Nawrocki', 'linux-samsung-soc',
'Russell King - ARM Linux', 'Kyungmin Park',
linux-pm, 'linux-arm-kernel'
In-Reply-To: <4EA690EF.4000703@samsung.com>
Chanwoo Choi wrote:
>
> This patch support the generic power domains to control power domain
> of EXYNOS4.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos4/Kconfig | 2 +
> arch/arm/mach-exynos4/Makefile | 1 +
> arch/arm/mach-exynos4/include/mach/pm-exynos4.h | 50 +++++
> arch/arm/mach-exynos4/include/mach/regs-clock.h | 9 +
> arch/arm/mach-exynos4/include/mach/regs-pmu.h | 2 +
> arch/arm/mach-exynos4/pm-exynos4.c | 237
> +++++++++++++++++++++++
> 6 files changed, 301 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/include/mach/pm-exynos4.h
> create mode 100644 arch/arm/mach-exynos4/pm-exynos4.c
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 4924838..d042e53 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -14,6 +14,7 @@ config CPU_EXYNOS4210
> select SAMSUNG_DMADEV
> select S5P_PM if PM
> select S5P_SLEEP if PM
> + select PM_GENERIC_DOMAINS if PM
> help
> Enable EXYNOS4210 CPU support
>
> @@ -21,6 +22,7 @@ config SOC_EXYNOS4212
> bool
> select S5P_PM if PM
> select S5P_SLEEP if PM
> + select PM_GENERIC_DOMAINS if PM
> help
> Enable EXYNOS4212 SoC support
>
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index 2bb18f4..d73a4e7 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -14,6 +14,7 @@ obj- :=
>
> obj-$(CONFIG_ARCH_EXYNOS4) += cpu.o init.o clock.o irq-combiner.o
> obj-$(CONFIG_ARCH_EXYNOS4) += setup-i2c0.o irq-eint.o dma.o pmu.o
> +obj-$(CONFIG_ARCH_EXYNOS4) += pm-exynos4.o
> obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
> obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
> obj-$(CONFIG_PM) += pm.o
> diff --git a/arch/arm/mach-exynos4/include/mach/pm-exynos4.h b/arch/arm/mach-
> exynos4/include/mach/pm-exynos4.h
> new file mode 100644
> index 0000000..31f6b75
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/include/mach/pm-exynos4.h
> @@ -0,0 +1,50 @@
> +/* linux/arch/arm/mach-exynos4/include/mach/pm-exynos4.h
> + *
> + * EXYNOS4 series Power management support
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef PM_EXYNOS4_H
> +#define PM_EXYNOS4_H
> +
> +#include <linux/pm_domain.h>
> +
> +#ifdef CONFIG_PM
> +struct exynos4_pm_domain {
> + struct generic_pm_domain genpd;
> + const char *name;
> + void __iomem *base;
> + u32 clkgate_mask;
> +};
> +
> +extern int exynos4_add_device_to_domain(struct exynos4_pm_domain
> *exynos4_pd,
> + struct platform_device *pdev);
> +extern void exynos4210_init_pm_domains(void);
> +extern void exynos4x12_init_pm_domains(void);
> +
> +/* Common power domain for EXYNOS4 series */
> +extern struct exynos4_pm_domain exynos4_pd_mfc;
> +extern struct exynos4_pm_domain exynos4_pd_g3d;
> +extern struct exynos4_pm_domain exynos4_pd_lcd0;
> +extern struct exynos4_pm_domain exynos4_pd_tv;
> +extern struct exynos4_pm_domain exynos4_pd_cam;
> +extern struct exynos4_pm_domain exynos4_pd_gps;
> +
> +/* Only for EXYNOS4210 */
> +extern struct exynos4_pm_domain exynos4_pd_lcd1;
> +
> +/* Only for EXYNOS4x12 */
> +extern struct exynos4_pm_domain exynos4_pd_isp;
> +
> +#else
> +#define exynos4_add_device_to_domain(exynos4_pd, pdev) { }
> +#define exynos4210_init_pm_domains() { }
> +#define exynos4x12_init_pm_domains() { }
> +#endif /* CONFIG_PM */
> +#endif /* PM_EXYNOS4_H */
> diff --git a/arch/arm/mach-exynos4/include/mach/regs-clock.h b/arch/arm/mach-
> exynos4/include/mach/regs-clock.h
> index 6c37ebe..c519ade 100644
> --- a/arch/arm/mach-exynos4/include/mach/regs-clock.h
> +++ b/arch/arm/mach-exynos4/include/mach/regs-clock.h
> @@ -194,6 +194,13 @@
> #define S5P_CLKDIV_BUS_GPLR_SHIFT (4)
> #define S5P_CLKDIV_BUS_GPLR_MASK (0x7 <<
> S5P_CLKDIV_BUS_GPLR_SHIFT)
>
> +#define S5P_CLKGATE_BLOCK_CAM (1 << 0)
> +#define S5P_CLKGATE_BLOCK_TV (1 << 1)
> +#define S5P_CLKGATE_BLOCK_MFC (1 << 2)
> +#define S5P_CLKGATE_BLOCK_G3D (1 << 3)
> +#define S5P_CLKGATE_BLOCK_LCD0 (1 << 4)
> +#define S5P_CLKGATE_BLOCK_GPS (1 << 7)
> +
> /* Only for EXYNOS4210 */
>
> #define S5P_CLKSRC_LCD1 S5P_CLKREG(0x0C238)
> @@ -201,6 +208,8 @@
> #define S5P_CLKDIV_LCD1 S5P_CLKREG(0x0C538)
> #define S5P_CLKGATE_IP_LCD1 S5P_CLKREG(0x0C938)
>
> +#define S5P_CLKGATE_BLOCK_LCD1 (1 << 5)
> +
> /* Compatibility defines and inclusion */
>
> #include <mach/regs-pmu.h>
> diff --git a/arch/arm/mach-exynos4/include/mach/regs-pmu.h b/arch/arm/mach-
> exynos4/include/mach/regs-pmu.h
> index 4fff8e9..da397d5 100644
> --- a/arch/arm/mach-exynos4/include/mach/regs-pmu.h
> +++ b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
> @@ -217,4 +217,6 @@
> #define S5P_SECSS_MEM_OPTION
> S5P_PMUREG(0x2EC8)
> #define S5P_ROTATOR_MEM_OPTION
> S5P_PMUREG(0x2F48)
>
> +#define S5P_PMU_ISP_CONF S5P_PMUREG(0x3CA0)
> +
> #endif /* __ASM_ARCH_REGS_PMU_H */
> diff --git a/arch/arm/mach-exynos4/pm-exynos4.c b/arch/arm/mach-exynos4/pm-
> exynos4.c
> new file mode 100644
> index 0000000..c35952b
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/pm-exynos4.c
> @@ -0,0 +1,237 @@
> +/* linux/arch/arm/mach-exynos4/pm-exynos4.c
> + *
> + * EXYNOS4 series Power management support
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/io.h>
> +
> +#include <mach/regs-clock.h>
> +#include <mach/pm-exynos4.h>
> +
> +#ifdef CONFIG_PM
> +/*
> + * Define function to support generic power domain
> + */
> +
> +static DEFINE_SPINLOCK(clkgate_block_lock);
> +
> +static struct exynos4_pm_domain *to_exynos4_pd(struct generic_pm_domain
> *pd)
> +{
> + return container_of(pd, struct exynos4_pm_domain, genpd);
> +}
> +
> +static int __exynos4_pd_power_down(struct generic_pm_domain *genpd)
> +{
> + struct exynos4_pm_domain *exynos4_pd = to_exynos4_pd(genpd);
> + u32 timeout;
> +
> + /* Disable the power of power-domain */
> + __raw_writel(0, exynos4_pd->base);
> +
> + /* Wait max 1ms */
> + timeout = 10;
> + while (__raw_readl(exynos4_pd->base + 0x4) &
> S5P_INT_LOCAL_PWR_EN) {
> + if (timeout == 0) {
> + pr_err("Power domain %s disable failed.\n",
> exynos4_pd->name);
> + return -ETIMEDOUT;
> + }
> + timeout--;
> + usleep_range(90, 110);
> + }
> +
> + /* Configure the clock-gating control register for block to turn off */
> + if (exynos4_pd->clkgate_mask) {
> + unsigned long flags;
> + u32 reg;
> +
> + spin_lock_irqsave(&clkgate_block_lock, flags);
> + reg = __raw_readl(S5P_CLKGATE_BLOCK);
> + reg &= ~exynos4_pd->clkgate_mask;
> + __raw_writel(reg, S5P_CLKGATE_BLOCK);
> + spin_unlock_irqrestore(&clkgate_block_lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static int __exynos4_pd_power_up(struct generic_pm_domain *genpd)
> +{
> + struct exynos4_pm_domain *exynos4_pd = to_exynos4_pd(genpd);
> + u32 timeout;
> +
> + /* Enable power domain */
> + __raw_writel(S5P_INT_LOCAL_PWR_EN, exynos4_pd->base);
> +
> + /* Wait max 1ms */
> + timeout = 10;
> + while ((__raw_readl(exynos4_pd->base + 0x4) &
> S5P_INT_LOCAL_PWR_EN)
> + != S5P_INT_LOCAL_PWR_EN) {
> + if (timeout == 0) {
> + pr_err("Power domain %s enable failed.\n",
> + exynos4_pd->name);
> + return -ETIMEDOUT;
> + }
> + timeout--;
> + usleep_range(90, 110);
> + }
> +
> + /* Configure the clock-gating control register for block to turn on */
> + if (exynos4_pd->clkgate_mask) {
> + unsigned long flags;
> + u32 reg;
> +
> + spin_lock_irqsave(&clkgate_block_lock, flags);
> + reg = __raw_readl(S5P_CLKGATE_BLOCK);
> + reg |= exynos4_pd->clkgate_mask;
> + __raw_writel(reg, S5P_CLKGATE_BLOCK);
> + spin_unlock_irqrestore(&clkgate_block_lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static bool __exynos4_pd_active_wakeup(struct device *dev)
> +{
> + return true;
> +}
> +
> +static void __exynos4_init_pm_domain(struct exynos4_pm_domain *exynos4_pd)
> +{
> + struct generic_pm_domain *genpd;
> +
> + if (!exynos4_pd) {
> + pr_err("Failed to initialize Power domain(%s)\n", exynos4_pd-
> >name);
> + return;
> + }
> +
> + genpd = &exynos4_pd->genpd;
> +
> + pm_genpd_init(genpd, NULL, false);
> + genpd->active_wakeup = __exynos4_pd_active_wakeup;
> + genpd->power_off = __exynos4_pd_power_down;
> + genpd->power_on = __exynos4_pd_power_up;
> +}
> +
> +/*
> + * Define power domain of EXYNOS4 series
> + * - EXYNOS4210
> + * - EXYNOS4212
> + */
> +/* Common power domain on EXYNOS4 series */
> +struct exynos4_pm_domain exynos4_pd_mfc = {
> + .name = "PD_MFC",
> + .base = S5P_PMU_MFC_CONF,
> + .clkgate_mask = S5P_CLKGATE_BLOCK_MFC,
> +};
> +
> +struct exynos4_pm_domain exynos4_pd_g3d = {
> + .name = "PD_G3D",
> + .base = S5P_PMU_G3D_CONF,
> + .clkgate_mask = S5P_CLKGATE_BLOCK_G3D,
> +};
> +
> +struct exynos4_pm_domain exynos4_pd_lcd0 = {
> + .name = "PD_LCD0",
> + .base = S5P_PMU_LCD0_CONF,
> + .clkgate_mask = S5P_CLKGATE_BLOCK_LCD0,
> +};
> +
> +struct exynos4_pm_domain exynos4_pd_tv = {
> + .name = "PD_TV",
> + .base = S5P_PMU_TV_CONF,
> + .clkgate_mask = S5P_CLKGATE_BLOCK_TV,
> +};
> +
> +struct exynos4_pm_domain exynos4_pd_cam = {
> + .name = "PD_CAM",
> + .base = S5P_PMU_CAM_CONF,
> + .clkgate_mask = S5P_CLKGATE_BLOCK_CAM,
> +};
> +
> +struct exynos4_pm_domain exynos4_pd_gps = {
> + .name = "PD_GPS",
> + .base = S5P_PMU_GPS_CONF,
> + .clkgate_mask = S5P_CLKGATE_BLOCK_GPS,
> +};
> +
> +/* Only for EXYNOS4210 */
> +struct exynos4_pm_domain exynos4_pd_lcd1 = {
> + .name = "PD_LCD1",
> + .base = S5P_PMU_LCD1_CONF,
> + .clkgate_mask = S5P_CLKGATE_BLOCK_LCD1,
> +};
> +
> +/* Only for EXYNOS4212 */
> +struct exynos4_pm_domain exynos4_pd_isp = {
> + .name = "PD_ISP",
> + .base = S5P_PMU_ISP_CONF,
> +};
> +
> +/*
> + * Define function which initalize power domain and add device to it
> + */
> +int exynos4_add_device_to_domain(struct exynos4_pm_domain *exynos4_pd,
> + struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + if (!exynos4_pd || !pdev)
> + return -EINVAL;
> +
> + ret = pm_genpd_add_device(&exynos4_pd->genpd, dev);
> + if (ret < 0) {
> + pr_err("Failed to add %s device to power domain(%s)\n",
> + dev_name(&pdev->dev), exynos4_pd->name);
> + return ret;
> + }
> +
> + pr_info("Add %s device to power domain(%s)\n",
> + dev_name(&pdev->dev), exynos4_pd->name);
> + return 0;
> +}
> +
> +void exynos4_init_pm_domains(void)
> +{
> + __exynos4_init_pm_domain(&exynos4_pd_mfc);
> + __exynos4_init_pm_domain(&exynos4_pd_g3d);
> + __exynos4_init_pm_domain(&exynos4_pd_lcd0);
> + __exynos4_init_pm_domain(&exynos4_pd_tv);
> + __exynos4_init_pm_domain(&exynos4_pd_cam);
> + __exynos4_init_pm_domain(&exynos4_pd_gps);
> +
> +}
> +
> +/* Initialize EXYNOS4210 power domain */
> +void exynos4210_init_pm_domains(void)
> +{
> + exynos4_init_pm_domains();
> +
> + __exynos4_init_pm_domain(&exynos4_pd_lcd1);
> +
> + /* Enabled the power domain of LCD0 */
> + __exynos4_pd_power_up(&exynos4_pd_lcd0.genpd);
> +}
> +
> +/* Initialize EXYNOS4x12 power domain */
> +void exynos4x12_init_pm_domains(void)
> +{
> + exynos4_init_pm_domains();
> +
> + __exynos4_init_pm_domain(&exynos4_pd_isp);
> +
> + /* Enabled the power domain of LCD0 */
> + __exynos4_pd_power_up(&exynos4_pd_lcd0.genpd);
> +}
> +#endif /* CONFIG_PM */
> --
> 1.7.0.4
As I said, I don't think we should control/gate the clocks with regarding power domain. It should be controlled by each regarding device driver and in addition, as I know, to handle block of clock is not recommended on EXYNOS4 now.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [PATCH 4/6 v2] PM: Limit race conditions between runtime PM and system sleep (v2)
From: Greg KH @ 2011-11-03 1:31 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, linux-scsi, LKML, Jesse Barnes, Ulf Hansson,
Tejun Heo, Linux PM mailing list, stable
In-Reply-To: <201111030128.52823.rjw@sisk.pl>
On Thu, Nov 03, 2011 at 01:28:52AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 02, 2011, Greg KH wrote:
> > On Wed, Nov 02, 2011 at 10:00:39PM +0100, Linus Walleij wrote:
> > > On Wed, Nov 2, 2011 at 9:11 PM, Greg KH <greg@kroah.com> wrote:
> > > > On Wed, Nov 02, 2011 at 09:06:02PM +0100, Linus Walleij wrote:
> > > >> On Wed, Nov 2, 2011 at 8:14 PM, Greg KH <greg@kroah.com> wrote:
> > > >> > So, what specific git commits do you want to see in the 3.0-stable
> > > >> > tree, and in what order should they be applied in?
> > > >>
> > > >> So to my untrained eye it looks like it should be applied like this (top to
> > > >> bottom) using the reverse commit order from the mainline kernel:
> > > >>
> > > >> e529192 PM: Introduce generic "noirq" callback routines for subsystems (v2)
> > > >> 455716e PM / Runtime: Update documentation of interactions with system sleep
> > > >> 1e2ef05 PM: Limit race conditions between runtime PM and system sleep (v2)
> > > >> f3393b6 PM / Runtime: Add new helper function: pm_runtime_status_suspended()
> > > >>
> > > >> So (2) documents the problem, (3) fixes it, whereas (1) and (4) makes
> > > >> it possible
> > > >> to write proper _noirq() code that does not race, IIRC.
> > > >
> > > > But, after this, it's just adding new infrastructure that drivers will
> > > > then be able to use. As I'm not adding new drivers to 3.0, there will
> > > > not be any users of this code, so why add it in the first place? It
> > > > doesn't look like this follows the rules of the stable kernel tree at
> > > > all, does it?
> > >
> > > We'll have to get some feedback from Rafael, but the way I percieved
> > > it, the patch (2) fixes a very real race, then fixing that makes it
> > > necessary for drivers using runtime_pm to do things differently to
> > > be on the safe side. But none were really fixed when first merging
> > > it.
> > >
> > > So on second thought you probably only want patch (2)
> > > "PM: Limit race conditions between runtime PM and system sleep (v2)"
> > > for stable.
> >
> > Ok, Rafael, any objection to me applying just this one?
>
> Well, I'd prefer not to unless there are reports confirming user problems
> being fixed specifically by this patch. It changes the PM core's behavior
> quite significantly and I'm a little afraid of possible regressions that may
> result from it.
Ok, good reason to not apply it, consider it dropped :)
greg k-h
^ permalink raw reply
* Re: [PATCH 4/6 v2] PM: Limit race conditions between runtime PM and system sleep (v2)
From: Rafael J. Wysocki @ 2011-11-03 0:28 UTC (permalink / raw)
To: Greg KH
Cc: Kevin Hilman, linux-scsi, LKML, Jesse Barnes, Ulf Hansson,
Tejun Heo, Linux PM mailing list, stable
In-Reply-To: <20111102211708.GA19025@kroah.com>
On Wednesday, November 02, 2011, Greg KH wrote:
> On Wed, Nov 02, 2011 at 10:00:39PM +0100, Linus Walleij wrote:
> > On Wed, Nov 2, 2011 at 9:11 PM, Greg KH <greg@kroah.com> wrote:
> > > On Wed, Nov 02, 2011 at 09:06:02PM +0100, Linus Walleij wrote:
> > >> On Wed, Nov 2, 2011 at 8:14 PM, Greg KH <greg@kroah.com> wrote:
> > >> > So, what specific git commits do you want to see in the 3.0-stable
> > >> > tree, and in what order should they be applied in?
> > >>
> > >> So to my untrained eye it looks like it should be applied like this (top to
> > >> bottom) using the reverse commit order from the mainline kernel:
> > >>
> > >> e529192 PM: Introduce generic "noirq" callback routines for subsystems (v2)
> > >> 455716e PM / Runtime: Update documentation of interactions with system sleep
> > >> 1e2ef05 PM: Limit race conditions between runtime PM and system sleep (v2)
> > >> f3393b6 PM / Runtime: Add new helper function: pm_runtime_status_suspended()
> > >>
> > >> So (2) documents the problem, (3) fixes it, whereas (1) and (4) makes
> > >> it possible
> > >> to write proper _noirq() code that does not race, IIRC.
> > >
> > > But, after this, it's just adding new infrastructure that drivers will
> > > then be able to use. As I'm not adding new drivers to 3.0, there will
> > > not be any users of this code, so why add it in the first place? It
> > > doesn't look like this follows the rules of the stable kernel tree at
> > > all, does it?
> >
> > We'll have to get some feedback from Rafael, but the way I percieved
> > it, the patch (2) fixes a very real race, then fixing that makes it
> > necessary for drivers using runtime_pm to do things differently to
> > be on the safe side. But none were really fixed when first merging
> > it.
> >
> > So on second thought you probably only want patch (2)
> > "PM: Limit race conditions between runtime PM and system sleep (v2)"
> > for stable.
>
> Ok, Rafael, any objection to me applying just this one?
Well, I'd prefer not to unless there are reports confirming user problems
being fixed specifically by this patch. It changes the PM core's behavior
quite significantly and I'm a little afraid of possible regressions that may
result from it.
Thanks,
Rafael
^ permalink raw reply
* Re: PM / OPP: Fix build when CONFIG_PM_OPP is not set
From: Rafael J. Wysocki @ 2011-11-03 0:21 UTC (permalink / raw)
To: Tony Lindgren
Cc: Kevin Hilman, linux-kernel, Kyungmin Park, MyungJoo Ham, linux-pm,
linux-omap
In-Reply-To: <20111102170055.GI31337@atomide.com>
On Wednesday, November 02, 2011, Tony Lindgren wrote:
> Commit 03ca370fbf7b76d6d002380dbdc2cdc2319f9c80 (PM / OPP: Add
> OPP availability change notifier) does not compile if CONFIG_PM_OPP
> is not set:
>
> arch/arm/plat-omap/omap-pm-noop.o: In function `opp_get_notifier':
> include/linux/opp.h:103: multiple definition of `opp_get_notifier'
> include/linux/opp.h:103: first defined here
>
> Also fix incorrect comment.
>
> Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Mike Turquette <mturquette@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Applied to linux-pm/linux-next.
Thanks,
Rafael
> ---
>
> I'm seeing this with omap1_defconfig at least.
>
> --- a/include/linux/opp.h
> +++ b/include/linux/opp.h
> @@ -97,11 +97,11 @@ static inline int opp_disable(struct device *dev, unsigned long freq)
> return 0;
> }
>
> -struct srcu_notifier_head *opp_get_notifier(struct device *dev)
> +static inline struct srcu_notifier_head *opp_get_notifier(struct device *dev)
> {
> return ERR_PTR(-EINVAL);
> }
> -#endif /* CONFIG_PM */
> +#endif /* CONFIG_PM_OPP */
>
> #if defined(CONFIG_CPU_FREQ) && defined(CONFIG_PM_OPP)
> int opp_init_cpufreq_table(struct device *dev,
>
>
^ permalink raw reply
* Re: [PATCH] CPU hotplug, PM: Remove unused symbol 'suspend_cpu_hotplug'
From: Rafael J. Wysocki @ 2011-11-03 0:19 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: mingo, amwang, linux-pm, gregkh, linux-kernel, akpm, linux-pm,
a.p.zijlstra
In-Reply-To: <20111028134737.18461.60249.stgit@srivatsabhat.in.ibm.com>
On Friday, October 28, 2011, Srivatsa S. Bhat wrote:
>
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Applied to linux-pm/linux-next.
Thanks,
Rafael
> ---
>
> include/linux/cpu.h | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index b1a635a..6cb60fd 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -196,13 +196,9 @@ static inline void cpu_hotplug_driver_unlock(void)
> #endif /* CONFIG_HOTPLUG_CPU */
>
> #ifdef CONFIG_PM_SLEEP_SMP
> -extern int suspend_cpu_hotplug;
> -
> extern int disable_nonboot_cpus(void);
> extern void enable_nonboot_cpus(void);
> #else /* !CONFIG_PM_SLEEP_SMP */
> -#define suspend_cpu_hotplug 0
> -
> static inline int disable_nonboot_cpus(void) { return 0; }
> static inline void enable_nonboot_cpus(void) {}
> #endif /* !CONFIG_PM_SLEEP_SMP */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH 4/6 v2] PM: Limit race conditions between runtime PM and system sleep (v2)
From: Greg KH @ 2011-11-02 21:17 UTC (permalink / raw)
To: Linus Walleij
Cc: Kevin Hilman, linux-scsi, LKML, Jesse Barnes, Ulf Hansson,
Tejun Heo, Linux PM mailing list, stable
In-Reply-To: <CACRpkdafpsgUi-0K5krr2_Hp+8GzCG8ZPu-HVNOK0_7uwURxdg@mail.gmail.com>
On Wed, Nov 02, 2011 at 10:00:39PM +0100, Linus Walleij wrote:
> On Wed, Nov 2, 2011 at 9:11 PM, Greg KH <greg@kroah.com> wrote:
> > On Wed, Nov 02, 2011 at 09:06:02PM +0100, Linus Walleij wrote:
> >> On Wed, Nov 2, 2011 at 8:14 PM, Greg KH <greg@kroah.com> wrote:
> >> > So, what specific git commits do you want to see in the 3.0-stable
> >> > tree, and in what order should they be applied in?
> >>
> >> So to my untrained eye it looks like it should be applied like this (top to
> >> bottom) using the reverse commit order from the mainline kernel:
> >>
> >> e529192 PM: Introduce generic "noirq" callback routines for subsystems (v2)
> >> 455716e PM / Runtime: Update documentation of interactions with system sleep
> >> 1e2ef05 PM: Limit race conditions between runtime PM and system sleep (v2)
> >> f3393b6 PM / Runtime: Add new helper function: pm_runtime_status_suspended()
> >>
> >> So (2) documents the problem, (3) fixes it, whereas (1) and (4) makes
> >> it possible
> >> to write proper _noirq() code that does not race, IIRC.
> >
> > But, after this, it's just adding new infrastructure that drivers will
> > then be able to use. As I'm not adding new drivers to 3.0, there will
> > not be any users of this code, so why add it in the first place? It
> > doesn't look like this follows the rules of the stable kernel tree at
> > all, does it?
>
> We'll have to get some feedback from Rafael, but the way I percieved
> it, the patch (2) fixes a very real race, then fixing that makes it
> necessary for drivers using runtime_pm to do things differently to
> be on the safe side. But none were really fixed when first merging
> it.
>
> So on second thought you probably only want patch (2)
> "PM: Limit race conditions between runtime PM and system sleep (v2)"
> for stable.
Ok, Rafael, any objection to me applying just this one?
Linus, have you tested the 3.0 kernel with just this patch applied? If
not, please do so and let me know. I'll wait for that before doing
anything.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 4/6 v2] PM: Limit race conditions between runtime PM and system sleep (v2)
From: Linus Walleij @ 2011-11-02 21:00 UTC (permalink / raw)
To: Greg KH
Cc: Kevin Hilman, linux-scsi, LKML, Jesse Barnes, Ulf Hansson,
Tejun Heo, Linux PM mailing list, stable
In-Reply-To: <20111102201101.GA5581@kroah.com>
On Wed, Nov 2, 2011 at 9:11 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Nov 02, 2011 at 09:06:02PM +0100, Linus Walleij wrote:
>> On Wed, Nov 2, 2011 at 8:14 PM, Greg KH <greg@kroah.com> wrote:
>> > So, what specific git commits do you want to see in the 3.0-stable
>> > tree, and in what order should they be applied in?
>>
>> So to my untrained eye it looks like it should be applied like this (top to
>> bottom) using the reverse commit order from the mainline kernel:
>>
>> e529192 PM: Introduce generic "noirq" callback routines for subsystems (v2)
>> 455716e PM / Runtime: Update documentation of interactions with system sleep
>> 1e2ef05 PM: Limit race conditions between runtime PM and system sleep (v2)
>> f3393b6 PM / Runtime: Add new helper function: pm_runtime_status_suspended()
>>
>> So (2) documents the problem, (3) fixes it, whereas (1) and (4) makes
>> it possible
>> to write proper _noirq() code that does not race, IIRC.
>
> But, after this, it's just adding new infrastructure that drivers will
> then be able to use. As I'm not adding new drivers to 3.0, there will
> not be any users of this code, so why add it in the first place? It
> doesn't look like this follows the rules of the stable kernel tree at
> all, does it?
We'll have to get some feedback from Rafael, but the way I percieved
it, the patch (2) fixes a very real race, then fixing that makes it
necessary for drivers using runtime_pm to do things differently to
be on the safe side. But none were really fixed when first merging
it.
So on second thought you probably only want patch (2)
"PM: Limit race conditions between runtime PM and system sleep (v2)"
for stable.
Yours,
Linus Walleij
^ permalink raw reply
* Re: Resume problem, reboot instead of resume after suspend on Zepto Nox A14
From: Damien Thébault @ 2011-11-02 20:47 UTC (permalink / raw)
To: MyungJoo Ham; +Cc: linux-pm
In-Reply-To: <CAJ0PZbT6_64Sg6NX+-Kshdn0T-1zynyUVkZ-hRCYtz6Fv_v4CA@mail.gmail.com>
On Wed, Nov 2, 2011 at 10:39, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
> [...]
> When core is used for pm_test, the platform_ops's enter() is not
> called. Thus, you are not actually testing the real suspend-to-RAM,
> you are testing everything suspend-related materials except for the
> real suspend-resume mechanism for the CPU.
>
> I'm not familiar with x86's ACPI; however, this looks like a
> resume-related problem.
> Probably, at the BIOS (or any other pre-BIOS stage?), the CPU cannot
> read the "the system has been suspended-to-RAM" message?
> or the resume routine of kernel is failing and the system resets or
> jumps to BIOS?
> , which are some issues we've experienced with ARM devices and its bootloaders.
>
> You'll probably need to examine the ACPI's suspend-to-RAM related bits
> or data structure at the platform_ops's enter() callback. And see if
> anything is corrupted or mis-configured.
I made some progress: with "nolapic" I'm able to get back to my
desktop, however if I make any fs access (like running an executable),
the system just locks. At least it doesn't reboot so it's an
improvement. I'll try so investigate further.
--
Damien Thebault
^ permalink raw reply
* Re: [PATCH 4/6 v2] PM: Limit race conditions between runtime PM and system sleep (v2)
From: Greg KH @ 2011-11-02 20:11 UTC (permalink / raw)
To: Linus Walleij
Cc: Kevin Hilman, linux-scsi, LKML, Jesse Barnes, Ulf Hansson,
Tejun Heo, Linux PM mailing list, stable
In-Reply-To: <CACRpkdY8zAw_pdwn2yUEJPdfYPS+VCcLrpucZzhCyNsVPYehdg@mail.gmail.com>
On Wed, Nov 02, 2011 at 09:06:02PM +0100, Linus Walleij wrote:
> On Wed, Nov 2, 2011 at 8:14 PM, Greg KH <greg@kroah.com> wrote:
>
> >> We have also backported:
> >> PM: Introduce generic "noirq" callback routines for subsystems (v2)
> >> PM / Runtime: Update documentation of interactions with system sleep
> >> PM / Runtime: Add new helper function: pm_runtime_status_suspended()
> >>
> >> And now it seems to be sufficient to get this thing going.
> >
> > So, what specific git commits do you want to see in the 3.0-stable
> > tree, and in what order should they be applied in?
>
> So to my untrained eye it looks like it should be applied like this (top to
> bottom) using the reverse commit order from the mainline kernel:
>
> e529192 PM: Introduce generic "noirq" callback routines for subsystems (v2)
> 455716e PM / Runtime: Update documentation of interactions with system sleep
> 1e2ef05 PM: Limit race conditions between runtime PM and system sleep (v2)
> f3393b6 PM / Runtime: Add new helper function: pm_runtime_status_suspended()
>
> So (2) documents the problem, (3) fixes it, whereas (1) and (4) makes
> it possible
> to write proper _noirq() code that does not race, IIRC.
But, after this, it's just adding new infrastructure that drivers will
then be able to use. As I'm not adding new drivers to 3.0, there will
not be any users of this code, so why add it in the first place? It
doesn't look like this follows the rules of the stable kernel tree at
all, does it?
confused,
greg k-h
^ permalink raw reply
* Re: [PATCH 4/6 v2] PM: Limit race conditions between runtime PM and system sleep (v2)
From: Linus Walleij @ 2011-11-02 20:06 UTC (permalink / raw)
To: Greg KH
Cc: Kevin Hilman, linux-scsi, LKML, Jesse Barnes, Ulf Hansson,
Tejun Heo, Linux PM mailing list, stable
In-Reply-To: <20111102191432.GC29355@kroah.com>
On Wed, Nov 2, 2011 at 8:14 PM, Greg KH <greg@kroah.com> wrote:
>> We have also backported:
>> PM: Introduce generic "noirq" callback routines for subsystems (v2)
>> PM / Runtime: Update documentation of interactions with system sleep
>> PM / Runtime: Add new helper function: pm_runtime_status_suspended()
>>
>> And now it seems to be sufficient to get this thing going.
>
> So, what specific git commits do you want to see in the 3.0-stable
> tree, and in what order should they be applied in?
So to my untrained eye it looks like it should be applied like this (top to
bottom) using the reverse commit order from the mainline kernel:
e529192 PM: Introduce generic "noirq" callback routines for subsystems (v2)
455716e PM / Runtime: Update documentation of interactions with system sleep
1e2ef05 PM: Limit race conditions between runtime PM and system sleep (v2)
f3393b6 PM / Runtime: Add new helper function: pm_runtime_status_suspended()
So (2) documents the problem, (3) fixes it, whereas (1) and (4) makes
it possible
to write proper _noirq() code that does not race, IIRC.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 4/6 v2] PM: Limit race conditions between runtime PM and system sleep (v2)
From: Greg KH @ 2011-11-02 19:14 UTC (permalink / raw)
To: Linus Walleij
Cc: Kevin Hilman, linux-scsi, LKML, Jesse Barnes, Tejun Heo,
Linux PM mailing list, stable
In-Reply-To: <CAKnu2Mru4c-2LBCZ_k3ZA+v47u0+um8igYU7EWt8=qOTVgcUjA@mail.gmail.com>
On Thu, Oct 27, 2011 at 03:54:20PM +0200, Linus Walleij wrote:
> 2011/6/29 Rafael J. Wysocki <rjw@sisk.pl>:
>
> > One of the roles of the PM core is to prevent different PM callbacks
> > executed for the same device object from racing with each other.
> > Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
> > (PM: Allow pm_runtime_suspend() to succeed during system suspend)
> > runtime PM callbacks may be executed concurrently with system
> > suspend/resume callbacks for the same device.
> (...)
> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
>
> A quick question: is there some specific reason why this patch should
> not go into the 3.0.y stable releases? We are trying to produce
> a runtime PM system of product quality based on 3.0.y and we've
> already had to backport this patch ourselves to get things stable.
>
> We have also backported:
> PM: Introduce generic "noirq" callback routines for subsystems (v2)
> PM / Runtime: Update documentation of interactions with system sleep
> PM / Runtime: Add new helper function: pm_runtime_status_suspended()
>
> And now it seems to be sufficient to get this thing going.
So, what specific git commits do you want to see in the 3.0-stable
tree, and in what order should they be applied in?
thanks,
greg k-h
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Dmitry Torokhov @ 2011-11-02 17:08 UTC (permalink / raw)
To: Andrew Watts; +Cc: tj, linux-pm, linux-kernel
In-Reply-To: <20111102170058.GA2388@zeus>
On Wednesday, November 02, 2011 10:01:00 AM Andrew Watts wrote:
> On Wed, Nov 02, 2011 at 09:31:09AM -0700, Dmitry Torokhov wrote:
> > OK, it looks like you do have input, what you do not have is X
> > functioning.
>
> The extent of my tests on input were to notice that the LED for caps
> lock does not toggle when pressing "caps lock" after a bad resume. I
> have also tried to blindly type "reboot" and such in what should be an
> active xterm.
When in X it is X that is responsible for LED switching. Also input
processing beyond the kernel won't be happening if X is hosed.
--
Dmitry
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Andrew Watts @ 2011-11-02 17:01 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: tj, linux-pm, linux-kernel
In-Reply-To: <20111102163109.GA29430@core.coreip.homeip.net>
On Wed, Nov 02, 2011 at 09:31:09AM -0700, Dmitry Torokhov wrote:
>
> OK, it looks like you do have input, what you do not have is X
> functioning.
The extent of my tests on input were to notice that the LED for caps
lock does not toggle when pressing "caps lock" after a bad resume. I
have also tried to blindly type "reboot" and such in what should be an
active xterm.
~ Andy
^ permalink raw reply
* PM / OPP: Fix build when CONFIG_PM_OPP is not set
From: Tony Lindgren @ 2011-11-02 17:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, linux-kernel, Kyungmin Park, MyungJoo Ham, linux-pm,
linux-omap
Commit 03ca370fbf7b76d6d002380dbdc2cdc2319f9c80 (PM / OPP: Add
OPP availability change notifier) does not compile if CONFIG_PM_OPP
is not set:
arch/arm/plat-omap/omap-pm-noop.o: In function `opp_get_notifier':
include/linux/opp.h:103: multiple definition of `opp_get_notifier'
include/linux/opp.h:103: first defined here
Also fix incorrect comment.
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mike Turquette <mturquette@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
I'm seeing this with omap1_defconfig at least.
--- a/include/linux/opp.h
+++ b/include/linux/opp.h
@@ -97,11 +97,11 @@ static inline int opp_disable(struct device *dev, unsigned long freq)
return 0;
}
-struct srcu_notifier_head *opp_get_notifier(struct device *dev)
+static inline struct srcu_notifier_head *opp_get_notifier(struct device *dev)
{
return ERR_PTR(-EINVAL);
}
-#endif /* CONFIG_PM */
+#endif /* CONFIG_PM_OPP */
#if defined(CONFIG_CPU_FREQ) && defined(CONFIG_PM_OPP)
int opp_init_cpufreq_table(struct device *dev,
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Dmitry Torokhov @ 2011-11-02 16:31 UTC (permalink / raw)
To: Andrew Watts; +Cc: tj, linux-pm, linux-kernel
In-Reply-To: <20111102160208.GA6657@zeus>
On Wed, Nov 02, 2011 at 11:02:09AM -0500, Andrew Watts wrote:
> On Tue, Nov 01, 2011 at 10:46:58PM -0700, Dmitry Torokhov wrote:
> >
> > Are you hibernating from text console or X? Can you try plugging in USB
> > keyboard and see if you are getting input? What about ssh into the box?
>
> Forgot to answer a few of your questions. Plugging in a USB keyboard does
> not help.
OK, it looks like you do have input, what you do not have is X
functioning.
I am not sure why radeon reports lockup with that patch; serio uses
system_long_wq to schedule its long-playing works and the only other
user of system_long_wq seems to be sata, but then concurrency management
should take care of them sharing the workqueue.
Tejun, do you have any ideas here?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Andrew Watts @ 2011-11-02 16:02 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: tj, linux-pm, linux-kernel
In-Reply-To: <20111102054658.GA29035@core.coreip.homeip.net>
On Tue, Nov 01, 2011 at 10:46:58PM -0700, Dmitry Torokhov wrote:
>
> Are you hibernating from text console or X? Can you try plugging in USB
> keyboard and see if you are getting input? What about ssh into the box?
Forgot to answer a few of your questions. Plugging in a USB keyboard does
not help. And for now I cannot test whether the sshd daemon is reponsive
though it would seem that it would indeed be OK.
~ Andy
^ permalink raw reply
* Re: hiberante hangs TCP Re: [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking
From: Tejun Heo @ 2011-11-02 15:10 UTC (permalink / raw)
To: MyungJoo Ham; +Cc: netdev, linux-pm, David Fries, linux-kernel
In-Reply-To: <CAJ0PZbSRX6Rqn5NnnMkVGrPovtSuc2NWasysOYnjr3j9rON1VQ@mail.gmail.com>
Hello,
On Wed, Nov 02, 2011 at 06:44:31PM +0900, MyungJoo Ham wrote:
> > Hmmm... sounds like taking down network interfaces before starting
> > hibernation sequence should be enough, which shouldn't be too
> > difficult to implement from userland. Rafael, what do you think?
> >
> > Thanks.
>
> Um... it seems that the "thaw" callbacks of network interfaces or TCP
> should do something on this.
>
> Probably, the "thaw" callbacks should make sure that the TCP
> connections are closed?
I don't think it's a good idea to diddle with TCP connections from
that layer. From what I understand, it seem all we need is plugging
tx/rx while preparing for hibernation. That shouldn't be too
difficult.
Thanks.
--
tejun
^ 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