* 3.3-rc4+: Reported regressions 3.1 -> 3.2
From: Rafael J. Wysocki @ 2012-02-23 23:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some post-3.1 regressions introduced before
3.2, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-3.1 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2012-02-24 9 8 7
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42714
Subject : 3.2.x Regression for SAS Controller on Dell C6100
Submitter : Herbert Poetzl <herbert-dBHVzrDq9nF4Lj/PQRBjDg@public.gmane.org>
Date : 2012-01-31 18:09 (24 days old)
Message-ID : <20120131180949.GT29272-ZD0Mn47LIGX0Pe/G4T7+5F6hYfS7NtTn@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=132803360019481&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42685
Subject : multi-media key "mute" no longer recognized
Submitter : Toralf Förster <toralf.foerster-Mmb7MZpHnFY@public.gmane.org>
Date : 2012-01-23 10:52 (32 days old)
Message-ID : <201201231152.25344.toralf.foerster-Mmb7MZpHnFY@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=132731613606121&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42684
Subject : FYIO: usb/video 3.2 breaks logitech 9000pro webcam focus control
Submitter : M G Berberich <berberic-vmG2aq7wDA3mFSIgyKwhw7NAH6kLmebB@public.gmane.org>
Date : 2012-01-23 21:49 (32 days old)
Message-ID : <20120123214934.GA4240@invalid>
References : http://marc.info/?l=linux-kernel&m=132735609521443&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42631
Subject : Sound broken in 3.2.0 and 3.2.1
Submitter : Joseph Parmelee <jparmele-0t/HR9YC43JWk0Htik3J/w@public.gmane.org>
Date : 2012-01-13 19:44 (42 days old)
Message-ID : <alpine.LNX.2.00.1201131241090.1239@bruno>
References : http://marc.info/?l=linux-kernel&m=132648462806235&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42629
Subject : recvmsg sleeping from invalid context
Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2012-01-13 18:24 (42 days old)
Message-ID : <20120113182401.GA25885-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=132647921304184&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42611
Subject : kernel 3.2 crashes too early on HP dc7700 and HP t5000 series
Submitter : Dmitry D. Khlebnikov <galaxy-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
Date : 2012-01-10 11:49 (45 days old)
Message-ID : <20120110114905.GC13535-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=132619793012702&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42610
Subject : 3.2.0 reboot powers off machine
Submitter : Tom Weber <l_linux-kernel-w8lRr17kQ6puIcIf6OMhTAC/G2K4zDHf@public.gmane.org>
Date : 2012-01-11 11:03 (44 days old)
Message-ID : <1326279818.24835.12.camel@utumno>
References : http://marc.info/?l=linux-kernel&m=132628059308023&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42571
Subject : BUG in ofcs2_change_file_space
Submitter : Bret Towe <magnade-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2012-01-05 22:23 (50 days old)
Message-ID : <CALjC5haTNDMOTDPL1m1uBTc2a-Qb8cvR44SCaVDFMzGc+Gw3+w@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=132580236211209&w=2
Patch : http://oss.oracle.com/pipermail/ocfs2-devel/2012-January/008464.html
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 3.1 and 3.2, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=42566
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* 3.3-rc4+: Reported regressions from 3.2
From: Rafael J. Wysocki @ 2012-02-23 22:51 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
Hi all,
We definitely aren't 100% in business yet with the tracking of regressions,
but since the Bugzilla is operational again, we can collect reports at least.
I'd like to use this opportunity to thank Maciej Rutecki and Florian Mickler
for their hard work on the regression tracking and to clarify some things that
seem to have caused some confusion to happen recently. Namely, we use the
kernel Bugzilla (https://bugzilla.kernel.org) for the tracking of regressions
for the simple reason that our scripts generate the lists that are posted
(like the one below) out of Bugzilla entries created by us (and sometimes
by other people). Those entries are used by us as a storage of information,
so we're going to add them even though some kernel developers don't seem to
like that. We don't require developers to actually use those entries for
handling bug reports, we only need people to let us know when they should be
closed, because the bug has been fixed in the Linus' tree, or when there's
a patch available for the bug (in which case we mark it as "resolved", but
we don't close it just yet). There is no reason for you to be openly hostile
to Maciej, who's been creating those entries recently, because he's just been
doing his job. However, you may not want us to track kernel regressions at
all, in which case please let us know about that and we will find some other,
presumably equally interesting things to do. :-)
Yes, we might have been more verbose about what _exactly_ we've been using the
Bugzilla for and what our workflow is, but at the same time people might have
been a bit less harsh to someone who's been doing a service to the community,
completely voluntarily.
Thanks,
Rafael
---
This message contains a list of some regressions from 3.2,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 3.2, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2012-02-23 15 13 13
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42798
Subject : i915 regression with 3.3-rc3+git
Submitter : Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Date : 2012-02-17 20:48 (7 days old)
Message-ID : <4F3EBD0D.7000906@gmail.com>
References : http://marc.info/?l=linux-kernel&m=132951173002619&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42776
Subject : OF-related boot crash in 3.3.0-rc3-00188-g3ec1e88
Submitter : Meelis Roos <mroos@linux.ee>
Date : 2012-02-13 7:45 (11 days old)
Message-ID : <alpine.SOC.1.00.1202130942030.1488@math.ut.ee>
References : http://marc.info/?l=linux-kernel&m=132911916331615&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42761
Subject : Possible circular locking dependency (3.3-rc2)
Submitter : Felipe Balbi <balbi@ti.com>
Date : 2012-02-08 12:41 (16 days old)
Message-ID : <20120208124147.GF16334@legolas.emea.dhcp.ti.com>
References : http://marc.info/?l=linux-kernel&m=132870492311858&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42746
Subject : 3.3-rc2 snd_pcm lockdep backtrace
Submitter : Josh Boyer <jwboyer@redhat.com>
Date : 2012-02-06 14:56 (18 days old)
Message-ID : <20120206145621.GA4771@zod.bos.redhat.com>
References : http://marc.info/?l=linux-kernel&m=132854040916172&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42735
Subject : kobject (ffff88003ffbb4b8): tried to init an initialized object, something is seriously wrong.
Submitter : Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date : 2012-02-03 20:59 (21 days old)
Message-ID : <20120203205953.GA2897@phenom.dumpdata.com>
References : http://marc.info/?l=linux-kernel&m=132830315526901&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42734
Subject : dosemu graphics broken in v3.3-rc1
Submitter : Hans de Bruin <jmdebruin@xmsnet.nl>
Date : 2012-02-02 22:25 (22 days old)
First-Bad-Commit: http://git.kernel.org/linus/308e5bcbdb10452e8aba31aa21432fb67ee46d72
Message-ID : <4F2B0D4D.3000304@xmsnet.nl>
References : http://marc.info/?l=linux-kernel&m=132825899111982&w=2
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42733
Subject : Regression 3.2 -> 3.3-rc1 10 sec hang at boot and resume, COMRESET failed
Submitter : Norbert Preining <preining@logic.at>
Date : 2012-02-02 5:12 (22 days old)
Message-ID : <20120202051258.GA15550@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=132815978615112&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42713
Subject : Regression in skge that started around acb42a3 (so past v3.3-rc1)
Submitter : Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date : 2012-01-30 15:58 (25 days old)
Message-ID : <20120130155816.GA1400@phenom.dumpdata.com>
References : http://marc.info/?l=linux-kernel&m=132793944220262&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42707
Subject : Hang deconfiguring network interface (in shutdown) on 3.3-rc1
Submitter : James Bottomley <James.Bottomley@hansenpartnership.com>
Date : 2012-01-28 19:56 (27 days old)
Message-ID : <1327780565.2924.24.camel@dabdike.int.hansenpartnership.com>
References : http://marc.info/?l=linux-kernel&m=132778076214873&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42686
Subject : iwlagn is getting even worse with 3.3-rc1
Submitter : Norbert Preining <preining@logic.at>
Date : 2012-01-24 1:36 (31 days old)
Message-ID : <20120124013625.GB18436@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=132736918325378&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42683
Subject : WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
Submitter : Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date : 2012-01-23 18:06 (32 days old)
Message-ID : <20120123180601.GA24553@phenom.dumpdata.com>
References : http://marc.info/?l=linux-kernel&m=132734233916154&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42678
Subject : [3.3-rc1] radeon stuck in kernel after lockup
Submitter : Torsten Kaiser <just.for.lkml@googlemail.com>
Date : 2012-01-21 19:03 (34 days old)
Message-ID : <CAPVoSvSXMvRb=1itu9DjF+s=6zfAChvUxS-x=b8EV9kOZinNpA@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=132717279606670&w=2
Handled-By : Jérôme Glisse <glisse@freedesktop.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42669
Subject : 3.3-rc1: compiling problems nvme , l2cap_sock , mc13892-regulator , and snd-pcsp don't work
Submitter : werner <w.landgraf@ru.ru>
Date : 2012-01-20 18:52 (35 days old)
Message-ID : <web-682421181@zbackend1.aha.ru>
References : http://marc.info/?l=linux-kernel&m=132708923719565&w=2
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 3.2,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=42644
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 1/4] thermal: Add a new trip type to use cooling device instance number
From: Amit Kachhap @ 2012-02-23 11:20 UTC (permalink / raw)
To: R, Durgadoss
Cc: linaro-dev@lists.linaro.org, patches@linaro.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-pm@lists.linux-foundation.org, rob.lee@linaro.org
In-Reply-To: <4D68720C2E767A4AA6A8796D42C8EB59043B20@BGSMSX101.gar.corp.intel.com>
On 23 February 2012 12:16, R, Durgadoss <durgadoss.r@intel.com> wrote:
> Hi Amit,
>
>> -----Original Message-----
>> From: amit kachhap [mailto:amitdanielk@gmail.com] On Behalf Of Amit Daniel
>> Kachhap
>> Sent: Wednesday, February 22, 2012 3:44 PM
>> To: linux-pm@lists.linux-foundation.org
>> Cc: linux-kernel@vger.kernel.org; mjg59@srcf.ucam.org; linux-
>> acpi@vger.kernel.org; lenb@kernel.org; linaro-dev@lists.linaro.org;
>> amit.kachhap@linaro.org; R, Durgadoss; rob.lee@linaro.org; patches@linaro.org
>> Subject: [PATCH 1/4] thermal: Add a new trip type to use cooling device
>> instance number
>>
>> This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
>> trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
>> device instance number. This helps the cooling device registered as
>> different instances to perform appropriate cooling action decision in
>> the set_cur_state call back function.
>>
>> Also since the trip temperature's are in ascending order so some logic
>> is put in place to skip the un-necessary checks.
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
>> ---
>> Documentation/thermal/sysfs-api.txt | 4 +-
>> drivers/thermal/thermal_sys.c | 45 ++++++++++++++++++++++++++++++++--
>> include/linux/thermal.h | 1 +
>> 3 files changed, 45 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-
>> api.txt
>> index 1733ab9..7a0c080 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -184,8 +184,8 @@ trip_point_[0-*]_temp
>>
>> trip_point_[0-*]_type
>> Strings which indicate the type of the trip point.
>> - E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
>> - thermal zone.
>> + E.g. it can be one of critical, hot, passive, active[0-1],
>> + state-active[0-*] for ACPI thermal zone.
>> RO, Optional
>>
>> cdev[0-*]
>> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
>> index 220ce7e..d4c9b20 100644
>> --- a/drivers/thermal/thermal_sys.c
>> +++ b/drivers/thermal/thermal_sys.c
>> @@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct
>> device_attribute *attr,
>> return sprintf(buf, "passive\n");
>> case THERMAL_TRIP_ACTIVE:
>> return sprintf(buf, "active\n");
>> + case THERMAL_TRIP_STATE_ACTIVE:
>> + return sprintf(buf, "state-active\n");
>> default:
>> return sprintf(buf, "unknown\n");
>> }
>> @@ -1034,10 +1036,10 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
>>
>> void thermal_zone_device_update(struct thermal_zone_device *tz)
>> {
>> - int count, ret = 0;
>> - long temp, trip_temp;
>> + int count, ret = 0, inst_id;
>> + long temp, trip_temp, max_state, last_trip_change = 0;
>> enum thermal_trip_type trip_type;
>> - struct thermal_cooling_device_instance *instance;
>> + struct thermal_cooling_device_instance *instance, *state_instance;
>> struct thermal_cooling_device *cdev;
>>
>> mutex_lock(&tz->lock);
>> @@ -1086,6 +1088,43 @@ void thermal_zone_device_update(struct
>> thermal_zone_device *tz)
>> cdev->ops->set_cur_state(cdev, 0);
>> }
>> break;
>> + case THERMAL_TRIP_STATE_ACTIVE:
>> + list_for_each_entry(instance, &tz->cooling_devices,
>> + node) {
>> + if (instance->trip != count)
>> + continue;
>> +
>> + if (temp <= last_trip_change)
>> + continue;
>> +
>> + inst_id = 0;
>> + /*
>> + *For this instance how many instance of same
>> + *cooling device occured before
>> + */
>> +
>> + list_for_each_entry(state_instance,
>> + &tz->cooling_devices, node) {
>> + if (instance->cdev ==
>> + state_instance->cdev)
>> + inst_id++;
>> + if (state_instance->trip == count)
>> + break;
>> + }
>
> Can you explain a bit more on this loop and the set_cur_state below ?
> Sorry, I don't get the logic behind this..
This loop is basically finding the instance id of the same cooling device.
Say we have done like this,
thermal_zone_bind_cooling_device(thermal, 2, cdev);
thermal_zone_bind_cooling_device(thermal, 3, cdev);
thermal_zone_bind_cooling_device(thermal, 4, cdev);
In above same cooling device cdev is binded to trip no 2,3 and 4 with
inst_id generated as 1,2,3 respectively. so set_cur_state for those
trip reached will be called as,
set_cur_state(cdev, 1);
set_cur_state(cdev, 2);
set_cur_state(cdev, 3);
Thanks,
Amit D
>
> Thanks,
> Durga
>
>> +
>> + cdev = instance->cdev;
>> + cdev->ops->get_max_state(cdev, &max_state);
>> +
>> + if ((temp >= trip_temp) &&
>> + (inst_id <= max_state))
>> + cdev->ops->set_cur_state(cdev, inst_id);
>> + else if ((temp < trip_temp) &&
>> + (--inst_id <= max_state))
>> + cdev->ops->set_cur_state(cdev, inst_id);
>> +
>> + last_trip_change = trip_temp;
>> + }
>> + break;
>> case THERMAL_TRIP_PASSIVE:
>> if (temp >= trip_temp || tz->passive)
>> thermal_zone_device_passive(tz, temp,
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index 796f1ff..8df901f 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -42,6 +42,7 @@ enum thermal_trip_type {
>> THERMAL_TRIP_PASSIVE,
>> THERMAL_TRIP_HOT,
>> THERMAL_TRIP_CRITICAL,
>> + THERMAL_TRIP_STATE_ACTIVE,
>> };
>>
>> struct thermal_zone_device_ops {
>> --
>> 1.7.1
>
^ permalink raw reply
* Re: [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number
From: R, Durgadoss @ 2012-02-23 6:46 UTC (permalink / raw)
To: Amit Daniel Kachhap, linux-pm@lists.linux-foundation.org
Cc: linaro-dev@lists.linaro.org, patches@linaro.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
rob.lee@linaro.org
In-Reply-To: <1329905650-30161-2-git-send-email-amit.kachhap@linaro.org>
Hi Amit,
> -----Original Message-----
> From: amit kachhap [mailto:amitdanielk@gmail.com] On Behalf Of Amit Daniel
> Kachhap
> Sent: Wednesday, February 22, 2012 3:44 PM
> To: linux-pm@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.org; mjg59@srcf.ucam.org; linux-
> acpi@vger.kernel.org; lenb@kernel.org; linaro-dev@lists.linaro.org;
> amit.kachhap@linaro.org; R, Durgadoss; rob.lee@linaro.org; patches@linaro.org
> Subject: [PATCH 1/4] thermal: Add a new trip type to use cooling device
> instance number
>
> This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
> trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
> device instance number. This helps the cooling device registered as
> different instances to perform appropriate cooling action decision in
> the set_cur_state call back function.
>
> Also since the trip temperature's are in ascending order so some logic
> is put in place to skip the un-necessary checks.
>
> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
> ---
> Documentation/thermal/sysfs-api.txt | 4 +-
> drivers/thermal/thermal_sys.c | 45 ++++++++++++++++++++++++++++++++--
> include/linux/thermal.h | 1 +
> 3 files changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-
> api.txt
> index 1733ab9..7a0c080 100644
> --- a/Documentation/thermal/sysfs-api.txt
> +++ b/Documentation/thermal/sysfs-api.txt
> @@ -184,8 +184,8 @@ trip_point_[0-*]_temp
>
> trip_point_[0-*]_type
> Strings which indicate the type of the trip point.
> - E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
> - thermal zone.
> + E.g. it can be one of critical, hot, passive, active[0-1],
> + state-active[0-*] for ACPI thermal zone.
> RO, Optional
>
> cdev[0-*]
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 220ce7e..d4c9b20 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct
> device_attribute *attr,
> return sprintf(buf, "passive\n");
> case THERMAL_TRIP_ACTIVE:
> return sprintf(buf, "active\n");
> + case THERMAL_TRIP_STATE_ACTIVE:
> + return sprintf(buf, "state-active\n");
> default:
> return sprintf(buf, "unknown\n");
> }
> @@ -1034,10 +1036,10 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
>
> void thermal_zone_device_update(struct thermal_zone_device *tz)
> {
> - int count, ret = 0;
> - long temp, trip_temp;
> + int count, ret = 0, inst_id;
> + long temp, trip_temp, max_state, last_trip_change = 0;
> enum thermal_trip_type trip_type;
> - struct thermal_cooling_device_instance *instance;
> + struct thermal_cooling_device_instance *instance, *state_instance;
> struct thermal_cooling_device *cdev;
>
> mutex_lock(&tz->lock);
> @@ -1086,6 +1088,43 @@ void thermal_zone_device_update(struct
> thermal_zone_device *tz)
> cdev->ops->set_cur_state(cdev, 0);
> }
> break;
> + case THERMAL_TRIP_STATE_ACTIVE:
> + list_for_each_entry(instance, &tz->cooling_devices,
> + node) {
> + if (instance->trip != count)
> + continue;
> +
> + if (temp <= last_trip_change)
> + continue;
> +
> + inst_id = 0;
> + /*
> + *For this instance how many instance of same
> + *cooling device occured before
> + */
> +
> + list_for_each_entry(state_instance,
> + &tz->cooling_devices, node) {
> + if (instance->cdev ==
> + state_instance->cdev)
> + inst_id++;
> + if (state_instance->trip == count)
> + break;
> + }
Can you explain a bit more on this loop and the set_cur_state below ?
Sorry, I don't get the logic behind this..
Thanks,
Durga
> +
> + cdev = instance->cdev;
> + cdev->ops->get_max_state(cdev, &max_state);
> +
> + if ((temp >= trip_temp) &&
> + (inst_id <= max_state))
> + cdev->ops->set_cur_state(cdev, inst_id);
> + else if ((temp < trip_temp) &&
> + (--inst_id <= max_state))
> + cdev->ops->set_cur_state(cdev, inst_id);
> +
> + last_trip_change = trip_temp;
> + }
> + break;
> case THERMAL_TRIP_PASSIVE:
> if (temp >= trip_temp || tz->passive)
> thermal_zone_device_passive(tz, temp,
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 796f1ff..8df901f 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -42,6 +42,7 @@ enum thermal_trip_type {
> THERMAL_TRIP_PASSIVE,
> THERMAL_TRIP_HOT,
> THERMAL_TRIP_CRITICAL,
> + THERMAL_TRIP_STATE_ACTIVE,
> };
>
> struct thermal_zone_device_ops {
> --
> 1.7.1
^ permalink raw reply
* Re: [linux-pm] [PATCH 0/4] thermal: Adding generic cpu cooling devices
From: Eduardo Valentin @ 2012-02-22 15:45 UTC (permalink / raw)
To: Amit Daniel Kachhap
Cc: linux-pm, linaro-dev, patches, linux-kernel, linux-acpi, rob.lee
In-Reply-To: <1329905650-30161-1-git-send-email-amit.kachhap@linaro.org>
Hello Amit,
Thanks for keeping this up.
On Wed, Feb 22, 2012 at 03:44:06PM +0530, Amit Daniel Kachhap wrote:
> Changes since RFC:
> *Changed the cpu cooling registration/unregistration API's to instance based
> *Changed the STATE_ACTIVE trip type to pass correct instance id
> *Adding support to restore back the policy->max_freq after doing frequency
> clipping.
Have checked if this does not overlap with what the user set's as max_freq?
Not sure if we have governors that set max_freq as well. Anyways, looks like
just saving the current max and restoring it may lead to overlaps. I didn't check though.
> *Moved the trip cooling stats from sysfs node to debugfs node as suggested
> by Greg KH greg@kroah.com
> *Incorporated several review comments from eduardo.valentin@ti.com
>
> Todo:
> *Report time spent in each trip point along with the cooling statistics
> *Add opp library support in cpufreq cooling api's
>
> Brief Description:
>
> 1) The generic cooling devices code is placed inside driver/thermal/* as
> placing inside acpi folder will need un-necessary enabling of acpi code.
>
> 2) This patchset adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes
> cooling device instance number and may be helpful for cpufreq cooling devices
> to take the correct cooling action.
As already said on your previous series, the naming is not good. Problem
is that it may confuse people who have ACPI nomenclature in mind. Active,
on those terms, is related to cooling devices that consumes more power,
like activating fans.
>
> 3) This patchset adds generic cpu cooling low level implementation through
> frequency clipping and cpu hotplug. In future, other cpu related cooling
> devices may be added here. An ACPI version of this already exists
> (drivers/acpi/processor_thermal.c). But this will be useful for platforms
> like ARM using the generic thermal interface along with the generic cpu
> cooling devices. The cooling device registration API's return cooling device
> pointers which can be easily binded with the thermal zone trip points.
Yeah, but here I have to agree with Matthew Garrett's comment on your previous
version. If it is supposed to be generic, then it has to couple of ACPI as well,
otherwise it is generic for non-ACPI right? :-)
One suggestion is to think on how we could make the passive trip type more generic,
so that it could fit any policy there, either ACPI based or non-ACPI.
Talking about policy, I also think that having one specific policy on a generic
cooling strategy is maybe not a good way to go. The percentages stepping is
one proposal, but some other system may want to put its own way of cooling
using the available opps. That comes again back to the point that we probably
want something more generalized there in the generic code.
For instance, while updating the zone, you could have a generic callback
operation which would dictate the relation between trip with passive cooling state.
Then, ACPI would then define how it wants this relation to be. Then you could propose the
percentage based approach, but other people could also have its own way of correlation
or how the zone has to be updated while doing passive cooling.
Another thing is that you may want to include some examples on your documentation.
Examples of system setup with trips, temps, percentages and behavior.
>
> 4)This patchset provides a simple way of reporting cooling achieved in a
> trip type. This will help in fine cooling the cooling devices attached.
>
> Amit Daniel Kachhap (4):
> thermal: Add a new trip type to use cooling device instance number
> thermal: Add generic cpufreq cooling implementation
> thermal: Add generic cpuhotplug cooling implementation
> thermal: Add support to report cooling statistics achieved by cooling
> devices
>
> Documentation/thermal/cpu-cooling-api.txt | 57 ++++
> Documentation/thermal/sysfs-api.txt | 4 +-
> drivers/thermal/Kconfig | 11 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/cpu_cooling.c | 484 +++++++++++++++++++++++++++++
> drivers/thermal/thermal_sys.c | 165 ++++++++++-
> include/linux/cpu_cooling.h | 71 +++++
> include/linux/thermal.h | 14 +
> 8 files changed, 802 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/thermal/cpu-cooling-api.txt
> create mode 100644 drivers/thermal/cpu_cooling.c
> create mode 100644 include/linux/cpu_cooling.h
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* Re: [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
From: Peter Meerwald @ 2012-02-22 10:58 UTC (permalink / raw)
To: Amit Daniel Kachhap
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
patches-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lenb-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1329905650-30161-3-git-send-email-amit.kachhap-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi, only textual nitpicking below...
> user and the binding of these cooling devices to the corresponding
> trip points can be easily done as the registration API's return the
> cooling device pointer. The user of these api's are responsible for
API vs. api
use plural s: APIs
> + This interface function registers the cpufreq cooling device with the name
> + "thermal-cpufreq-%x". This api can support multiple instance of cpufreq cooling
> + devices.
instances
> + .freq_clip_pctg: Percentage of frequency to be clipped for each allowed
> + cpus.
cpu
> + tab_size: the total number of cooling state.
states
p.
--
Peter Meerwald
+43-664-2444418 (mobile)
^ permalink raw reply
* [PATCH 4/4] thermal: Add support to report cooling statistics achieved by cooling devices
From: Amit Daniel Kachhap @ 2012-02-22 10:14 UTC (permalink / raw)
To: linux-pm; +Cc: linaro-dev, patches, linux-kernel, linux-acpi, rob.lee
In-Reply-To: <1329905650-30161-1-git-send-email-amit.kachhap@linaro.org>
Add a debugfs node code to report effective cooling of all cooling devices
attached to each trip points of a thermal zone. The cooling data reported
will be absolute if the higher temperature trip points are arranged first
otherwise the cooling stats is the cumulative effect of the earlier
invoked cooling handlers.
The basic assumption is that cooling devices will bring down the temperature
in a symmetric manner and those statistics can be stored back and used for
further tuning of the system.
e.g.
cat /sys/kernel/debug/thermal/thermal_zone0/trip_0_cooling
6000
Here trip_0 cooling devices produce 6 degree Celsius temperature drop.
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
---
drivers/thermal/thermal_sys.c | 120 +++++++++++++++++++++++++++++++++++++++++
include/linux/thermal.h | 13 +++++
2 files changed, 133 insertions(+), 0 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index d4c9b20..9784551 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -34,6 +34,7 @@
#include <linux/reboot.h>
#include <net/netlink.h>
#include <net/genetlink.h>
+#include <linux/debugfs.h>
MODULE_AUTHOR("Zhang Rui");
MODULE_DESCRIPTION("Generic thermal management sysfs support");
@@ -93,6 +94,97 @@ static void release_idr(struct idr *idr, struct mutex *lock, int id)
mutex_unlock(lock);
}
+static void update_cooling_stats(struct thermal_zone_device *tz, long cur_temp)
+{
+ int count, max_index, cur_interval, used_data = 0;
+ long trip_temp, max_temp = 0, cool_temp;
+
+ if (cur_temp >= tz->last_temperature)
+ return;
+
+ /* find the trip according to last temperature */
+ for (count = 0; count < tz->trips; count++) {
+ tz->ops->get_trip_temp(tz, count, &trip_temp);
+ if (tz->last_temperature >= trip_temp) {
+ if (max_temp < trip_temp) {
+ max_temp = trip_temp;
+ max_index = count;
+ }
+ }
+ }
+
+ if (!max_temp) {
+ tz->last_trip_level = -1;
+ return;
+ }
+
+ cur_interval = tz->stat[max_index].interval_ptr;
+ cool_temp = tz->last_temperature - cur_temp;
+
+ if (tz->last_trip_level != max_index) {
+ if (++cur_interval == INTERVAL_HISTORY)
+ cur_interval = 0;
+ tz->stat[max_index].cool_temp[cur_interval] = cool_temp;
+ tz->stat[max_index].interval_ptr = cur_interval;
+ tz->last_trip_level = max_index;
+ } else {
+ tz->stat[max_index].cool_temp[cur_interval] += cool_temp;
+ }
+
+ /*Average out the cooling for this trip level*/
+ for (count = 0; count < INTERVAL_HISTORY; count++) {
+ if (tz->stat[max_index].cool_temp[count] > 0) {
+ tz->stat[max_index].avg_cool +=
+ tz->stat[max_index].cool_temp[count];
+ used_data++;
+ }
+ }
+ if (used_data > 1)
+ tz->stat[max_index].avg_cool =
+ tz->stat[max_index].avg_cool / used_data;
+ return;
+}
+
+#if defined(CONFIG_DEBUG_FS)
+/* debugfs support to debug cooling info per trip type */
+static struct dentry *thermal_debugfs_root;
+static int thermal_register_debugfs(struct thermal_zone_device *tz)
+{
+ char name[THERMAL_NAME_LENGTH];
+ int count = 0, err = 0;
+ struct dentry *d;
+
+ if (thermal_debugfs_root == NULL)
+ return -EINVAL;
+
+ sprintf(name, "thermal_zone%d", tz->id);
+ d = debugfs_create_dir(name, thermal_debugfs_root);
+ if (!d)
+ return -ENOMEM;
+ tz->d_entry = d;
+ for (count = 0; count < tz->trips; count++) {
+ sprintf(name, "trip_%d_cooling", count);
+ d = debugfs_create_u32(name, S_IRUGO, tz->d_entry,
+ (u32 *)&tz->stat[count].avg_cool);
+ if (!d) {
+ err = -ENOMEM;
+ goto err_debugfs;
+ }
+ }
+ return 0;
+
+err_debugfs:
+ debugfs_remove_recursive(tz->d_entry);
+ return err;
+}
+
+static void thermal_unregister_debugfs(struct thermal_zone_device *tz)
+{
+ debugfs_remove_recursive(tz->d_entry);
+}
+
+#endif
+
/* sys I/F for thermal zone */
#define to_thermal_zone(_dev) \
@@ -1051,6 +1143,8 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
goto leave;
}
+ update_cooling_stats(tz, temp);
+
for (count = 0; count < tz->trips; count++) {
tz->ops->get_trip_type(tz, count, &trip_type);
tz->ops->get_trip_temp(tz, count, &trip_temp);
@@ -1211,6 +1305,7 @@ struct thermal_zone_device *thermal_zone_device_register(char *type,
tz->tc2 = tc2;
tz->passive_delay = passive_delay;
tz->polling_delay = polling_delay;
+ tz->last_trip_level = -1;
dev_set_name(&tz->device, "thermal_zone%d", tz->id);
result = device_register(&tz->device);
@@ -1220,6 +1315,13 @@ struct thermal_zone_device *thermal_zone_device_register(char *type,
return ERR_PTR(result);
}
+ /*Allocate variables for cooling stats*/
+ tz->stat = devm_kzalloc(&tz->device,
+ sizeof(struct thermal_cooling_stats) * trips,
+ GFP_KERNEL);
+ if (!tz->stat)
+ goto unregister;
+
/* sys I/F */
if (type) {
result = device_create_file(&tz->device, &dev_attr_type);
@@ -1257,6 +1359,12 @@ struct thermal_zone_device *thermal_zone_device_register(char *type,
if (result)
goto unregister;
+#if defined(CONFIG_DEBUG_FS)
+ result = thermal_register_debugfs(tz);
+ if (result)
+ goto unregister;
+#endif
+
mutex_lock(&thermal_list_lock);
list_add_tail(&tz->node, &thermal_tz_list);
if (ops->bind)
@@ -1321,6 +1429,10 @@ void thermal_zone_device_unregister(struct thermal_zone_device *tz)
for (count = 0; count < tz->trips; count++)
TRIP_POINT_ATTR_REMOVE(&tz->device, count);
+#if defined(CONFIG_DEBUG_FS)
+ thermal_unregister_debugfs(tz);
+#endif
+
thermal_remove_hwmon_sysfs(tz);
release_idr(&thermal_tz_idr, &thermal_idr_lock, tz->id);
idr_destroy(&tz->idr);
@@ -1440,6 +1552,11 @@ static int __init thermal_init(void)
mutex_destroy(&thermal_list_lock);
}
result = genetlink_init();
+#if defined(CONFIG_DEBUG_FS)
+ thermal_debugfs_root = debugfs_create_dir("thermal", NULL);
+ if (!thermal_debugfs_root)
+ result = -ENOMEM;
+#endif
return result;
}
@@ -1451,6 +1568,9 @@ static void __exit thermal_exit(void)
mutex_destroy(&thermal_idr_lock);
mutex_destroy(&thermal_list_lock);
genetlink_exit();
+#if defined(CONFIG_DEBUG_FS)
+ debugfs_remove_recursive(thermal_debugfs_root);
+#endif
}
fs_initcall(thermal_init);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 8df901f..6f15f85 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -73,6 +73,14 @@ struct thermal_cooling_device_ops {
#define THERMAL_TRIPS_NONE -1
#define THERMAL_MAX_TRIPS 12
#define THERMAL_NAME_LENGTH 20
+#define INTERVAL_HISTORY 12
+
+struct thermal_cooling_stats {
+ int cool_temp[INTERVAL_HISTORY];
+ int interval_ptr;
+ int avg_cool;
+};
+
struct thermal_cooling_device {
int id;
char type[THERMAL_NAME_LENGTH];
@@ -103,6 +111,11 @@ struct thermal_zone_device {
struct list_head cooling_devices;
struct idr idr;
struct mutex lock; /* protect cooling devices list */
+ struct thermal_cooling_stats *stat;
+ int last_trip_level;
+#if defined(CONFIG_DEBUG_FS)
+ struct dentry *d_entry;
+#endif
struct list_head node;
struct delayed_work poll_queue;
};
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] thermal: Add generic cpuhotplug cooling implementation
From: Amit Daniel Kachhap @ 2012-02-22 10:14 UTC (permalink / raw)
To: linux-pm; +Cc: linaro-dev, patches, linux-kernel, linux-acpi, rob.lee
In-Reply-To: <1329905650-30161-1-git-send-email-amit.kachhap@linaro.org>
This patch adds support for generic cpu thermal cooling low level
implementations using cpuhotplug based on the thermal level requested
from user. Different cpu related cooling devices can be registered by the
user and the binding of these cooling devices to the corresponding
trip points can be easily done as the registration API's return the
cooling device pointer. The user of these api's are responsible for
passing the cpumask.
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
---
Documentation/thermal/cpu-cooling-api.txt | 17 +++
drivers/thermal/cpu_cooling.c | 174 +++++++++++++++++++++++++++++
include/linux/cpu_cooling.h | 17 +++
3 files changed, 208 insertions(+), 0 deletions(-)
diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt
index 04de67c..bdaf509 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -38,3 +38,20 @@ the cooling device pointer.
This interface function unregisters the "thermal-cpufreq-%x" cooling device.
cdev: Cooling device pointer which has to be unregistered.
+
+1.2 cpuhotplug registration api's
+
+1.2.1 struct thermal_cooling_device *cpuhotplug_cooling_register(
+ const struct cpumask *mask_val)
+
+ This interface function registers the cpuhotplug cooling device with the name
+ "cpu-hotplug-%x". This api can support multiple instance of cpuhotplug cooling
+ devices.
+
+ mask_val: all the allowed cpu's which can be hotplugged out.
+
+1.1.2 void cpuhotplug_cooling_unregister(struct thermal_cooling_device *cdev)
+
+ This interface function unregisters the "thermal-cpuhotplug-%x" cooling device.
+
+ cdev: Cooling device pointer which has to be unregistered.
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 298f550..3d2d87f 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -48,6 +48,21 @@ static struct cpufreq_cooling_device *notify_cpufreq;
static DEFINE_PER_CPU(unsigned int, max_policy_freq);
#endif /*CONFIG_CPU_FREQ*/
+#ifdef CONFIG_HOTPLUG_CPU
+struct hotplug_cooling_device {
+ int id;
+ struct thermal_cooling_device *cool_dev;
+ unsigned int hotplug_state;
+ const struct cpumask *allowed_cpus;
+ struct list_head node;
+};
+
+static LIST_HEAD(cooling_cpuhotplug_list);
+static DEFINE_MUTEX(cooling_cpuhotplug_lock);
+static DEFINE_IDR(cpuhotplug_idr);
+#endif /*CONFIG_HOTPLUG_CPU*/
+
+
static int get_idr(struct idr *idr, struct mutex *lock, int *id)
{
int err;
@@ -308,3 +323,162 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
}
EXPORT_SYMBOL(cpufreq_cooling_unregister);
#endif /*CONFIG_CPU_FREQ*/
+
+#ifdef CONFIG_HOTPLUG_CPU
+/*
+ * cpu hotplug cooling device callback functions
+ */
+static int cpuhotplug_get_max_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct hotplug_cooling_device *hotplug_dev = NULL;
+
+ mutex_lock(&cooling_cpuhotplug_lock);
+ list_for_each_entry(hotplug_dev, &cooling_cpuhotplug_list, node)
+ if (hotplug_dev && hotplug_dev->cool_dev == cdev)
+ break;
+
+ mutex_unlock(&cooling_cpuhotplug_lock);
+ if (!hotplug_dev || hotplug_dev->cool_dev != cdev)
+ return -EINVAL;
+
+ *state = 1;
+ return 0;
+}
+
+static int cpuhotplug_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct hotplug_cooling_device *hotplug_dev = NULL;
+
+ mutex_lock(&cooling_cpuhotplug_lock);
+ list_for_each_entry(hotplug_dev, &cooling_cpuhotplug_list, node)
+ if (hotplug_dev && hotplug_dev->cool_dev == cdev)
+ break;
+
+ mutex_unlock(&cooling_cpuhotplug_lock);
+ if (!hotplug_dev || hotplug_dev->cool_dev != cdev)
+ return -EINVAL;
+
+ /*
+ * This cooling device may be of type ACTIVE, so state field can
+ * be 0 or 1
+ */
+ *state = hotplug_dev->hotplug_state;
+ return 0;
+}
+
+/*This cooling may be as ACTIVE type*/
+static int cpuhotplug_set_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long state)
+{
+ int cpuid, this_cpu = smp_processor_id();
+ struct hotplug_cooling_device *hotplug_dev = NULL;
+
+ mutex_lock(&cooling_cpuhotplug_lock);
+ list_for_each_entry(hotplug_dev, &cooling_cpuhotplug_list, node)
+ if (hotplug_dev && hotplug_dev->cool_dev == cdev)
+ break;
+
+ mutex_unlock(&cooling_cpuhotplug_lock);
+ if (!hotplug_dev || hotplug_dev->cool_dev != cdev)
+ return -EINVAL;
+
+ if (hotplug_dev->hotplug_state == state)
+ return 0;
+
+ /*
+ * This cooling device may be of type ACTIVE, so state field can
+ * be 0 or 1
+ */
+ if (state == 1) {
+ for_each_cpu(cpuid, hotplug_dev->allowed_cpus) {
+ if (cpu_online(cpuid) && (cpuid != this_cpu))
+ cpu_down(cpuid);
+ }
+ } else if (state == 0) {
+ for_each_cpu(cpuid, hotplug_dev->allowed_cpus) {
+ if (!cpu_online(cpuid) && (cpuid != this_cpu))
+ cpu_up(cpuid);
+ }
+ } else {
+ return -EINVAL;
+ }
+
+ hotplug_dev->hotplug_state = state;
+
+ return 0;
+}
+/* bind hotplug callbacks to cpu hotplug cooling device */
+static struct thermal_cooling_device_ops cpuhotplug_cooling_ops = {
+ .get_max_state = cpuhotplug_get_max_state,
+ .get_cur_state = cpuhotplug_get_cur_state,
+ .set_cur_state = cpuhotplug_set_cur_state,
+};
+
+struct thermal_cooling_device *cpuhotplug_cooling_register(
+ const struct cpumask *mask_val)
+{
+ struct thermal_cooling_device *cool_dev;
+ struct hotplug_cooling_device *hotplug_dev;
+ int ret = 0;
+ char dev_name[THERMAL_NAME_LENGTH];
+
+ hotplug_dev =
+ kzalloc(sizeof(struct hotplug_cooling_device), GFP_KERNEL);
+
+ if (!hotplug_dev)
+ return ERR_PTR(-ENOMEM);
+
+ ret = get_idr(&cpuhotplug_idr, &cooling_cpuhotplug_lock,
+ &hotplug_dev->id);
+ if (ret) {
+ kfree(hotplug_dev);
+ return ERR_PTR(-EINVAL);
+ }
+
+ sprintf(dev_name, "cpu-hotplug-%u", hotplug_dev->id);
+
+ hotplug_dev->hotplug_state = 0;
+ hotplug_dev->allowed_cpus = mask_val;
+ cool_dev = thermal_cooling_device_register(dev_name, hotplug_dev,
+ &cpuhotplug_cooling_ops);
+ if (!cool_dev) {
+ release_idr(&cpuhotplug_idr, &cooling_cpuhotplug_lock,
+ hotplug_dev->id);
+ kfree(hotplug_dev);
+ return ERR_PTR(-EINVAL);
+ }
+
+ hotplug_dev->cool_dev = cool_dev;
+ mutex_lock(&cooling_cpuhotplug_lock);
+ list_add_tail(&hotplug_dev->node, &cooling_cpuhotplug_list);
+ mutex_unlock(&cooling_cpuhotplug_lock);
+
+ return cool_dev;
+}
+EXPORT_SYMBOL(cpuhotplug_cooling_register);
+
+void cpuhotplug_cooling_unregister(struct thermal_cooling_device *cdev)
+{
+ struct hotplug_cooling_device *hotplug_dev = NULL;
+
+ mutex_lock(&cooling_cpuhotplug_lock);
+ list_for_each_entry(hotplug_dev, &cooling_cpuhotplug_list, node)
+ if (hotplug_dev && hotplug_dev->cool_dev == cdev)
+ break;
+
+ if (!hotplug_dev || hotplug_dev->cool_dev != cdev) {
+ mutex_unlock(&cooling_cpuhotplug_lock);
+ return;
+ }
+
+ list_del(&hotplug_dev->node);
+ mutex_unlock(&cooling_cpuhotplug_lock);
+ thermal_cooling_device_unregister(hotplug_dev->cool_dev);
+ release_idr(&cpuhotplug_idr, &cooling_cpuhotplug_lock,
+ hotplug_dev->id);
+ kfree(hotplug_dev);
+}
+EXPORT_SYMBOL(cpuhotplug_cooling_unregister);
+#endif /*CONFIG_HOTPLUG_CPU*/
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index 5dc5632..8d195d5 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -50,5 +50,22 @@ static inline void cpufreq_cooling_unregister(
return;
}
#endif /*CONFIG_CPU_FREQ*/
+#ifdef CONFIG_HOTPLUG_CPU
+extern struct thermal_cooling_device *cpuhotplug_cooling_register(
+ const struct cpumask *mask_val);
+
+extern void cpuhotplug_cooling_unregister(struct thermal_cooling_device *cdev);
+#else /*!CONFIG_HOTPLUG_CPU*/
+static inline struct thermal_cooling_device *cpuhotplug_cooling_register(
+ const struct cpumask *mask_val)
+{
+ return NULL;
+}
+static inline void cpuhotplug_cooling_unregister(
+ struct thermal_cooling_device *cdev)
+{
+ return;
+}
+#endif /*CONFIG_HOTPLUG_CPU*/
#endif /* __CPU_COOLING_H__ */
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
From: Amit Daniel Kachhap @ 2012-02-22 10:14 UTC (permalink / raw)
To: linux-pm; +Cc: linaro-dev, patches, linux-kernel, linux-acpi, rob.lee
In-Reply-To: <1329905650-30161-1-git-send-email-amit.kachhap@linaro.org>
This patch adds support for generic cpu thermal cooling low level
implementations using frequency scaling up/down based on the request
from user. Different cpu related cooling devices can be registered by the
user and the binding of these cooling devices to the corresponding
trip points can be easily done as the registration API's return the
cooling device pointer. The user of these api's are responsible for
passing clipping frequency in percentages.
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
---
Documentation/thermal/cpu-cooling-api.txt | 40 ++++
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile | 1 +
drivers/thermal/cpu_cooling.c | 310 +++++++++++++++++++++++++++++
include/linux/cpu_cooling.h | 54 +++++
5 files changed, 416 insertions(+), 0 deletions(-)
create mode 100644 Documentation/thermal/cpu-cooling-api.txt
create mode 100644 drivers/thermal/cpu_cooling.c
create mode 100644 include/linux/cpu_cooling.h
diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt
new file mode 100644
index 0000000..04de67c
--- /dev/null
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -0,0 +1,40 @@
+CPU cooling api's How To
+===================================
+
+Written by Amit Daniel Kachhap <amit.kachhap@linaro.org>
+
+Updated: 13 Dec 2011
+
+Copyright (c) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com)
+
+0. Introduction
+
+The generic cpu cooling(freq clipping, cpuhotplug) provides
+registration/unregistration api's to the user. The binding of the cooling
+devices to the trip point is left for the user. The registration api's returns
+the cooling device pointer.
+
+1. cpufreq cooling api's
+
+1.1 cpufreq registration api's
+1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
+ struct freq_pctg_table *tab_ptr, unsigned int tab_size,
+ const struct cpumask *mask_val)
+
+ This interface function registers the cpufreq cooling device with the name
+ "thermal-cpufreq-%x". This api can support multiple instance of cpufreq cooling
+ devices.
+
+ tab_ptr: The table containing the percentage of frequency to be clipped for
+ each cooling state.
+ .freq_clip_pctg: Percentage of frequency to be clipped for each allowed
+ cpus.
+ .polling_interval: polling interval for this cooling state.
+ tab_size: the total number of cooling state.
+ mask_val: all the allowed cpu's where frequency clipping can happen.
+
+1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+
+ This interface function unregisters the "thermal-cpufreq-%x" cooling device.
+
+ cdev: Cooling device pointer which has to be unregistered.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f7f71b2..298c1cd 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -18,3 +18,14 @@ config THERMAL_HWMON
depends on THERMAL
depends on HWMON=y || HWMON=THERMAL
default y
+
+config CPU_THERMAL
+ bool "generic cpu cooling support"
+ depends on THERMAL
+ help
+ This implements the generic cpu cooling mechanism through frequency
+ reduction, cpu hotplug and any other ways of reducing temperature. An
+ ACPI version of this already exists(drivers/acpi/processor_thermal.c).
+ This will be useful for platforms using the generic thermal interface
+ and not the ACPI interface.
+ If you want this support, you should say Y or M here.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 31108a0..655cbc4 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_THERMAL) += thermal_sys.o
+obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
new file mode 100644
index 0000000..298f550
--- /dev/null
+++ b/drivers/thermal/cpu_cooling.c
@@ -0,0 +1,310 @@
+/*
+ * linux/drivers/thermal/cpu_cooling.c
+ *
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com)
+ * Copyright (C) 2011 Amit Daniel <amit.kachhap@linaro.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/thermal.h>
+#include <linux/platform_device.h>
+#include <linux/cpufreq.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/cpu.h>
+#include <linux/cpu_cooling.h>
+
+#ifdef CONFIG_CPU_FREQ
+struct cpufreq_cooling_device {
+ int id;
+ struct thermal_cooling_device *cool_dev;
+ struct freq_pctg_table *tab_ptr;
+ unsigned int tab_size;
+ unsigned int cpufreq_state;
+ const struct cpumask *allowed_cpus;
+ struct list_head node;
+};
+
+static LIST_HEAD(cooling_cpufreq_list);
+static DEFINE_MUTEX(cooling_cpufreq_lock);
+static DEFINE_IDR(cpufreq_idr);
+static struct cpufreq_cooling_device *notify_cpufreq;
+static DEFINE_PER_CPU(unsigned int, max_policy_freq);
+#endif /*CONFIG_CPU_FREQ*/
+
+static int get_idr(struct idr *idr, struct mutex *lock, int *id)
+{
+ int err;
+again:
+ if (unlikely(idr_pre_get(idr, GFP_KERNEL) == 0))
+ return -ENOMEM;
+
+ if (lock)
+ mutex_lock(lock);
+ err = idr_get_new(idr, NULL, id);
+ if (lock)
+ mutex_unlock(lock);
+ if (unlikely(err == -EAGAIN))
+ goto again;
+ else if (unlikely(err))
+ return err;
+
+ *id = *id & MAX_ID_MASK;
+ return 0;
+}
+
+static void release_idr(struct idr *idr, struct mutex *lock, int id)
+{
+ if (lock)
+ mutex_lock(lock);
+ idr_remove(idr, id);
+ if (lock)
+ mutex_unlock(lock);
+}
+
+#ifdef CONFIG_CPU_FREQ
+/*Below codes defines functions to be used for cpufreq as cooling device*/
+static bool is_cpufreq_valid(int cpu)
+{
+ struct cpufreq_policy policy;
+ if (!cpufreq_get_policy(&policy, cpu))
+ return true;
+ return false;
+}
+
+static int cpufreq_apply_cooling(struct cpufreq_cooling_device *cpufreq_device,
+ unsigned long cooling_state)
+{
+ int cpuid, this_cpu = smp_processor_id();
+
+ if (!is_cpufreq_valid(this_cpu))
+ return 0;
+
+ if (cooling_state > cpufreq_device->tab_size)
+ return -EINVAL;
+
+ /*Check if last cooling level is same as current cooling level*/
+ if (cpufreq_device->cpufreq_state == cooling_state)
+ return 0;
+
+ cpufreq_device->cpufreq_state = cooling_state;
+
+ /*cpufreq thermal notifier uses this cpufreq device pointer*/
+ notify_cpufreq = cpufreq_device;
+
+ for_each_cpu(cpuid, cpufreq_device->allowed_cpus) {
+ if (is_cpufreq_valid(cpuid))
+ cpufreq_update_policy(cpuid);
+ }
+
+ return 0;
+}
+
+static int thermal_cpufreq_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct cpufreq_policy *policy = data;
+ struct freq_pctg_table *th_table;
+ unsigned long max_freq = 0;
+ unsigned int th_pctg = 0, level;
+
+ if (event != CPUFREQ_ADJUST)
+ return 0;
+
+ if (!notify_cpufreq)
+ return 0;
+
+ level = notify_cpufreq->cpufreq_state;
+
+ if (level > 0) {
+ th_table =
+ &(notify_cpufreq->tab_ptr[level - 1]);
+ th_pctg = th_table->freq_clip_pctg;
+ max_freq =
+ (policy->cpuinfo.max_freq * (100 - th_pctg)) / 100;
+
+ if (per_cpu(max_policy_freq, policy->cpu) == 0)
+ per_cpu(max_policy_freq, policy->cpu) = policy->max;
+ } else {
+ if (per_cpu(max_policy_freq, policy->cpu) != 0) {
+ max_freq = per_cpu(max_policy_freq, policy->cpu);
+ per_cpu(max_policy_freq, policy->cpu) = 0;
+ } else {
+ max_freq = policy->max;
+ }
+ }
+
+ cpufreq_verify_within_limits(policy, 0, max_freq);
+
+ return 0;
+}
+
+/*
+ * cpufreq cooling device callback functions
+ */
+static int cpufreq_get_max_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct cpufreq_cooling_device *cpufreq_device = NULL;
+
+ mutex_lock(&cooling_cpufreq_lock);
+ list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node)
+ if (cpufreq_device && cpufreq_device->cool_dev == cdev)
+ break;
+
+ mutex_unlock(&cooling_cpufreq_lock);
+ if (!cpufreq_device || cpufreq_device->cool_dev != cdev)
+ return -EINVAL;
+
+ *state = cpufreq_device->tab_size;
+ return 0;
+}
+
+static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct cpufreq_cooling_device *cpufreq_device = NULL;
+
+ mutex_lock(&cooling_cpufreq_lock);
+ list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node)
+ if (cpufreq_device && cpufreq_device->cool_dev == cdev)
+ break;
+
+ mutex_unlock(&cooling_cpufreq_lock);
+ if (!cpufreq_device || cpufreq_device->cool_dev != cdev)
+ return -EINVAL;
+ *state = cpufreq_device->cpufreq_state;
+ return 0;
+}
+
+/*This cooling may be as PASSIVE/ACTIVE type*/
+static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long state)
+{
+ struct cpufreq_cooling_device *cpufreq_device = NULL;
+
+ mutex_lock(&cooling_cpufreq_lock);
+ list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node)
+ if (cpufreq_device && cpufreq_device->cool_dev == cdev)
+ break;
+
+ mutex_unlock(&cooling_cpufreq_lock);
+ if (!cpufreq_device || cpufreq_device->cool_dev != cdev)
+ return -EINVAL;
+
+ cpufreq_apply_cooling(cpufreq_device, state);
+ return 0;
+}
+
+/* bind cpufreq callbacks to cpufreq cooling device */
+static struct thermal_cooling_device_ops cpufreq_cooling_ops = {
+ .get_max_state = cpufreq_get_max_state,
+ .get_cur_state = cpufreq_get_cur_state,
+ .set_cur_state = cpufreq_set_cur_state,
+};
+
+static struct notifier_block thermal_cpufreq_notifier_block = {
+ .notifier_call = thermal_cpufreq_notifier,
+};
+
+struct thermal_cooling_device *cpufreq_cooling_register(
+ struct freq_pctg_table *tab_ptr, unsigned int tab_size,
+ const struct cpumask *mask_val)
+{
+ struct thermal_cooling_device *cool_dev;
+ struct cpufreq_cooling_device *cpufreq_dev = NULL;
+ unsigned int count = 0;
+ char dev_name[THERMAL_NAME_LENGTH];
+ int ret = 0, id = 0;
+
+ if (tab_ptr == NULL || tab_size == 0)
+ return ERR_PTR(-EINVAL);
+
+ list_for_each_entry(cpufreq_dev, &cooling_cpufreq_list, node)
+ count++;
+
+ cpufreq_dev =
+ kzalloc(sizeof(struct cpufreq_cooling_device), GFP_KERNEL);
+
+ if (!cpufreq_dev)
+ return ERR_PTR(-ENOMEM);
+
+ cpufreq_dev->tab_ptr = tab_ptr;
+ cpufreq_dev->tab_size = tab_size;
+ cpufreq_dev->allowed_cpus = mask_val;
+
+ ret = get_idr(&cpufreq_idr, &cooling_cpufreq_lock, &cpufreq_dev->id);
+ if (ret) {
+ kfree(cpufreq_dev);
+ return ERR_PTR(-EINVAL);
+ }
+
+ sprintf(dev_name, "thermal-cpufreq-%d", cpufreq_dev->id);
+
+ cool_dev = thermal_cooling_device_register(dev_name, cpufreq_dev,
+ &cpufreq_cooling_ops);
+ if (!cool_dev) {
+ release_idr(&cpufreq_idr, &cooling_cpufreq_lock,
+ cpufreq_dev->id);
+ kfree(cpufreq_dev);
+ return ERR_PTR(-EINVAL);
+ }
+ cpufreq_dev->id = id;
+ cpufreq_dev->cool_dev = cool_dev;
+ mutex_lock(&cooling_cpufreq_lock);
+ list_add_tail(&cpufreq_dev->node, &cooling_cpufreq_list);
+ mutex_unlock(&cooling_cpufreq_lock);
+
+ if (count == 0)
+ cpufreq_register_notifier(&thermal_cpufreq_notifier_block,
+ CPUFREQ_POLICY_NOTIFIER);
+ return cool_dev;
+}
+EXPORT_SYMBOL(cpufreq_cooling_register);
+
+void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+{
+ struct cpufreq_cooling_device *cpufreq_dev = NULL;
+ unsigned int count = 0;
+
+ mutex_lock(&cooling_cpufreq_lock);
+ list_for_each_entry(cpufreq_dev, &cooling_cpufreq_list, node) {
+ if (cpufreq_dev && cpufreq_dev->cool_dev == cdev)
+ break;
+ count++;
+ }
+
+ if (!cpufreq_dev || cpufreq_dev->cool_dev != cdev) {
+ mutex_unlock(&cooling_cpufreq_lock);
+ return;
+ }
+
+ list_del(&cpufreq_dev->node);
+ mutex_unlock(&cooling_cpufreq_lock);
+
+ if (count == 1)
+ cpufreq_unregister_notifier(&thermal_cpufreq_notifier_block,
+ CPUFREQ_POLICY_NOTIFIER);
+
+ thermal_cooling_device_unregister(cpufreq_dev->cool_dev);
+ release_idr(&cpufreq_idr, &cooling_cpufreq_lock, cpufreq_dev->id);
+ kfree(cpufreq_dev);
+}
+EXPORT_SYMBOL(cpufreq_cooling_unregister);
+#endif /*CONFIG_CPU_FREQ*/
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
new file mode 100644
index 0000000..5dc5632
--- /dev/null
+++ b/include/linux/cpu_cooling.h
@@ -0,0 +1,54 @@
+/*
+ * linux/include/linux/cpu_cooling.h
+ *
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com)
+ * Copyright (C) 2011 Amit Daniel <amit.kachhap@linaro.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#ifndef __CPU_COOLING_H__
+#define __CPU_COOLING_H__
+
+#include <linux/thermal.h>
+
+struct freq_pctg_table {
+ unsigned int freq_clip_pctg;
+ unsigned int polling_interval;
+};
+
+#ifdef CONFIG_CPU_FREQ
+struct thermal_cooling_device *cpufreq_cooling_register(
+ struct freq_pctg_table *tab_ptr, unsigned int tab_size,
+ const struct cpumask *mask_val);
+
+void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev);
+#else /*!CONFIG_CPU_FREQ*/
+static inline struct thermal_cooling_device *cpufreq_cooling_register(
+ struct freq_pctg_table *tab_ptr, unsigned int tab_size,
+ const struct cpumask *mask_val)
+{
+ return NULL;
+}
+static inline void cpufreq_cooling_unregister(
+ struct thermal_cooling_device *cdev)
+{
+ return;
+}
+#endif /*CONFIG_CPU_FREQ*/
+
+#endif /* __CPU_COOLING_H__ */
--
1.7.1
^ permalink raw reply related
* [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number
From: Amit Daniel Kachhap @ 2012-02-22 10:14 UTC (permalink / raw)
To: linux-pm; +Cc: linaro-dev, patches, linux-kernel, linux-acpi, rob.lee
In-Reply-To: <1329905650-30161-1-git-send-email-amit.kachhap@linaro.org>
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.
Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
---
Documentation/thermal/sysfs-api.txt | 4 +-
drivers/thermal/thermal_sys.c | 45 ++++++++++++++++++++++++++++++++--
include/linux/thermal.h | 1 +
3 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index 1733ab9..7a0c080 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
trip_point_[0-*]_type
Strings which indicate the type of the trip point.
- E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
- thermal zone.
+ E.g. it can be one of critical, hot, passive, active[0-1],
+ state-active[0-*] for ACPI thermal zone.
RO, Optional
cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 220ce7e..d4c9b20 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct device_attribute *attr,
return sprintf(buf, "passive\n");
case THERMAL_TRIP_ACTIVE:
return sprintf(buf, "active\n");
+ case THERMAL_TRIP_STATE_ACTIVE:
+ return sprintf(buf, "state-active\n");
default:
return sprintf(buf, "unknown\n");
}
@@ -1034,10 +1036,10 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
void thermal_zone_device_update(struct thermal_zone_device *tz)
{
- int count, ret = 0;
- long temp, trip_temp;
+ int count, ret = 0, inst_id;
+ long temp, trip_temp, max_state, last_trip_change = 0;
enum thermal_trip_type trip_type;
- struct thermal_cooling_device_instance *instance;
+ struct thermal_cooling_device_instance *instance, *state_instance;
struct thermal_cooling_device *cdev;
mutex_lock(&tz->lock);
@@ -1086,6 +1088,43 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
cdev->ops->set_cur_state(cdev, 0);
}
break;
+ case THERMAL_TRIP_STATE_ACTIVE:
+ list_for_each_entry(instance, &tz->cooling_devices,
+ node) {
+ if (instance->trip != count)
+ continue;
+
+ if (temp <= last_trip_change)
+ continue;
+
+ inst_id = 0;
+ /*
+ *For this instance how many instance of same
+ *cooling device occured before
+ */
+
+ list_for_each_entry(state_instance,
+ &tz->cooling_devices, node) {
+ if (instance->cdev ==
+ state_instance->cdev)
+ inst_id++;
+ if (state_instance->trip == count)
+ break;
+ }
+
+ cdev = instance->cdev;
+ cdev->ops->get_max_state(cdev, &max_state);
+
+ if ((temp >= trip_temp) &&
+ (inst_id <= max_state))
+ cdev->ops->set_cur_state(cdev, inst_id);
+ else if ((temp < trip_temp) &&
+ (--inst_id <= max_state))
+ cdev->ops->set_cur_state(cdev, inst_id);
+
+ last_trip_change = trip_temp;
+ }
+ break;
case THERMAL_TRIP_PASSIVE:
if (temp >= trip_temp || tz->passive)
thermal_zone_device_passive(tz, temp,
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 796f1ff..8df901f 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -42,6 +42,7 @@ enum thermal_trip_type {
THERMAL_TRIP_PASSIVE,
THERMAL_TRIP_HOT,
THERMAL_TRIP_CRITICAL,
+ THERMAL_TRIP_STATE_ACTIVE,
};
struct thermal_zone_device_ops {
--
1.7.1
^ permalink raw reply related
* [PATCH 0/4] thermal: Adding generic cpu cooling devices
From: Amit Daniel Kachhap @ 2012-02-22 10:14 UTC (permalink / raw)
To: linux-pm; +Cc: linaro-dev, patches, linux-kernel, linux-acpi, rob.lee
Changes since RFC:
*Changed the cpu cooling registration/unregistration API's to instance based
*Changed the STATE_ACTIVE trip type to pass correct instance id
*Adding support to restore back the policy->max_freq after doing frequency
clipping.
*Moved the trip cooling stats from sysfs node to debugfs node as suggested
by Greg KH greg@kroah.com
*Incorporated several review comments from eduardo.valentin@ti.com
Todo:
*Report time spent in each trip point along with the cooling statistics
*Add opp library support in cpufreq cooling api's
Brief Description:
1) The generic cooling devices code is placed inside driver/thermal/* as
placing inside acpi folder will need un-necessary enabling of acpi code.
2) This patchset adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes
cooling device instance number and may be helpful for cpufreq cooling devices
to take the correct cooling action.
3) This patchset adds generic cpu cooling low level implementation through
frequency clipping and cpu hotplug. In future, other cpu related cooling
devices may be added here. An ACPI version of this already exists
(drivers/acpi/processor_thermal.c). But this will be useful for platforms
like ARM using the generic thermal interface along with the generic cpu
cooling devices. The cooling device registration API's return cooling device
pointers which can be easily binded with the thermal zone trip points.
4)This patchset provides a simple way of reporting cooling achieved in a
trip type. This will help in fine cooling the cooling devices attached.
Amit Daniel Kachhap (4):
thermal: Add a new trip type to use cooling device instance number
thermal: Add generic cpufreq cooling implementation
thermal: Add generic cpuhotplug cooling implementation
thermal: Add support to report cooling statistics achieved by cooling
devices
Documentation/thermal/cpu-cooling-api.txt | 57 ++++
Documentation/thermal/sysfs-api.txt | 4 +-
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile | 1 +
drivers/thermal/cpu_cooling.c | 484 +++++++++++++++++++++++++++++
drivers/thermal/thermal_sys.c | 165 ++++++++++-
include/linux/cpu_cooling.h | 71 +++++
include/linux/thermal.h | 14 +
8 files changed, 802 insertions(+), 5 deletions(-)
create mode 100644 Documentation/thermal/cpu-cooling-api.txt
create mode 100644 drivers/thermal/cpu_cooling.c
create mode 100644 include/linux/cpu_cooling.h
^ permalink raw reply
* Re: [PATCH 0/2] RFC: CPU frequency max as PM QoS param
From: Antti P Miettinen @ 2012-02-20 10:00 UTC (permalink / raw)
Cc: linux-pm, cpufreq
In-Reply-To: <CAGF5oy9LC4Ve8u6UqG3EbGkWmWYVMthHatJdaRR_ZMO4UQh3CA@mail.gmail.com>
Thanks for the comments. I'd like to comment on maximum CPU frequency,
sysfs files and per device contraints..
Maximum CPU frequency could be useful for thermal. However, it is not a
complete solution for thermal. Just like minimum CPU frequency is not a
complete solution for computing throughput (e.g. memory and accelerator
control are not directly addressed by a CPU frequency
constraint). Maximum CPU frequency can be also useful for energy
efficiency even though the constraint is not a complete solution here
either. I guess latency constraints do not completely solve end-to-end
latency requirements but the mechanism is useful so it is good to have
it. I'd argue minimum and maximum frequency are simular in this respect.
There are sysfs files for constraining CPU frequency. However, there is
no arbitration for several applications trying to place constraints. PM
QoS provides a way to consolidate requests from several applications and
cleanup upon application crash. I think the existing sysfs files are not
an appropriate inferface for user space applications.
Currently CPU sleep states are blocked globally for latency
contraints. Finer granularity control would be possible with per CPU
contraints. However - are there clients that know or want to contrain a
specific CPU? Same question is applicable also to CPU frequency. Even
though per CPU control is more flexible, what are the clients that want
to constrain a specific CPU?
Another complication for the per device constraints is the user space
interface. Dynamic minors run out pretty fast if we have per CPU
parameters and the system has huge number of CPUs. Does anyone have any
opinions about the user space interface for device PM QoS?
--Antti
^ permalink raw reply
* Re: [PATCH] PM / QoS: unconditionally build the feature
From: Rafael J. Wysocki @ 2012-02-17 20:48 UTC (permalink / raw)
To: Pavel Machek
Cc: Venkatesh Pallipadi, Mark Gross, linux-kernel,
Linux PM mailing list, Jean Pihet
In-Reply-To: <20120217192724.GC2707@elf.ucw.cz>
On Friday, February 17, 2012, Pavel Machek wrote:
> On Mon 2012-02-13 16:41:10, Rafael J. Wysocki wrote:
> > On Monday, February 13, 2012, Jean Pihet wrote:
> > > The PM QoS feature depends on CONFIG_PM which depends on
> > > PM_SLEEP || PM_RUNTIME. This breaks CPU C-states with kernels
> > > not having these CONFIGs.
> > >
> > > This patch allows the feature in all cases.
> > >
> > > Signed-off-by: Jean Pihet <j-pihet@ti.com>
> > > Reported-by: Venkatesh Pallipadi <venki@google.com>
> > > Cc: Rafael J. Wysocki <rjw@sisk.pl>
> > > Cc: Mark Gross <markgross@thegnar.org>
> >
> > Applied, but I modified the changelog (please have a look at the
> > linux-pm/pm-qos branch for details).
>
> Is it good idea? For servers, power management / QoS is not
> neccessary...
Yes, it is. They surely use CPUidle.
Thanks,
Rafael
^ permalink raw reply
* Re: hiberante hangs TCP Re: [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking
From: Pavel Machek @ 2012-02-17 19:28 UTC (permalink / raw)
To: Tejun Heo; +Cc: netdev, linux-pm, linux-kernel, David Fries
In-Reply-To: <20111102151039.GA12543@dhcp-172-17-108-109.mtv.corp.google.com>
On Wed 2011-11-02 08:10:39, Tejun Heo wrote:
> 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.
Yes, that should be done.
If someone has uswsusp setup where they talk over the network, it
might break them, but hopefully noone is doing that.
Also hopefully noone does hibernation on /dev/nbd.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] PM / QoS: unconditionally build the feature
From: Pavel Machek @ 2012-02-17 19:27 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Venkatesh Pallipadi, Mark Gross, linux-kernel,
Linux PM mailing list, Jean Pihet
In-Reply-To: <201202131641.10535.rjw@sisk.pl>
On Mon 2012-02-13 16:41:10, Rafael J. Wysocki wrote:
> On Monday, February 13, 2012, Jean Pihet wrote:
> > The PM QoS feature depends on CONFIG_PM which depends on
> > PM_SLEEP || PM_RUNTIME. This breaks CPU C-states with kernels
> > not having these CONFIGs.
> >
> > This patch allows the feature in all cases.
> >
> > Signed-off-by: Jean Pihet <j-pihet@ti.com>
> > Reported-by: Venkatesh Pallipadi <venki@google.com>
> > Cc: Rafael J. Wysocki <rjw@sisk.pl>
> > Cc: Mark Gross <markgross@thegnar.org>
>
> Applied, but I modified the changelog (please have a look at the
> linux-pm/pm-qos branch for details).
Is it good idea? For servers, power management / QoS is not
neccessary... What about fixing kconfig, instead?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [linux-pm] [PATCH 0/2] RFC: CPU frequency max as PM QoS param
From: Valentin, Eduardo @ 2012-02-17 8:12 UTC (permalink / raw)
To: markgross, amit.kachhap
Cc: Kevin Hilman, len.brown, cpufreq, Antti P Miettinen, linux-pm,
j-pihet
In-Reply-To: <20120217030453.GA3266@gs62>
Hello,
On Fri, Feb 17, 2012 at 5:04 AM, mark gross <markgross@thegnar.org> wrote:
> On Wed, Feb 15, 2012 at 05:06:40PM -0800, Kevin Hilman wrote:
>> Hello,
>>
>> Antti P Miettinen <amiettinen@nvidia.com> writes:
>>
>> > This is a continuation to "RFC: CPU frequency min as PM QoS param"
>> > patchset. This patchset adds CPU frequency maximum as a PM QoS
>> > parameter and modifies CPU frequncy core to enforce the limit. CPU
>> > frequency ceiling can be used to improve the energy efficiency of
>> > workloads that would cause the cpufreq governors to enforce an
>> > unnecessarily high operating point. In other words, CPU frequency
>> > maximum can act as an energy efficiency level request.
>> >
>> > Tested on Dell E6420 with the ACPI cpufreq driver against Ubuntu
>> > 3.2. Patches are against linux-next, compile tested.
>>
>> I know there were some earlier discussions about the usefulness of a max
>> frequency QoS parameter, so I wanted to throw in a reason to include max
>> as well as min frequency parameters.
>>
>> IMO, having a max frequency QoS parameter would be very useful from a
>> thermal perspective.
>>
>> There are some ongoing projects in the PM working group at Linaro that
>> are exploring plugins to the thermal framework that implment a "cooling
>> device" by capping CPU frequency. Having a QoS parameter do do this
>> would be the logical interface.
I saw the work started by Amit (Cced), but I believe we may need to expand it.
>>
>> I also agree with some earlier requests that these should probably be
>> per-CPU instead of global. That would make it simple to cap frequency
>> of one cluster while leaving another alone.
I believe we need to consider a broader set of cases, not only cpu.
>>
> Hi,
>
> My problem is that overloading pm_qos with a performance limits is a
> hack that will likely have problems coexisting with the core notion of
> throttling limiting that is pm_qos as thermal limiting enabling expands
> its scope.
>
> Sure limiting performance governors seem to need the same notifications
> and infrastructure as pm_qos but I worry that as its really doing the
> opposite to qos I really don't see the logic of having it in pmqos.
>
> Lets consider thermal throttling a bit maybe I can convince you to that
> maybe we need some new mechanism for energy and thermal limiting. (BTW
> I agree something is needed for this).
>
> For thermals the culprit's are:
> cpu -- cpufreq governor currently not-thermal aware
> Display -- brightness not thermal aware
> GFX -- graphics driver not thermal aware
> battery charging -- somewhat thermal aware but needs more than just bat
> temp to count.
> Flash -- led flash light not thermal aware.
This is probably what we want to consider, at least to start with. As
Mark mentions above, the cpu domain is just part of the equation.
The work started by Amit is going towards the right direction, but I
believe we need to review the thermal problem for those systems that
don't have ACPI. The generic part of current thermal framework
(drivers/thermal/) is still somewhat bound to ACPI.
>
> Other devices may have other heat sources of course.
Indeed.
>
> Wouldn't it be better to have thermal awareness as part of the driver
> model and then have a pm_qos like thing to do out of band signaling of
> devices and user mode when a temperature is hit?
>
Having things exposed to drivers is maybe one we to go, but we need to
be careful and not leave the decision making to drivers, IMO. Might be
worth considering thermal governors as well, instead of having the
decision making spread all over driver code. The point I am trying to
make here is that sometimes you may want to consider correlation
between these thermal domains.
> Putting it a qos class for limiting the high end of the performance that
> a governor really doesn't go far enough IMO. It looks like a hack just
> for cpufreq that already has sysfs interfaces for limiting the top
> frequency.
>
> ok, maybe my argument is not so strong. but as long as its named pm QOS
> and not pm-constraints I don't like the idea of having the max
> parameter in the pm_qos code.
I also agree that this type of problem goes more like a set of
constraint instead of trying to keep QoS.
>
> It feature creeps the infrastructure and violates the spirit of what
> pm_qos was to solve. i.e. constrain the lower power states not upper
> states.
>
> But, for thermal / energy management I think we need more notification
> of thermal or energy events than what is needed for the pm_qos problem.
>
> For pm_qos its mostly a static problem that is tuned in the lab. Know
> the workload needs and block too much throttling. For thermal / energy
> management you isn't any tuning you can do. You don't apply the
> constraint until it gets too hot. You don't know if or when you'll get
> too hot.
>
> Note: its more than just temperature that we need to worry about. Peak
> current is also a related issue (that is much more transient)
>
> Shouldn't we do something more forward looking than hack pm_qos with
> max-freq so that cpufreq can check a redundant parameter to what it
> already has exported through sysfs?
Agreed here, we need something to represent the problem in better way.
But, I believe what is currently at the sysfs for cpufreq is a
constraint set by user, and for thermal aspect, sometimes you can not
confuse what the user has set to what the system really needs. The
system may not want to wait for user to say you have to reduce
performance in order to try contain thermal, specially if the
situation is going critical, or as you mentioned, to consider peak
current management as well. So, I believe we need to consider both as
different constraints. Besides having these constraints coming from
different places and not having a good way to show what is going on on
the system (and also good ways to debug it) is something that may need
to be thought as well.
>
>
> --mark
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
All best,
--
Eduardo Valentin
^ permalink raw reply
* Re: [PATCH 0/2] RFC: CPU frequency max as PM QoS param
From: mark gross @ 2012-02-17 3:04 UTC (permalink / raw)
To: Kevin Hilman
Cc: len.brown, markgross, cpufreq, Antti P Miettinen, linux-pm,
j-pihet
In-Reply-To: <87d39fk2n3.fsf@ti.com>
On Wed, Feb 15, 2012 at 05:06:40PM -0800, Kevin Hilman wrote:
> Hello,
>
> Antti P Miettinen <amiettinen@nvidia.com> writes:
>
> > This is a continuation to "RFC: CPU frequency min as PM QoS param"
> > patchset. This patchset adds CPU frequency maximum as a PM QoS
> > parameter and modifies CPU frequncy core to enforce the limit. CPU
> > frequency ceiling can be used to improve the energy efficiency of
> > workloads that would cause the cpufreq governors to enforce an
> > unnecessarily high operating point. In other words, CPU frequency
> > maximum can act as an energy efficiency level request.
> >
> > Tested on Dell E6420 with the ACPI cpufreq driver against Ubuntu
> > 3.2. Patches are against linux-next, compile tested.
>
> I know there were some earlier discussions about the usefulness of a max
> frequency QoS parameter, so I wanted to throw in a reason to include max
> as well as min frequency parameters.
>
> IMO, having a max frequency QoS parameter would be very useful from a
> thermal perspective.
>
> There are some ongoing projects in the PM working group at Linaro that
> are exploring plugins to the thermal framework that implment a "cooling
> device" by capping CPU frequency. Having a QoS parameter do do this
> would be the logical interface.
>
> I also agree with some earlier requests that these should probably be
> per-CPU instead of global. That would make it simple to cap frequency
> of one cluster while leaving another alone.
>
Hi,
My problem is that overloading pm_qos with a performance limits is a
hack that will likely have problems coexisting with the core notion of
throttling limiting that is pm_qos as thermal limiting enabling expands
its scope.
Sure limiting performance governors seem to need the same notifications
and infrastructure as pm_qos but I worry that as its really doing the
opposite to qos I really don't see the logic of having it in pmqos.
Lets consider thermal throttling a bit maybe I can convince you to that
maybe we need some new mechanism for energy and thermal limiting. (BTW
I agree something is needed for this).
For thermals the culprit's are:
cpu -- cpufreq governor currently not-thermal aware
Display -- brightness not thermal aware
GFX -- graphics driver not thermal aware
battery charging -- somewhat thermal aware but needs more than just bat
temp to count.
Flash -- led flash light not thermal aware.
Other devices may have other heat sources of course.
Wouldn't it be better to have thermal awareness as part of the driver
model and then have a pm_qos like thing to do out of band signaling of
devices and user mode when a temperature is hit?
Putting it a qos class for limiting the high end of the performance that
a governor really doesn't go far enough IMO. It looks like a hack just
for cpufreq that already has sysfs interfaces for limiting the top
frequency.
ok, maybe my argument is not so strong. but as long as its named pm QOS
and not pm-constraints I don't like the idea of having the max
parameter in the pm_qos code.
It feature creeps the infrastructure and violates the spirit of what
pm_qos was to solve. i.e. constrain the lower power states not upper
states.
But, for thermal / energy management I think we need more notification
of thermal or energy events than what is needed for the pm_qos problem.
For pm_qos its mostly a static problem that is tuned in the lab. Know
the workload needs and block too much throttling. For thermal / energy
management you isn't any tuning you can do. You don't apply the
constraint until it gets too hot. You don't know if or when you'll get
too hot.
Note: its more than just temperature that we need to worry about. Peak
current is also a related issue (that is much more transient)
Shouldn't we do something more forward looking than hack pm_qos with
max-freq so that cpufreq can check a redundant parameter to what it
already has exported through sysfs?
--mark
^ permalink raw reply
* Re: Corrupted files after suspend to disk
From: richard -rw- weinberger @ 2012-02-16 23:37 UTC (permalink / raw)
Cc: linux-pm, LKML, esandeen
In-Reply-To: <4F3D90E1.6010001@redhat.com>
On Fri, Feb 17, 2012 at 12:27 AM, Eric Sandeen <sandeen@redhat.com> wrote:
> On 2/16/12 8:30 AM, Dave Jones wrote:
>> On Thu, Feb 16, 2012 at 11:52:27AM +0100, richard -rw- weinberger wrote:
>>
>> > >> >> Of course, please test the above separately. :-)
>> > >> >
>> > >> > Ok, I'll test this when I'm at home.
>> > >> >
>> > >> > BTW: dropping the caches helps, when some files seem corrupted.
>> > >> > Today /usr/bin/okular was broken.
>> > >> > After setting vm.drop_caches=1 it worked again.
>> > >>
>> > >> On Linux 2.6.38 I'm unable to reproduce the issue.
>> > >> Only 2.6.37 seems to be affected.
>> > >> So, I'm moving over to 2.6.38. :)
>> > >
>> > Bad news:
>> > I saw the issue on 3.x too but thought it's because my IdeaPad s10 is crap.
>> > Now with my shiny new Lenovo x121e I have the same issue! :-(
>> >
>> > OpenSUSE 12.1, kernel 3.2.7.
>> > After a few suspend2disk iterations random files are corrupted.
>> > But only cached files. A reboot solves the problem.
>
> Just to be clear - you see _data_ corruption in files, but only
> until a reboot, and after that they are ok? Ok, reading above
> about using drop_caches that sounds like the case.
Yes.
A reboot always solved the data corruption.
drop_caches solved it in 99% of all cases.
On-disk data was never corrupted.
--
Thanks,
//richard
^ permalink raw reply
* Re: Corrupted files after suspend to disk
From: Eric Sandeen @ 2012-02-16 23:27 UTC (permalink / raw)
To: Dave Jones, richard -rw- weinberger, Rafael J. Wysocki, LKML,
linux-pm, esandeen
In-Reply-To: <20120216163030.GA32651@redhat.com>
On 2/16/12 8:30 AM, Dave Jones wrote:
> On Thu, Feb 16, 2012 at 11:52:27AM +0100, richard -rw- weinberger wrote:
>
> > >> >> Of course, please test the above separately. :-)
> > >> >
> > >> > Ok, I'll test this when I'm at home.
> > >> >
> > >> > BTW: dropping the caches helps, when some files seem corrupted.
> > >> > Today /usr/bin/okular was broken.
> > >> > After setting vm.drop_caches=1 it worked again.
> > >>
> > >> On Linux 2.6.38 I'm unable to reproduce the issue.
> > >> Only 2.6.37 seems to be affected.
> > >> So, I'm moving over to 2.6.38. :)
> > >
> > Bad news:
> > I saw the issue on 3.x too but thought it's because my IdeaPad s10 is crap.
> > Now with my shiny new Lenovo x121e I have the same issue! :-(
> >
> > OpenSUSE 12.1, kernel 3.2.7.
> > After a few suspend2disk iterations random files are corrupted.
> > But only cached files. A reboot solves the problem.
Just to be clear - you see _data_ corruption in files, but only
until a reboot, and after that they are ok? Ok, reading above
about using drop_caches that sounds like the case.
That sounds different from what I saw in the bug Dave mentions
below, but possibly related root cause, I suppose.
-Eric
> FWIW, we've been seeing a number of hard to diagnose failures
> with suspend to disk for the last few releases in Fedora.
> Eric Sandeen has been chasing https://bugzilla.redhat.com/show_bug.cgi?id=744275
> for a while, but there's no smoking gun that really explains what's
> getting into these states. Further complicating things, is that it
> doesn't seem to be 100% reproducable.
>
> Dave
>
^ permalink raw reply
* Re: Corrupted files after suspend to disk
From: richard -rw- weinberger @ 2012-02-16 23:22 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, LKML, esandeen
In-Reply-To: <201202170016.14313.rjw@sisk.pl>
On Fri, Feb 17, 2012 at 12:16 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday, February 17, 2012, richard -rw- weinberger wrote:
>> On Thu, Feb 16, 2012 at 11:26 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > On Thu, 16 Feb 2012, Rafael J. Wysocki wrote:
>> >
>> >> > FWIW, we've been seeing a number of hard to diagnose failures
>> >> > with suspend to disk for the last few releases in Fedora.
>> >> > Eric Sandeen has been chasing https://bugzilla.redhat.com/show_bug.cgi?id=744275
>> >> > for a while, but there's no smoking gun that really explains what's
>> >> > getting into these states. Further complicating things, is that it
>> >> > doesn't seem to be 100% reproducable.
>> >>
>> >> I wonder if that's reproducible with the filesystems freezing patch I posted
>> >> some time ago (it will need some rebasing to apply to the current mainline or
>> >> 3.2.y).
>>
>> Where can I find this patch?
>> I'll happily test it.
>> But it may take some time as the bug is not easy to reproduce.
>
> This is the last version posted:
>
> http://marc.info/?l=linux-kernel&m=132775832509351&w=4
>
> However, it only may help if you use the kernel-based hibernation i.e.
> "echo disk > /sys/power/state" (that may be worth testing without the
> patch too, but Fedora is using this AFAICS, so it probably has that
> problem too).
Okay, I'll use kernel-based hibernation from now on.
If the problem still occurs I'll apply your patch.
Stay tuned!
--
Thanks,
//richard
^ permalink raw reply
* Re: Corrupted files after suspend to disk
From: Rafael J. Wysocki @ 2012-02-16 23:16 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: linux-pm, LKML, esandeen
In-Reply-To: <CAFLxGvwWBWTmv+uUH87UB3Ly31hjVU5kWpSyihGDKj6_8oc6WA@mail.gmail.com>
On Friday, February 17, 2012, richard -rw- weinberger wrote:
> On Thu, Feb 16, 2012 at 11:26 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Thu, 16 Feb 2012, Rafael J. Wysocki wrote:
> >
> >> > FWIW, we've been seeing a number of hard to diagnose failures
> >> > with suspend to disk for the last few releases in Fedora.
> >> > Eric Sandeen has been chasing https://bugzilla.redhat.com/show_bug.cgi?id=744275
> >> > for a while, but there's no smoking gun that really explains what's
> >> > getting into these states. Further complicating things, is that it
> >> > doesn't seem to be 100% reproducable.
> >>
> >> I wonder if that's reproducible with the filesystems freezing patch I posted
> >> some time ago (it will need some rebasing to apply to the current mainline or
> >> 3.2.y).
>
> Where can I find this patch?
> I'll happily test it.
> But it may take some time as the bug is not easy to reproduce.
This is the last version posted:
http://marc.info/?l=linux-kernel&m=132775832509351&w=4
However, it only may help if you use the kernel-based hibernation i.e.
"echo disk > /sys/power/state" (that may be worth testing without the
patch too, but Fedora is using this AFAICS, so it probably has that
problem too).
Thanks,
Rafael
^ permalink raw reply
* Re: Corrupted files after suspend to disk
From: richard -rw- weinberger @ 2012-02-16 23:07 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-pm, LKML, esandeen
In-Reply-To: <Pine.LNX.4.44L0.1202161722310.1150-100000@iolanthe.rowland.org>
On Thu, Feb 16, 2012 at 11:26 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 16 Feb 2012, Rafael J. Wysocki wrote:
>
>> > FWIW, we've been seeing a number of hard to diagnose failures
>> > with suspend to disk for the last few releases in Fedora.
>> > Eric Sandeen has been chasing https://bugzilla.redhat.com/show_bug.cgi?id=744275
>> > for a while, but there's no smoking gun that really explains what's
>> > getting into these states. Further complicating things, is that it
>> > doesn't seem to be 100% reproducable.
>>
>> I wonder if that's reproducible with the filesystems freezing patch I posted
>> some time ago (it will need some rebasing to apply to the current mainline or
>> 3.2.y).
Where can I find this patch?
I'll happily test it.
But it may take some time as the bug is not easy to reproduce.
>> I also thing that this problem discovered by Alan Stern may be involved:
>>
>> http://marc.info/?l=linux-pm&m=132940331030253&w=4
>
> Probably not, unless the filesystems in question are on a USB drive.
The filesystems are no on a USB device.
--
Thanks,
//richard
^ permalink raw reply
* Re: Corrupted files after suspend to disk
From: Alan Stern @ 2012-02-16 22:26 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: richard -rw- weinberger, linux-pm, LKML, esandeen
In-Reply-To: <201202162251.47063.rjw@sisk.pl>
On Thu, 16 Feb 2012, Rafael J. Wysocki wrote:
> > FWIW, we've been seeing a number of hard to diagnose failures
> > with suspend to disk for the last few releases in Fedora.
> > Eric Sandeen has been chasing https://bugzilla.redhat.com/show_bug.cgi?id=744275
> > for a while, but there's no smoking gun that really explains what's
> > getting into these states. Further complicating things, is that it
> > doesn't seem to be 100% reproducable.
>
> I wonder if that's reproducible with the filesystems freezing patch I posted
> some time ago (it will need some rebasing to apply to the current mainline or
> 3.2.y).
>
> I also thing that this problem discovered by Alan Stern may be involved:
>
> http://marc.info/?l=linux-pm&m=132940331030253&w=4
Probably not, unless the filesystems in question are on a USB drive.
Still, if anyone wants to test it, there's a patch here:
http://marc.info/?l=linux-pm&m=132941053601190&w=4
Alan Stern
^ permalink raw reply
* Re: Corrupted files after suspend to disk
From: Rafael J. Wysocki @ 2012-02-16 21:51 UTC (permalink / raw)
To: Dave Jones; +Cc: richard -rw- weinberger, linux-pm, LKML, esandeen
In-Reply-To: <20120216163030.GA32651@redhat.com>
On Thursday, February 16, 2012, Dave Jones wrote:
> On Thu, Feb 16, 2012 at 11:52:27AM +0100, richard -rw- weinberger wrote:
>
> > >> >> Of course, please test the above separately. :-)
> > >> >
> > >> > Ok, I'll test this when I'm at home.
> > >> >
> > >> > BTW: dropping the caches helps, when some files seem corrupted.
> > >> > Today /usr/bin/okular was broken.
> > >> > After setting vm.drop_caches=1 it worked again.
> > >>
> > >> On Linux 2.6.38 I'm unable to reproduce the issue.
> > >> Only 2.6.37 seems to be affected.
> > >> So, I'm moving over to 2.6.38. :)
> > >
> > Bad news:
> > I saw the issue on 3.x too but thought it's because my IdeaPad s10 is crap.
> > Now with my shiny new Lenovo x121e I have the same issue! :-(
> >
> > OpenSUSE 12.1, kernel 3.2.7.
> > After a few suspend2disk iterations random files are corrupted.
> > But only cached files. A reboot solves the problem.
>
> FWIW, we've been seeing a number of hard to diagnose failures
> with suspend to disk for the last few releases in Fedora.
> Eric Sandeen has been chasing https://bugzilla.redhat.com/show_bug.cgi?id=744275
> for a while, but there's no smoking gun that really explains what's
> getting into these states. Further complicating things, is that it
> doesn't seem to be 100% reproducable.
I wonder if that's reproducible with the filesystems freezing patch I posted
some time ago (it will need some rebasing to apply to the current mainline or
3.2.y).
I also thing that this problem discovered by Alan Stern may be involved:
http://marc.info/?l=linux-pm&m=132940331030253&w=4
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH 1/2] r8169: Enable WOL from Magic Packet by default
From: Sameer Nanda @ 2012-02-16 20:47 UTC (permalink / raw)
To: David Miller; +Cc: romieu, rjw, hayeswang, netdev, linux-pm
In-Reply-To: <20120214.223746.419009242484406948.davem@davemloft.net>
On Tue, Feb 14, 2012 at 7:37 PM, David Miller <davem@davemloft.net> wrote:
> From: Sameer Nanda <snanda@chromium.org>
> Date: Tue, 14 Feb 2012 17:00:04 -0800
>
>> On Tue, Feb 14, 2012 at 4:13 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
>>> Sameer Nanda <snanda@chromium.org> :
>>>> Set the WOL config registers to only enable WOL from magic packet by
>>>> default. Without this change in place, the WOL config register
>>>> settings on warm reboot come up in an inconsistent state since these
>>>> registers don't get reset on a warm reboot.
>>>
>>> I am not completely convinced, especially as the change of behavior
>>> could be noticed.
>>
>> Agreed that this change could be noticed. Maybe a module parameter
>> might be a better way to handle this?
>
> Please no random module parameters, something ethtool based is
> what you should shoot for.
With the existing code, WOL from PHY, unicast, multicast and broadcast
packets may get accidentally enabled. The probability of seeing such
packets/events in the wild is quite high and this can cause unintended
wakes from S3 or reboots.
The probability of seeing matching MagicPackets in the wild is
vanishingly small. Therefore, setting MagicPacket as the only default
WOL mechanism seems like the safer option.
Since ethtool already supports setting of WOL options from userland, I
guess we don't need a new module parameter as the user can set WOL
options according to his own desires.
--
Sameer
^ 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