Sachin Kamat | 21 May 2013 11:20
Favicon

[PATCH 1/1] Thermal: spear: Fix compilation error

Fixes the following compilation error introduced by commit 253e3ae170
(Thermal: spear_thermal: convert to devm_ioremap_resource).
drivers/thermal/spear_thermal.c: In function ‘spear_thermal_probe’:
drivers/thermal/spear_thermal.c:123:46: error: ‘dev’ undeclared
(first use in this function)
stdev->thermal_base = devm_ioremap_resource(dev, res);

While at it also remove the error message as devm_ioremap_resource()
provides its own error messages.

Signed-off-by: Sachin Kamat <sachin.kamat <at> linaro.org>
Cc: Vincenzo Frascino <vincenzo.frascino <at> st.com>
Cc: Viresh Kumar <viresh.kumar <at> linaro.org>
---
Compile tested and based on linux-next (20130521).
---
 drivers/thermal/spear_thermal.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/spear_thermal.c b/drivers/thermal/spear_thermal.c
index fa30918..813add6 100644
--- a/drivers/thermal/spear_thermal.c
+++ b/drivers/thermal/spear_thermal.c
 <at>  <at>  -120,11 +120,9  <at>  <at>  static int spear_thermal_probe(struct platform_device *pdev)

 	/* Enable thermal sensor */
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	stdev->thermal_base = devm_ioremap_resource(dev, res);
-	if (IS_ERR(stdev->thermal_base)) {
-		dev_err(&pdev->dev, "ioremap failed\n");
(Continue reading)

mohamed haneef | 20 May 2013 18:39
Picon

linux power management

Hi, I would like to learn power management module programming, any
suggestions other than the kernel documentation and googling. like
books specific to power management it would be ok even if the book is
not related to linux power mangement ( I would relate it no problem )

thanks in advance.
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mohamed haneef | 20 May 2013 18:41
Picon

linux power management

Hi, I would like to learn power management module programming, any
suggestions other than the kernel documentation and googling. like
books specific to power management it would be ok even if the book is
not related to linux power mangement ( I would relate it no problem )

thanks in advance.
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafal Bilski | 19 May 2013 21:27
Picon
Favicon

[PATCH] e_powersaver: Fix linker error when ACPI processor is a module

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 <rafalbilski <at> interia.pl>
---
 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
 <at>  <at>  -272,7 +272,7  <at>  <at>  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 && ACPI_PROCESSOR
 	help
 	  This adds the CPUFreq driver for VIA C7 processors.  However, this driver
 	  does not have any safeguards to prevent operating the CPU out of spec
--

-- 
(Continue reading)

Jonghwa Lee | 18 May 2013 11:51

[PATCH 3/3] Thermal:core: Handle trips focused on current trip point only.

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 <jonghwa3.lee <at> samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham <at> samsung.com>
---
 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
 <at>  <at>  -333,14 +333,6  <at>  <at>  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->ops->get_trip_temp(tz, trip, &trip_temp);
-
-	/* If we have not crossed the trip_temp, we do not care. */
-	if (tz->temperature < trip_temp)
-		return;
-
 	if (tz->ops->notify)
 		tz->ops->notify(tz, trip, trip_type);
(Continue reading)

Jonghwa Lee | 18 May 2013 11:50

[PATCH 2/3] Thermal: core: Modify temp_crit_show() to use proper callback function.

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 <jonghwa3.lee <at> samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham <at> samsung.com>
---
 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
 <at>  <at>  -924,7 +924,7  <at>  <at>  temp_crit_show(struct device *dev, struct device_attribute *attr,
 	long temperature;
 	int ret;

-	ret = tz->ops->get_trip_temp(tz, 0, &temperature);
+	ret = tz->ops->get_crit_temp(tz, &temperature);
 	if (ret)
 		return ret;

--

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Jonghwa Lee | 18 May 2013 11:50

[PATCH 1/3] Thermal: core: Ask .get_trip_temp() to register thermal zone device.

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 <jonghwa3.lee <at> samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham <at> samsung.com>
---
 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
 <at>  <at>  -1624,7 +1624,7  <at>  <at>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	if (!ops || !ops->get_temp)
 		return ERR_PTR(-EINVAL);

-	if (trips > 0 && !ops->get_trip_type)
+	if (trips > 0 && (!ops->get_trip_type || !ops->get_trip_temp))
 		return ERR_PTR(-EINVAL);

 	tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL);
--

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Srinivas Pandruvada | 18 May 2013 01:42
Picon

[PATCH 0/3] CPU Package temperarure thermal driver (v02)

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.
Previous discussion link:
http://comments.gmane.org/gmane.linux.drivers.sensors/32182
" 
This is clear that there is reluctance in adding thresholds in coretemp sysfs,
during previous attempts. Probably because of lake of use cases.
But this time use case may be more compelling.

(Continue reading)

Rob Herring | 17 May 2013 21:36
Picon

spurious bL cpufreq driver messages

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 <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Brandt, Todd E | 17 May 2013 21:03
Picon
Favicon
Gravatar

[PATCH v2 1/2] ATA/SCSI subsystem resume path made fully asynchronous

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 <todd.e.brandt <at> intel.com>
---
 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                  |    3 +++
 7 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 7dcfdd8..3825d45 100644
--- a/block/genhd.c
+++ b/block/genhd.c
 <at>  <at>  -525,6 +525,8  <at>  <at>  static void register_disk(struct gendisk *disk)
(Continue reading)

Brandt, Todd E | 17 May 2013 21:00
Picon
Favicon
Gravatar

[PATCH v2 0/2] Hard disk S3 resume time optimization

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 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.

Patch 2/2 updates the drivers/base/power subsystem to allow any devices which
have registred as asynchronous and who have not registered "complete"
callbacks to be non-blocking. The ATA/SCSI subsystem devices don't
register complete callbacks, so they automatically use the new feature.

(Continue reading)


Gmane