http://permalink.gmane.org/gmane.linux.power-management.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.power-management.general/34249 <pre>on i386: CONFIG_ACPI_PROCESSOR=m CONFIG_X86_E_POWERSAVER=y drivers/built-in.o: In function `eps_cpu_init.part.8': e_powersaver.c:(.text.unlikely+0x2243): undefined reference to `acpi_processor_register_performance' e_powersaver.c:(.text.unlikely+0x22a2): undefined reference to `acpi_processor_unregister_performance' e_powersaver.c:(.text.unlikely+0x246b): undefined reference to `acpi_processor_get_bios_limit' X86_E_POWERSAVER should also depend on ACPI_PROCESSOR. Signed-off-by: Rafal Bilski &lt;rafalbilski&lt; at &gt;interia.pl&gt; --- drivers/cpufreq/Kconfig.x86 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86 index 2b8a8c3..6bd63d6 100644 --- a/drivers/cpufreq/Kconfig.x86 +++ b/drivers/cpufreq/Kconfig.x86 &lt; at &gt;&lt; at &gt; -272,7 +272,7 &lt; at &gt;&lt; at &gt; config X86_LONGHAUL config X86_E_POWERSAVER tristate "VIA C7 Enhanced PowerSaver (DANGEROUS)" select CPU_FREQ_TABLE -depends on X86_32 +depends on X86_32 &amp;&amp; ACPI_PROCESSOR help This adds the CPUFreq driver for</pre> Rafal Bilski 2013-05-19T19:27:55 http://permalink.gmane.org/gmane.linux.power-management.general/34247 <pre> No, it still registers the bL driver. The problem is not that DT data is missing, but it is present on a single cluster system. This is what my 1st cpu node looks like: $ ls /proc/device-tree/cpus/cpu&lt; at &gt;900/ clock-latency clocks device_type next-level-cache reg clock-names compatible name operating-points transition-latency This is the boot log: [ 1.192186] cpu cpu0: get_cluster_clk_and_freq_table: Failed to get clk for cpu: 0, cluster: 9 [ 1.200804] cpu cpu0: get_cluster_clk_and_freq_table: Failed to get data for cluster: 9 [ 1.208815] cpu cpu1: get_cluster_clk_and_freq_table: init_opp_table failed, cpu: 1, err: -61 [ 1.217345] cpu cpu1: get_cluster_clk_and_freq_table: Failed to get data for cluster: 9 [ 1.225354] cpu cpu2: get_cluster_clk_and_freq_table: init_opp_table failed, cpu: 2, err: -61 [ 1.233879] cpu cpu2: get_cluster_clk_and_freq_table: Failed to get data for cluster: 9 [ 1.241880] cpu cpu3: get_cluster_clk_and_freq_table: init_opp_table failed, cpu: 3,</pre> Rob Herring 2013-05-18T19:51:04 http://permalink.gmane.org/gmane.linux.power-management.general/34244 <pre> Yes.. Pick only 3/3 for 3.10 and others for later part.. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Viresh Kumar 2013-05-18T11:30:50 http://permalink.gmane.org/gmane.linux.power-management.general/34243 <pre>[...] Shouldn't it be if (WARN_ON(drv-&gt;refcnt &gt; 0)) return; ? Also, shouldn't things be undone in reverse order as they were done in __cpuidle_register_driver()? I mean disabling the timer broadcast notification before calling __cpuidle_unset_driver(). Regards, Francesco -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Francesco Lavra 2013-05-18T11:15:05 http://permalink.gmane.org/gmane.linux.power-management.general/34242 <pre>When thermal zone device is updated, it doesn't need to check every trip points and its handling mathod even current temperature doesn't exceed the trip's temperature. To modify those dissipatve mechanism, this patch introduces the way to get current thermal trip point to call only correspond trip point handling. Signed-off-by: Jonghwa Lee &lt;jonghwa3.lee&lt; at &gt;samsung.com&gt; Signed-off-by: MyungJoo Ham &lt;myungjoo.ham&lt; at &gt;samsung.com&gt; --- drivers/thermal/thermal_core.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index ce4384a..1cc4825 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c &lt; at &gt;&lt; at &gt; -333,14 +333,6 &lt; at &gt;&lt; at &gt; static void handle_non_critical_trips(struct thermal_zone_device *tz, static void handle_critical_trips(struct thermal_zone_device *tz, int trip, enum thermal_trip_type trip_type) { -long trip_temp; - -tz-&gt;ops-&gt;get_trip_temp(tz, trip, &amp;trip_temp); - -/* If we ha</pre> Jonghwa Lee 2013-05-18T09:51:03 http://permalink.gmane.org/gmane.linux.power-management.general/34241 <pre>This patch modifies temp_crit_show() which is used to create hwmon's sysfs node to use .get_crit_temp callback function of thermal zone device rather than .get_trip_temp. Signed-off-by: Jonghwa Lee &lt;jonghwa3.lee&lt; at &gt;samsung.com&gt; Signed-off-by: MyungJoo Ham &lt;myungjoo.ham&lt; at &gt;samsung.com&gt; --- drivers/thermal/thermal_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index f753f48..ce4384a 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c &lt; at &gt;&lt; at &gt; -924,7 +924,7 &lt; at &gt;&lt; at &gt; temp_crit_show(struct device *dev, struct device_attribute *attr, long temperature; int ret; -ret = tz-&gt;ops-&gt;get_trip_temp(tz, 0, &amp;temperature); +ret = tz-&gt;ops-&gt;get_crit_temp(tz, &amp;temperature); if (ret) return ret; </pre> Jonghwa Lee 2013-05-18T09:50:56 http://permalink.gmane.org/gmane.linux.power-management.general/34240 <pre>This patch adds a requirement needing .get_trip_temp() callback function for registering thermal zone device. This function is used when thermal zone is updated and essential where thermal core handles thermal trip based only polling way not hw interrupt. Signed-off-by: Jonghwa Lee &lt;jonghwa3.lee&lt; at &gt;samsung.com&gt; Signed-off-by: MyungJoo Ham &lt;myungjoo.ham&lt; at &gt;samsung.com&gt; --- drivers/thermal/thermal_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index d755440..f753f48 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c &lt; at &gt;&lt; at &gt; -1624,7 +1624,7 &lt; at &gt;&lt; at &gt; struct thermal_zone_device *thermal_zone_device_register(const char *type, if (!ops || !ops-&gt;get_temp) return ERR_PTR(-EINVAL); -if (trips &gt; 0 &amp;&amp; !ops-&gt;get_trip_type) +if (trips &gt; 0 &amp;&amp; (!ops-&gt;get_trip_type || !ops-&gt;get_trip_temp)) return ERR_PTR(-EINVAL); tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL); </pre> Jonghwa Lee 2013-05-18T09:50:26 http://permalink.gmane.org/gmane.linux.power-management.general/34238 <pre> I have a question about your implementation for supporting EXYNOS5440. I don't know exactly how EXYNO5440's tmu is working, but just guess it would be similar with other EXYNOS series's without number of thermal sensors. (exclusive register map and threshold level). Due to the multiple number of thermal sensor in EXYNOS5440, it have multiple thermal zone devices and that's why it just leave interrupt pin in pending if interrupt is not its, right? So, my curious is, why we make all platform devices for each of thermal zone devices? Why don't you just handle all thermal zone devices with one platform device? Yes, It's probably right to make multiple devices node to support them, because it has different physical hardware(sensors). But we have one TMU , don't we? (Maybe my assumption is wrong, I assume that it has one TMU because it looks like it has only one irq line.). If I'm right, I think it is better to manage all thermal zone devices with one platform device. Then, we don't need to leave irq handler </pre> jonghwa3.lee< at >samsung.com 2013-05-18T05:23:18 http://permalink.gmane.org/gmane.linux.power-management.general/34237 <pre>[...] Ah, ok.. No problem! :-) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Srivatsa S. Bhat 2013-05-18T05:04:57 http://permalink.gmane.org/gmane.linux.power-management.general/34235 <pre> See if this fixes your issue. https://groups.google.com/forum/?fromgroups#!topic/linux.kernel/XJF-82rad4o Attached too. </pre> Viresh Kumar 2013-05-18T02:03:48 http://permalink.gmane.org/gmane.linux.power-management.general/34234 <pre> I think it *is* worth the effort. We could drop some CONFIG_PM* options in the process which would simplify things quite a bit too. Thanks a lot for the very clear explanation of this! Rafael </pre> Rafael J. Wysocki 2013-05-17T23:51:11 http://permalink.gmane.org/gmane.linux.power-management.general/34233 <pre>This driver register CPU digital temperature sensor as a thermal zone at package level. Each package will show up as one zone with at max two trip points. These trip points can be both read and updated. Once a non zero value is set in the trip point, if the package package temperature goes above or below this setting, a thermal notification is generated. Signed-off-by: Srinivas Pandruvada &lt;srinivas.pandruvada&lt; at &gt;linux.intel.com&gt; --- drivers/thermal/Kconfig | 12 + drivers/thermal/Makefile | 2 +- drivers/thermal/x86_pkg_temp_thermal.c | 642 +++++++++++++++++++++++++++++++++ 3 files changed, 655 insertions(+), 1 deletion(-) create mode 100644 drivers/thermal/x86_pkg_temp_thermal.c diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index a764f16..ed9b983 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig &lt; at &gt;&lt; at &gt; -165,4 +165,16 &lt; at &gt;&lt; at &gt; config INTEL_POWERCLAMP enforce idle time which results in more package C-state residency. The user interface is expos</pre> Srinivas Pandruvada 2013-05-17T23:42:02 http://permalink.gmane.org/gmane.linux.power-management.general/34232 <pre>Added documentation describing details of the x86 package temperature thermal driver. Signed-off-by: Srinivas Pandruvada &lt;srinivas.pandruvada&lt; at &gt;linux.intel.com&gt; --- Documentation/thermal/x86_pkg_temperature_thermal | 47 +++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/thermal/x86_pkg_temperature_thermal diff --git a/Documentation/thermal/x86_pkg_temperature_thermal b/Documentation/thermal/x86_pkg_temperature_thermal new file mode 100644 index 0000000..17a3a4c --- /dev/null +++ b/Documentation/thermal/x86_pkg_temperature_thermal &lt; at &gt;&lt; at &gt; -0,0 +1,47 &lt; at &gt;&lt; at &gt; +Kernel driver: x86_pkg_temp_thermal +=================== + +Supported chips: +* x86: with package level thermal management +(Verify using: CPUID.06H:EAX[bit 6] =1) + +Authors: Srinivas Pandruvada &lt;srinivas.pandruvada&lt; at &gt;linux.intel.com&gt; + +Reference +--- +Intel® 64 and IA-32 Architectures Software Developer’s Manual (Jan, 2013): +Chapter 14.6: PACKAGE LEVEL THERMAL MANAGEMENT + +Description +--------- + +This driver registe</pre> Srinivas Pandruvada 2013-05-17T23:42:03 http://permalink.gmane.org/gmane.linux.power-management.general/34231 <pre>Added callback registration for package threshold reports. Also added a callback to check the rate control implemented in callback or not. If there is no rate control implemented, then there is a default rate control similar to core threshold notification by delaying for CHECK_INTERVAL (5 minutes) between reports. Signed-off-by: Srinivas Pandruvada &lt;srinivas.pandruvada&lt; at &gt;linux.intel.com&gt; --- arch/x86/include/asm/mce.h | 7 ++++ arch/x86/kernel/cpu/mcheck/therm_throt.c | 63 ++++++++++++++++++++++++++++++-- 2 files changed, 66 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h index f4076af..4c619bf 100644 --- a/arch/x86/include/asm/mce.h +++ b/arch/x86/include/asm/mce.h &lt; at &gt;&lt; at &gt; -214,6 +214,13 &lt; at &gt;&lt; at &gt; void mce_log_therm_throt_event(__u64 status); /* Interrupt Handler for core thermal thresholds */ extern int (*platform_thermal_notify)(__u64 msr_val); +/* Interrupt Handler for package thermal thresholds */ +extern int (*platform_thermal_package_notify)(</pre> Srinivas Pandruvada 2013-05-17T23:42:01 http://permalink.gmane.org/gmane.linux.power-management.general/34230 <pre>This driver register CPU digital temperature package level sensor as a thermal zone with two user mode configurable trip points. Once the trip point is violated, user mode can receive notification via thermal notification mechanism and can take any action to control temperature. Changes: v02: Did majority of changes suggested by Eduardo Valentin. Main changes are: - Module parameters for rate control delay - Removed user space gov parameter in thermal_zone_register - Changes related to returning of errors values - Error code return values v01: First version for review Background: This set of changes were done to coretemp driver and posted to lm_sensors mailing list on 04/04/2013. This was reviewed by Guenter Roeck from lm-sensors and Zhang Rui (thermal maintainer). They were in agreement not to add notification mechanism to coretemp driver but use thermal sysfs. Guenter Roeck suggested to use approach like "db8500_thermal driver in drivers/thermal". So resubmitting the driver as a thermal zone driver. Pre</pre> Srinivas Pandruvada 2013-05-17T23:42:00 http://permalink.gmane.org/gmane.linux.power-management.general/34228 <pre> I went through your previous mails and here is what I think: I think this is not a regression that needs to be fixed. Instead it occurs to me that you started depending on the _flaw_ introduced by commit e8db0be124 (PM QoS: Move and rename the implementation files). Your requirement is very simple: you don't want CPUs to go to deep idle states, since your benchmark is very performance critical. Commit e8db0be124 made the mistake of returning 0 in pm_qos_request() when CONFIG_PM was unset. And that has the effect of disabling deeper idle states, which is exactly what you wanted. But, as noted by commit d020283d (PM / QoS: CPU C-state breakage with PM Qos change), this is quite a bit wrong, because it makes the system consume a *lot* of CPU power, because the CPUs never go to idle states and instead keep polling. Now, you might ask why is it wrong to set the default value to 0 (IOW, disable deep idle states) when CONFIG_PM is unset? Again, commit d020283d answers that indirectly - not every power-manageme</pre> Srivatsa S. Bhat 2013-05-17T19:50:10 http://permalink.gmane.org/gmane.linux.power-management.general/34225 <pre>The bL cpufreq driver appears to collide with the cpufreq-cpu0 driver. There doesn't appear to be a functional problem, but just spurious prints which indicate it is trying to do something. I think it needs better checking whether the chip is actually multi-cluster. This is what I get when I hotplug cpus: [ 909.372319] CPU1: Booted secondary processor [ 909.372616] cpu cpu1: get_cluster_clk_and_freq_table: init_opp_table failed, cpu: 1, err: -61 [ 909.385411] cpu cpu1: get_cluster_clk_and_freq_table: Failed to get data for cluster: 9 [ 909.394161] CPU2: shutdown [ 909.400957] CPU2: Booted secondary processor [ 909.401253] cpu cpu2: get_cluster_clk_and_freq_table: init_opp_table failed, cpu: 2, err: -61 [ 909.414044] cpu cpu2: get_cluster_clk_and_freq_table: Failed to get data for cluster: 9 Rob -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Rob Herring 2013-05-17T19:36:28 http://permalink.gmane.org/gmane.linux.power-management.general/34224 <pre>Hi, will do, thanks for the feedback. I used the goto to make the code addition smaller, but I obviously sacrificed code clarity. ________________________________________ From: Greg Kroah-Hartman [gregkh&lt; at &gt;linuxfoundation.org] Sent: Friday, May 17, 2013 12:11 PM To: Brandt, Todd E Cc: linux-ide&lt; at &gt;vger.kernel.org; linux-scsi&lt; at &gt;vger.kernel.org; linux-pm&lt; at &gt;vger.kernel.org; Jeff Garzik; Jens Axboe; Wysocki, Rafael J; Arjan van de Ven Subject: Re: [PATCH v2 2/2] Adds new device resume mode in PM core, async plus non-blocking On Fri, May 17, 2013 at 07:05:33PM +0000, Brandt, Todd E wrote: "hascb"? Please spell out what this is. You want to jump backwards? This isn't the scheduler, please, you can do better here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Brandt, Todd E 2013-05-17T19:29:57 http://permalink.gmane.org/gmane.linux.power-management.general/34221 <pre>This patch goes through and sets the power.async_suspend flag for every device in the ATA/SCSI resume path. This includes the ata port, link, and dev devices, the scsi host and target devices, all their associated transport devices, the block devices, and block partitions. This allows the entire ATA resume path to be added to the async device queue in drivers/base/power/main.c. Without this, the ATA resume path ends up in both queues (sync and async), which causes interdependencies and backs up the two queues. Changelog: v2: - Updated patch submission. Incorporates comments from Tejun Heo. Fixed pr_debug format, No functional changes. Signed-off-by: Todd Brandt &lt;todd.e.brandt&lt; at &gt;intel.com&gt; --- block/genhd.c | 2 ++ block/partition-generic.c | 1 + drivers/ata/libata-transport.c | 4 +++- drivers/base/attribute_container.c | 1 + drivers/base/core.c | 8 +++++++- drivers/scsi/scsi_sysfs.c | 2 +- drivers/scsi/sd.c</pre> Brandt, Todd E 2013-05-17T19:03:30 http://permalink.gmane.org/gmane.linux.power-management.general/34220 <pre>The vast majority of time spent in S3 resume is consumed by the ATA subsystem as it resumes the computer's hard drives. For large hard disks this time can be upwards of 10 seconds, which makes S3 suspend/resume too costly to use frequently. This time needs to be reduced. More details here: https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-worst-offender This patch set effectively reduces S3 resume time from multiple seconds to less than 700ms. The idea is to allow the ATA/SCSI subsystems to resume asynchronously without blocking system resume completion. The dpm_resume call currently waits for all asynchronous devices to finish resuming before it gives control back to the user. But in the case of ATA/SCSI we can give control back immediately, since the hard disks won't be needed immediately in lieu of RAM and cache. Patch 1/2 goes through and sets the power.async_suspend flag for every device in the ATA/SCSI resume path. This includes the ata port, link, and dev devices, the scsi host and</pre> Brandt, Todd E 2013-05-17T19:00:21 http://permalink.gmane.org/gmane.linux.power-management.general/34218 <pre> I will update the patch to only include Ivy bridge. This was a brain fade on my part. The numbers to marketing name decoding are in system programming manual. I don't know of a model number to project name list. intel_pstate is intended only for SandyBridge+ CPU's -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Dirk Brandewie 2013-05-17T16:08:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.power-management.general