* Re: [PATCH 1/3] cpufreq: Manage only online cpus
From: Viresh Kumar @ 2013-01-03 3:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linaro-dev, nicolas.pitre, amit.kucheria, mathieu.poirier,
linux-kernel, cpufreq, pdsw-power-team, linux-pm
In-Reply-To: <7569403.CvHy03LdiU@vostro.rjw.lan>
On 3 January 2013 06:43, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> BTW, i consider them as fixes and so would make sense to get them in next rc.
>> What do you think?
>
> Yes, if somebody tells me "yes, this fixes a problem for me". Otherwise,
> I don't quite see the reason.
I don't know how much people test HOTPLUG, but there are clear bugs related
to hotplug of cpus on a multiple cpu system :)
^ permalink raw reply
* Re: [PATCH 1/3] cpufreq: Manage only online cpus
From: Rafael J. Wysocki @ 2013-01-03 1:13 UTC (permalink / raw)
To: Viresh Kumar
Cc: linaro-dev, nicolas.pitre, amit.kucheria, mathieu.poirier,
linux-kernel, cpufreq, pdsw-power-team, linux-pm
In-Reply-To: <CAKohpomxCSVRXkvde-P6T3Ks=7Z8PX1NSjzFfvKsPYQXTScwRw@mail.gmail.com>
On Wednesday, January 02, 2013 11:59:57 AM Viresh Kumar wrote:
> On 16 December 2012 19:07, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 16 December 2012 18:34, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> >> Well, this series makes sense to me, but I'd like to hear what the other people
> >> think.
> >
> > That sounds great :)
> >
> > Some more information for others about how i reached to these issues
> > is present here:
> >
> > https://lkml.org/lkml/2012/12/10/44
>
> Hmm.. I don't know, if we are going to get any feedback from others :(
Surely somebody cares except for us two?
> BTW, i consider them as fixes and so would make sense to get them in next rc.
> What do you think?
Yes, if somebody tells me "yes, this fixes a problem for me". Otherwise,
I don't quite see the reason.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] cpuidle - fix lock contention in the idle path
From: Russ Anderson @ 2013-01-02 21:13 UTC (permalink / raw)
To: Daniel Lezcano
Cc: rafael.j.wysocki, linux-pm, pdeschrijver, akpm, linux-kernel, rja
In-Reply-To: <1356516108-11191-1-git-send-email-daniel.lezcano@linaro.org>
On Wed, Dec 26, 2012 at 11:01:48AM +0100, Daniel Lezcano wrote:
> The commit bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92 introduces
> a lock in the cpuidle_get_cpu_driver function. This function
> is used in the idle_call function.
>
> The problem is the contention with a large number of cpus because
> they try to access the idle routine at the same time.
>
> The lock could be safely removed because of how is used the
> cpuidle api. The cpuidle_register_driver is called first but
> until the cpuidle_register_device is not called we don't
> enter in the cpuidle idle call function because the device
> is not enabled.
>
> The cpuidle_unregister_driver function, leading the a NULL driver,
> is not called before the cpuidle_unregister_device.
>
> This is how is used the cpuidle api from the different drivers.
>
> However, a cleanup around the lock and a proper refcounting
> mechanism should be used to ensure the consistency in the api,
> like cpuidle_unregister_driver should failed if its refcounting
> is not 0.
>
> These modifications will need some code reorganization and rewrite
> which does not fit with a fix.
I agree.
> The following patch is a hot fix by returning to the initial behavior
> by removing the lock when getting the driver.
The patch fixes the problem. Verified on a system with 1024 cpus.
Thanks.
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reported-by: Russ Anderson <rja@sgi.com>
Acked-by: Russ Anderson <rja@sgi.com>
> ---
> drivers/cpuidle/driver.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index 3af841f..c2b281a 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -235,16 +235,10 @@ EXPORT_SYMBOL_GPL(cpuidle_get_driver);
> */
> struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
> {
> - struct cpuidle_driver *drv;
> -
> if (!dev)
> return NULL;
>
> - spin_lock(&cpuidle_driver_lock);
> - drv = __cpuidle_get_cpu_driver(dev->cpu);
> - spin_unlock(&cpuidle_driver_lock);
> -
> - return drv;
> + return __cpuidle_get_cpu_driver(dev->cpu);
> }
> EXPORT_SYMBOL_GPL(cpuidle_get_cpu_driver);
>
> --
> 1.7.9.5
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@sgi.com
^ permalink raw reply
* Re: [RFC PATCH 0/7] Support for Multiple sensors per zone
From: Eduardo Valentin @ 2013-01-02 16:46 UTC (permalink / raw)
To: R, Durgadoss
Cc: Zhang, Rui, linux-pm@vger.kernel.org, wni@nvidia.com,
amit.kachhap@linaro.org, hongbo.zhang@linaro.org,
sachin.kamat@linaro.org
In-Reply-To: <4D68720C2E767A4AA6A8796D42C8EB59252EA0@BGSMSX101.gar.corp.intel.com>
Hello Durga,
On 02-01-2013 18:29, R, Durgadoss wrote:
> Hello Eduardo,
>
>> -----Original Message-----
>> From: Eduardo Valentin [mailto:eduardo.valentin@ti.com]
>> Sent: Wednesday, January 02, 2013 9:18 PM
>> To: R, Durgadoss
>> Cc: Zhang, Rui; linux-pm@vger.kernel.org; wni@nvidia.com;
>> amit.kachhap@linaro.org; hongbo.zhang@linaro.org;
>> sachin.kamat@linaro.org
>> Subject: Re: [RFC PATCH 0/7] Support for Multiple sensors per zone
>>
>>
>> Hello Durga,
>>
>> First of all, sorry for the late answer. Happy New Year to you BTW. :-)
>
> Wish you a Happy New Year too :-)
Thanks.
> Yeah, we are talking after a long time!!
>
Indeed.
>>
>> On 17-11-2012 12:45, Durgadoss R wrote:
>>> This patch series attempts to add support for multiple
>>> sensors per zone. The work is based on the Thermal discussion
>>> happened in plumbers conference 2012, here:
>>> http://www.linuxplumbersconf.org/2012/schedule/
>>> Title: "Enhancing the Thermal Management Infrastructure in Linux"
>>>
>>
>> On the above discussion one point which was not really clear was if we
>> would create virtual thermal zones, with a fop to determine its
>> temperature in a given time, or if we would write APIs to fetch
>> temperature from a thermal zone and then in the platform code to would
>> derive the real temperature.
Forgot to mention that the agreement during the thermal session was to
use the concept of virtual thermal zone/sensor as agregator.
>
> A really difficult but interesting question; Happy to answer :-)
> Actually we discussed this very same point various times internally,
> before coming up with this new framework. Let me explain that in
> brief to you.
>
>>
>> From this patch series, looks like we are going to both directions at
>> the same time. Let me try to understand your proposal by introducing a
>> simple example.
>>
>> Let us assume a simple scenario which we have a thermal zone with 2
>> sensors, say, for skin management, one for back cover and one for LCD.
>> Assume also you have two different HW sensors, for whatever reason. By
>> your proposal, we would have two simple sensor drivers, one for each HW,
>> which is good. A platform driver that would add these two sensor
>> instances into a thermal zone.
>
> Perfect. Valid example.
>
>>
>> Now. what I don't know is how to determine the temperature of that zone.
>
> Yeah. Here we are.
> From the new framework onwards, we are treating the 'zone' as a complete
> virtual concept. A zone can have multiple sensors reporting temperature.
>
> To compute the 'theoretical zone temperature', consider 'zone' as a 'virtual
> sensor'. This means, the platform driver will register one more sensor using
> thermal_sensor_register API with a name 'virtual_XXXX' (or something like
> that; we have not finalized the name yet). This sensor can be added to the
> required zone also. Now, to compute the zone temperature, the 'get_temp'
> callback of this sensor (inside the platform driver) can do 'whatever magic
> it wants to do'.
OK. then we are going to do same thing we discussed in LPC. Just that I
got a bit confused on the patch set. Reusing get_temp is actually ideal
because we can keep the remaining API as it is.
> A rather simple magic could be:
> temp_of_virtual_sensor = (sum of all sensor
> temperatures in this zone)/num_sensors_in_this_zone.
>
Yeah.
> This way, we could provide trip_points & thresholds for this virtual sensor
> also. i.e. everything else remains same.
Exactly.
>
>> I believe we need to have a thermal zone fops with get temperature. I am
>
> We thought through this to some extent.
> Assume we introduce a 'temp' sysfs interface (and the fops) for zone temperature.
> Now, we have to provide trip_points and thresholds also for this; Then, in the
> governors, what should we refer to ? on what basis shall we take actions ?
> Based on sensor temperature crossing a trip point ? or
> Based on the zone temperature crossing its own trip point ?
> If it is zone based, then it has to be 'polled' because a virtual zone
> cannot support programmable thresholds.
Yeah, I think using the concept of virtual thermal zone is the best. The
trips and cooling actions are bound to the provided computed
temperature, and then everything else remains the same, except that the
zone temperature is actually synthetic.
>
> Moreover, the platform data mapping is also between sensors and
> cooling devices. A close look at patches 4 & 5 will explain this.
> So, If we go by 'zone' = 'virtual sensor',
> the governors can work as usual, and the way we provide platform data
> remains the same etc.. Hence, this idea was chosen.
>
good. that was also my suggestion during LPC.
> This 'virtual sensor' is also one important reason why we want to
> maintain the separation between 'sensor drivers' and 'platform drivers'.
> One that works for the hardware, and the other which can do magic :-)
>
> Let me know if this makes sense.
Yes it does. I will have a closer look on your series and come back later.
>
> Thanks again for the question!!
>
> Thanks,
> Durga
>
>> assuming the platform driver would be the one who introduces the thermal
>> zone, and adds the sensors, and knows how to determine the temperature
>> of that zone. This way, one can easily write a function to determine the
>> "summary temperature". Remember that using index to select one specific
>> temperature sensor for a given time may not be enough, as there are
>> scenarios in which one may write an equation which uses all sensors
>> temperature values to determine the ending zone temperature.
>>
>>> The intention is to make it easy for generic sensor drivers
>>> to register with the framework, and let them participate in
>>> platform thermal management. Another goal is to expose the
>>> binding information in a consistent way so that user space
>>> can consume the information and potentially manage platform thermals.
>>>
>>> This series contains 7 patches:
>>> Patch 1/7: Creates new sensor level APIs
>>> Patch 2/7: Creates new zone level APIs. The existing tzd structure is
>>> kept as such for clarity and compatibility purposes.
>>> Patch 3/7: Creates functions to add/remove a cdev to/from a zone. The
>>> existing tcd structure need not be modified.
>>> Patch 4/7: Adds a thermal_trip sysfs node, which exposes various trip
>>> points for all sensors present in a zone.
>>> Patch 5/7: Adds a thermal_map sysfs node. It is a compact representation
>>> of the binding relationship between a sensor and a cdev,
>>> within a zone.
>>> Patch 6/7: Creates Documentation for the new APIs. A new file is
>>> created for clarity. Final goal is to merge with the existing
>>> file or refactor the files, as whatever seems appropriate.
>>> Patch 7/7: A dummy driver that can be used for testing. This is not for
>> merge.
>>>
>>> Next steps:
>>> 1. Move all the existing drivers to the new implementation model.
>>> Help welcomed from individual driver authors/maintainers for this.
>>> 2. Make the thermal governors work with this new model.
>>> 3. Remove old/unused code from thermal_sys.c.
>>> 4. Add more detailed documentation
>>>
>>> I didn't want to submit patches for all these in one-go, since it
>>> might end-up being difficult to comprehend, besides delaying the
>>> review process. The other obvious reason being I cannot test all
>>> the changes on various drivers for 1.
>>>
>>> All these patches have been tested on a Core-i5 desktop running
>>> ubuntu 12.04 and an atom notebook running ubuntu 11.10.
>>> Kindly help review.
>>>
>>> Durgadoss R (7):
>>> Thermal: Create sensor level APIs
>>> Thermal: Create zone level APIs
>>> Thermal: Add APIs to bind cdev to new zone structure
>>> Thermal: Add Thermal_trip sysfs node
>>> Thermal: Add 'thermal_map' sysfs node
>>> Thermal: Add Documentation to new APIs
>>> Thermal: Dummy driver used for testing
>>>
>>> Documentation/thermal/sysfs-api2.txt | 213 ++++++++
>>> drivers/thermal/Kconfig | 5 +
>>> drivers/thermal/Makefile | 3 +
>>> drivers/thermal/thermal_sys.c | 915
>> ++++++++++++++++++++++++++++++++++
>>> drivers/thermal/thermal_test.c | 321 ++++++++++++
>>> include/linux/thermal.h | 118 +++++
>>> 6 files changed, 1575 insertions(+)
>>> create mode 100644 Documentation/thermal/sysfs-api2.txt
>>> create mode 100644 drivers/thermal/thermal_test.c
>>>
>
^ permalink raw reply
* RE: [RFC PATCH 0/7] Support for Multiple sensors per zone
From: R, Durgadoss @ 2013-01-02 16:29 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Zhang, Rui, linux-pm@vger.kernel.org, wni@nvidia.com,
amit.kachhap@linaro.org, hongbo.zhang@linaro.org,
sachin.kamat@linaro.org
In-Reply-To: <50E456B7.6010401@ti.com>
Hello Eduardo,
> -----Original Message-----
> From: Eduardo Valentin [mailto:eduardo.valentin@ti.com]
> Sent: Wednesday, January 02, 2013 9:18 PM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux-pm@vger.kernel.org; wni@nvidia.com;
> amit.kachhap@linaro.org; hongbo.zhang@linaro.org;
> sachin.kamat@linaro.org
> Subject: Re: [RFC PATCH 0/7] Support for Multiple sensors per zone
>
>
> Hello Durga,
>
> First of all, sorry for the late answer. Happy New Year to you BTW. :-)
Wish you a Happy New Year too :-)
Yeah, we are talking after a long time!!
>
> On 17-11-2012 12:45, Durgadoss R wrote:
> > This patch series attempts to add support for multiple
> > sensors per zone. The work is based on the Thermal discussion
> > happened in plumbers conference 2012, here:
> > http://www.linuxplumbersconf.org/2012/schedule/
> > Title: "Enhancing the Thermal Management Infrastructure in Linux"
> >
>
> On the above discussion one point which was not really clear was if we
> would create virtual thermal zones, with a fop to determine its
> temperature in a given time, or if we would write APIs to fetch
> temperature from a thermal zone and then in the platform code to would
> derive the real temperature.
A really difficult but interesting question; Happy to answer :-)
Actually we discussed this very same point various times internally,
before coming up with this new framework. Let me explain that in
brief to you.
>
> From this patch series, looks like we are going to both directions at
> the same time. Let me try to understand your proposal by introducing a
> simple example.
>
> Let us assume a simple scenario which we have a thermal zone with 2
> sensors, say, for skin management, one for back cover and one for LCD.
> Assume also you have two different HW sensors, for whatever reason. By
> your proposal, we would have two simple sensor drivers, one for each HW,
> which is good. A platform driver that would add these two sensor
> instances into a thermal zone.
Perfect. Valid example.
>
> Now. what I don't know is how to determine the temperature of that zone.
Yeah. Here we are.
>From the new framework onwards, we are treating the 'zone' as a complete
virtual concept. A zone can have multiple sensors reporting temperature.
To compute the 'theoretical zone temperature', consider 'zone' as a 'virtual
sensor'. This means, the platform driver will register one more sensor using
thermal_sensor_register API with a name 'virtual_XXXX' (or something like
that; we have not finalized the name yet). This sensor can be added to the
required zone also. Now, to compute the zone temperature, the 'get_temp'
callback of this sensor (inside the platform driver) can do 'whatever magic
it wants to do'.
A rather simple magic could be:
temp_of_virtual_sensor = (sum of all sensor
temperatures in this zone)/num_sensors_in_this_zone.
This way, we could provide trip_points & thresholds for this virtual sensor
also. i.e. everything else remains same.
> I believe we need to have a thermal zone fops with get temperature. I am
We thought through this to some extent.
Assume we introduce a 'temp' sysfs interface (and the fops) for zone temperature.
Now, we have to provide trip_points and thresholds also for this; Then, in the
governors, what should we refer to ? on what basis shall we take actions ?
Based on sensor temperature crossing a trip point ? or
Based on the zone temperature crossing its own trip point ?
If it is zone based, then it has to be 'polled' because a virtual zone
cannot support programmable thresholds.
Moreover, the platform data mapping is also between sensors and
cooling devices. A close look at patches 4 & 5 will explain this.
So, If we go by 'zone' = 'virtual sensor',
the governors can work as usual, and the way we provide platform data
remains the same etc.. Hence, this idea was chosen.
This 'virtual sensor' is also one important reason why we want to
maintain the separation between 'sensor drivers' and 'platform drivers'.
One that works for the hardware, and the other which can do magic :-)
Let me know if this makes sense.
Thanks again for the question!!
Thanks,
Durga
> assuming the platform driver would be the one who introduces the thermal
> zone, and adds the sensors, and knows how to determine the temperature
> of that zone. This way, one can easily write a function to determine the
> "summary temperature". Remember that using index to select one specific
> temperature sensor for a given time may not be enough, as there are
> scenarios in which one may write an equation which uses all sensors
> temperature values to determine the ending zone temperature.
>
> > The intention is to make it easy for generic sensor drivers
> > to register with the framework, and let them participate in
> > platform thermal management. Another goal is to expose the
> > binding information in a consistent way so that user space
> > can consume the information and potentially manage platform thermals.
> >
> > This series contains 7 patches:
> > Patch 1/7: Creates new sensor level APIs
> > Patch 2/7: Creates new zone level APIs. The existing tzd structure is
> > kept as such for clarity and compatibility purposes.
> > Patch 3/7: Creates functions to add/remove a cdev to/from a zone. The
> > existing tcd structure need not be modified.
> > Patch 4/7: Adds a thermal_trip sysfs node, which exposes various trip
> > points for all sensors present in a zone.
> > Patch 5/7: Adds a thermal_map sysfs node. It is a compact representation
> > of the binding relationship between a sensor and a cdev,
> > within a zone.
> > Patch 6/7: Creates Documentation for the new APIs. A new file is
> > created for clarity. Final goal is to merge with the existing
> > file or refactor the files, as whatever seems appropriate.
> > Patch 7/7: A dummy driver that can be used for testing. This is not for
> merge.
> >
> > Next steps:
> > 1. Move all the existing drivers to the new implementation model.
> > Help welcomed from individual driver authors/maintainers for this.
> > 2. Make the thermal governors work with this new model.
> > 3. Remove old/unused code from thermal_sys.c.
> > 4. Add more detailed documentation
> >
> > I didn't want to submit patches for all these in one-go, since it
> > might end-up being difficult to comprehend, besides delaying the
> > review process. The other obvious reason being I cannot test all
> > the changes on various drivers for 1.
> >
> > All these patches have been tested on a Core-i5 desktop running
> > ubuntu 12.04 and an atom notebook running ubuntu 11.10.
> > Kindly help review.
> >
> > Durgadoss R (7):
> > Thermal: Create sensor level APIs
> > Thermal: Create zone level APIs
> > Thermal: Add APIs to bind cdev to new zone structure
> > Thermal: Add Thermal_trip sysfs node
> > Thermal: Add 'thermal_map' sysfs node
> > Thermal: Add Documentation to new APIs
> > Thermal: Dummy driver used for testing
> >
> > Documentation/thermal/sysfs-api2.txt | 213 ++++++++
> > drivers/thermal/Kconfig | 5 +
> > drivers/thermal/Makefile | 3 +
> > drivers/thermal/thermal_sys.c | 915
> ++++++++++++++++++++++++++++++++++
> > drivers/thermal/thermal_test.c | 321 ++++++++++++
> > include/linux/thermal.h | 118 +++++
> > 6 files changed, 1575 insertions(+)
> > create mode 100644 Documentation/thermal/sysfs-api2.txt
> > create mode 100644 drivers/thermal/thermal_test.c
> >
^ permalink raw reply
* Re: [PATCH RESEND 1/4] thermal: Use thermal zone device id in netlink messages
From: Eduardo Valentin @ 2013-01-02 15:55 UTC (permalink / raw)
To: R, Durgadoss
Cc: Zhang, Rui, linux-pm@lists.linux-foundation.org,
linux-pm@vger.kernel.org
In-Reply-To: <4D68720C2E767A4AA6A8796D42C8EB59252E14@BGSMSX101.gar.corp.intel.com>
Hello,
On 02-01-2013 17:48, R, Durgadoss wrote:
>> -----Original Message-----
>> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
>> owner@vger.kernel.org] On Behalf Of Eduardo Valentin
>> Sent: Wednesday, January 02, 2013 9:00 PM
>> To: Zhang, Rui
>> Cc: R, Durgadoss; linux-pm@lists.linux-foundation.org; linux-
>> pm@vger.kernel.org; Eduardo Valentin
>> Subject: [PATCH RESEND 1/4] thermal: Use thermal zone device id in netlink
>> messages
>>
>> This patch changes the function thermal_generate_netlink_event
>> to receive a thermal zone device instead of a originator id.
>>
>> This way, the messages will always be bound to a thermal zone.
>
> As you have mentioned, we are planning to deprecate this API.
> But, for now, this change is Ok :-)
Good.
>
> And I believe all these four patches are on Rui's tree ?
They are not :-(
>
>>
>
> Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
>
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>> Documentation/thermal/sysfs-api.txt | 5 +++--
>> drivers/thermal/thermal_sys.c | 8 ++++++--
>> include/linux/thermal.h | 6 ++++--
>> 3 files changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt
>> b/Documentation/thermal/sysfs-api.txt
>> index 88c0233..526d4b9 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -329,8 +329,9 @@ The framework includes a simple notification
>> mechanism, in the form of a
>> netlink event. Netlink socket initialization is done during the _init_
>> of the framework. Drivers which intend to use the notification mechanism
>> just need to call thermal_generate_netlink_event() with two arguments viz
>> -(originator, event). Typically the originator will be an integer assigned
>> -to a thermal_zone_device when it registers itself with the framework. The
>> +(originator, event). The originator is a pointer to struct
>> thermal_zone_device
>> +from where the event has been originated. An integer which represents
>> the
>> +thermal zone device will be used in the message to identify the zone. The
>> event will be one of:{THERMAL_AUX0, THERMAL_AUX1,
>> THERMAL_CRITICAL,
>> THERMAL_DEV_FAULT}. Notification can be sent when the current
>> temperature
>> crosses any of the configured thresholds.
>> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
>> index 8c8ce80..d85f51f 100644
>> --- a/drivers/thermal/thermal_sys.c
>> +++ b/drivers/thermal/thermal_sys.c
>> @@ -1711,7 +1711,8 @@ static struct genl_multicast_group
>> thermal_event_mcgrp = {
>> .name = THERMAL_GENL_MCAST_GROUP_NAME,
>> };
>>
>> -int thermal_generate_netlink_event(u32 orig, enum events event)
>> +int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>> + enum events event)
>> {
>> struct sk_buff *skb;
>> struct nlattr *attr;
>> @@ -1721,6 +1722,9 @@ int thermal_generate_netlink_event(u32 orig,
>> enum events event)
>> int result;
>> static unsigned int thermal_event_seqnum;
>>
>> + if (!tz)
>> + return -EINVAL;
>> +
>> /* allocate memory */
>> size = nla_total_size(sizeof(struct thermal_genl_event)) +
>> nla_total_size(0);
>> @@ -1755,7 +1759,7 @@ int thermal_generate_netlink_event(u32 orig,
>> enum events event)
>>
>> memset(thermal_event, 0, sizeof(struct thermal_genl_event));
>>
>> - thermal_event->orig = orig;
>> + thermal_event->orig = tz->id;
>> thermal_event->event = event;
>>
>> /* send multicast genetlink message */
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index fe82022..e85ac70 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -244,9 +244,11 @@ int thermal_register_governor(struct
>> thermal_governor *);
>> void thermal_unregister_governor(struct thermal_governor *);
>>
>> #ifdef CONFIG_NET
>> -extern int thermal_generate_netlink_event(u32 orig, enum events event);
>> +extern int thermal_generate_netlink_event(struct thermal_zone_device
>> *tz,
>> + enum events event);
>> #else
>> -static inline int thermal_generate_netlink_event(u32 orig, enum events
>> event)
>> +static int thermal_generate_netlink_event(struct thermal_zone_device
>> *tz,
>> + enum events event)
>> {
>> return 0;
>> }
>> --
>> 1.7.7.1.488.ge8e1c
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH 1/1] thermal: introduce thermal_zone_lookup_temperature helper function
From: Eduardo Valentin @ 2013-01-02 15:53 UTC (permalink / raw)
To: durgadoss.r; +Cc: rui.zhang, linux-pm, linux-pm, Eduardo Valentin
This patch adds a helper function to get temperature of
a thermal zone, based on the zone type name.
It will perform a zone name lookup and return the last
sensor temperature reading. In case the zone is not found
or if the required parameters are invalid, it will return
the corresponding error code.
With this, we could write platform code to fetch several temperature
from several sensors and derive "summary" temperature for a virtual
thermal zone.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
drivers/thermal/thermal_sys.c | 30 ++++++++++++++++++++++++++++++
include/linux/thermal.h | 1 +
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index a24b010..4269571 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -1703,6 +1703,36 @@ void thermal_zone_device_unregister(struct thermal_zone_device *tz)
}
EXPORT_SYMBOL(thermal_zone_device_unregister);
+/**
+ * thermal_lookup_temperature - search for a zone and returns its temperature
+ * @name: thermal zone name to fetch the temperature
+ * @temperature: pointer to store the zone temperature, in case it is found
+ *
+ * When the zone is found, updates @temperature and returns 0. Returns
+ * -EINVAL in case of wrong parameters and -ENODEV in case the zone is not found
+ */
+int thermal_zone_lookup_temperature(const char *name, int *temperature)
+{
+ struct thermal_zone_device *pos = NULL;
+ bool found = false;
+
+ if (!name || !temperature)
+ return -EINVAL;
+
+ mutex_lock(&thermal_list_lock);
+ list_for_each_entry(pos, &thermal_tz_list, node)
+ if (!strcmp(pos->type, name)) {
+ found = true;
+ break;
+ }
+ if (found)
+ *temperature = pos->last_temperature;
+ mutex_unlock(&thermal_list_lock);
+
+ return found ? 0 : -ENODEV;
+}
+EXPORT_SYMBOL(thermal_zone_lookup_temperature);
+
#ifdef CONFIG_NET
static struct genl_family thermal_event_genl_family = {
.id = GENL_ID_GENERATE,
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index e85ac70..e0cb335c 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -233,6 +233,7 @@ void thermal_zone_device_update(struct thermal_zone_device *);
struct thermal_cooling_device *thermal_cooling_device_register(char *, void *,
const struct thermal_cooling_device_ops *);
void thermal_cooling_device_unregister(struct thermal_cooling_device *);
+int thermal_zone_lookup_temperature(const char *name, int *temperature);
int get_tz_trend(struct thermal_zone_device *, int);
struct thermal_instance *get_thermal_instance(struct thermal_zone_device *,
--
1.7.7.1.488.ge8e1c
^ permalink raw reply related
* RE: [PATCH RESEND 4/4] thermal: check for invalid trip setup when registering thermal device
From: R, Durgadoss @ 2013-01-02 15:53 UTC (permalink / raw)
To: Eduardo Valentin, Zhang, Rui
Cc: linux-pm@lists.linux-foundation.org, linux-pm@vger.kernel.org
In-Reply-To: <1357140582-8151-5-git-send-email-eduardo.valentin@ti.com>
> -----Original Message-----
> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> owner@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Wednesday, January 02, 2013 9:00 PM
> To: Zhang, Rui
> Cc: R, Durgadoss; linux-pm@lists.linux-foundation.org; linux-
> pm@vger.kernel.org; Eduardo Valentin
> Subject: [PATCH RESEND 4/4] thermal: check for invalid trip setup when
> registering thermal device
>
> This patch adds an extra check in the data structure while registering
> a thermal device. The check is to avoid registering zones with a number
> of trips greater than zero, but with no .get_trip_temp nor .get_trip_type
> callbacks. Receiving such data structure may end in wrong data access.
Yes, agreed. we are moving away from this API too :-(
But Nothing hurts to have this fix. So,
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Thanks,
Durga
>
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
> drivers/thermal/thermal_sys.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index fba27c3..0a1bf6b 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -1530,6 +1530,9 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
> if (!ops || !ops->get_temp)
> return ERR_PTR(-EINVAL);
>
> + if (trips > 0 && !ops->get_trip_type)
> + return ERR_PTR(-EINVAL);
> +
> tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL);
> if (!tz)
> return ERR_PTR(-ENOMEM);
> --
> 1.7.7.1.488.ge8e1c
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH RESEND 3/4] thermal: cleanup: use dev_* helper functions
From: R, Durgadoss @ 2013-01-02 15:51 UTC (permalink / raw)
To: Eduardo Valentin, Zhang, Rui
Cc: linux-pm@lists.linux-foundation.org, linux-pm@vger.kernel.org
In-Reply-To: <1357140582-8151-4-git-send-email-eduardo.valentin@ti.com>
> -----Original Message-----
> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> owner@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Wednesday, January 02, 2013 9:00 PM
> To: Zhang, Rui
> Cc: R, Durgadoss; linux-pm@lists.linux-foundation.org; linux-
> pm@vger.kernel.org; Eduardo Valentin
> Subject: [PATCH RESEND 3/4] thermal: cleanup: use dev_* helper functions
>
> Change the logging messages to used dev_* helper functions.
A good to have Change :-)
>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Thanks,
Durga
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
> drivers/thermal/thermal_sys.c | 10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 70ce100..fba27c3 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -354,8 +354,9 @@ static void handle_critical_trips(struct
> thermal_zone_device *tz,
> tz->ops->notify(tz, trip, trip_type);
>
> if (trip_type == THERMAL_TRIP_CRITICAL) {
> - pr_emerg("Critical temperature reached(%d C),shutting
> down\n",
> - tz->temperature / 1000);
> + dev_emerg(&tz->device,
> + "critical temperature reached(%d C),shutting
> down\n",
> + tz->temperature / 1000);
> orderly_poweroff(true);
> }
> }
> @@ -386,7 +387,8 @@ static void update_temperature(struct
> thermal_zone_device *tz)
>
> ret = tz->ops->get_temp(tz, &temp);
> if (ret) {
> - pr_warn("failed to read out thermal zone %d\n", tz->id);
> + dev_warn(&tz->device, "failed to read out thermal zone
> %d\n",
> + tz->id);
> goto exit;
> }
>
> @@ -1770,7 +1772,7 @@ int thermal_generate_netlink_event(struct
> thermal_zone_device *tz,
>
> result = genlmsg_multicast(skb, 0, thermal_event_mcgrp.id,
> GFP_ATOMIC);
> if (result)
> - pr_info("failed to send netlink event:%d\n", result);
> + dev_err(&tz->device, "Failed to send netlink event:%d",
> result);
>
> return result;
> }
> --
> 1.7.7.1.488.ge8e1c
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH RESEND 2/4] thermal: remove unnecessary include
From: R, Durgadoss @ 2013-01-02 15:48 UTC (permalink / raw)
To: Eduardo Valentin, Zhang, Rui
Cc: linux-pm@lists.linux-foundation.org, linux-pm@vger.kernel.org
In-Reply-To: <1357140582-8151-3-git-send-email-eduardo.valentin@ti.com>
> -----Original Message-----
> From: Eduardo Valentin [mailto:eduardo.valentin@ti.com]
> Sent: Wednesday, January 02, 2013 9:00 PM
> To: Zhang, Rui
> Cc: R, Durgadoss; linux-pm@lists.linux-foundation.org; linux-
> pm@vger.kernel.org; Eduardo Valentin
> Subject: [PATCH RESEND 2/4] thermal: remove unnecessary include
>
> No need for spinlocks in this file, then removing its header.
Good Catch !!
>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Thanks,
Durga
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
> drivers/thermal/thermal_sys.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index d85f51f..70ce100 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -32,7 +32,6 @@
> #include <linux/kdev_t.h>
> #include <linux/idr.h>
> #include <linux/thermal.h>
> -#include <linux/spinlock.h>
> #include <linux/reboot.h>
> #include <net/netlink.h>
> #include <net/genetlink.h>
> --
> 1.7.7.1.488.ge8e1c
^ permalink raw reply
* RE: [PATCH RESEND 1/4] thermal: Use thermal zone device id in netlink messages
From: R, Durgadoss @ 2013-01-02 15:48 UTC (permalink / raw)
To: Eduardo Valentin, Zhang, Rui
Cc: linux-pm@lists.linux-foundation.org, linux-pm@vger.kernel.org
In-Reply-To: <1357140582-8151-2-git-send-email-eduardo.valentin@ti.com>
> -----Original Message-----
> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> owner@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Wednesday, January 02, 2013 9:00 PM
> To: Zhang, Rui
> Cc: R, Durgadoss; linux-pm@lists.linux-foundation.org; linux-
> pm@vger.kernel.org; Eduardo Valentin
> Subject: [PATCH RESEND 1/4] thermal: Use thermal zone device id in netlink
> messages
>
> This patch changes the function thermal_generate_netlink_event
> to receive a thermal zone device instead of a originator id.
>
> This way, the messages will always be bound to a thermal zone.
As you have mentioned, we are planning to deprecate this API.
But, for now, this change is Ok :-)
And I believe all these four patches are on Rui's tree ?
>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
> Documentation/thermal/sysfs-api.txt | 5 +++--
> drivers/thermal/thermal_sys.c | 8 ++++++--
> include/linux/thermal.h | 6 ++++--
> 3 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/thermal/sysfs-api.txt
> b/Documentation/thermal/sysfs-api.txt
> index 88c0233..526d4b9 100644
> --- a/Documentation/thermal/sysfs-api.txt
> +++ b/Documentation/thermal/sysfs-api.txt
> @@ -329,8 +329,9 @@ The framework includes a simple notification
> mechanism, in the form of a
> netlink event. Netlink socket initialization is done during the _init_
> of the framework. Drivers which intend to use the notification mechanism
> just need to call thermal_generate_netlink_event() with two arguments viz
> -(originator, event). Typically the originator will be an integer assigned
> -to a thermal_zone_device when it registers itself with the framework. The
> +(originator, event). The originator is a pointer to struct
> thermal_zone_device
> +from where the event has been originated. An integer which represents
> the
> +thermal zone device will be used in the message to identify the zone. The
> event will be one of:{THERMAL_AUX0, THERMAL_AUX1,
> THERMAL_CRITICAL,
> THERMAL_DEV_FAULT}. Notification can be sent when the current
> temperature
> crosses any of the configured thresholds.
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 8c8ce80..d85f51f 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -1711,7 +1711,8 @@ static struct genl_multicast_group
> thermal_event_mcgrp = {
> .name = THERMAL_GENL_MCAST_GROUP_NAME,
> };
>
> -int thermal_generate_netlink_event(u32 orig, enum events event)
> +int thermal_generate_netlink_event(struct thermal_zone_device *tz,
> + enum events event)
> {
> struct sk_buff *skb;
> struct nlattr *attr;
> @@ -1721,6 +1722,9 @@ int thermal_generate_netlink_event(u32 orig,
> enum events event)
> int result;
> static unsigned int thermal_event_seqnum;
>
> + if (!tz)
> + return -EINVAL;
> +
> /* allocate memory */
> size = nla_total_size(sizeof(struct thermal_genl_event)) +
> nla_total_size(0);
> @@ -1755,7 +1759,7 @@ int thermal_generate_netlink_event(u32 orig,
> enum events event)
>
> memset(thermal_event, 0, sizeof(struct thermal_genl_event));
>
> - thermal_event->orig = orig;
> + thermal_event->orig = tz->id;
> thermal_event->event = event;
>
> /* send multicast genetlink message */
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index fe82022..e85ac70 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -244,9 +244,11 @@ int thermal_register_governor(struct
> thermal_governor *);
> void thermal_unregister_governor(struct thermal_governor *);
>
> #ifdef CONFIG_NET
> -extern int thermal_generate_netlink_event(u32 orig, enum events event);
> +extern int thermal_generate_netlink_event(struct thermal_zone_device
> *tz,
> + enum events event);
> #else
> -static inline int thermal_generate_netlink_event(u32 orig, enum events
> event)
> +static int thermal_generate_netlink_event(struct thermal_zone_device
> *tz,
> + enum events event)
> {
> return 0;
> }
> --
> 1.7.7.1.488.ge8e1c
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 0/7] Support for Multiple sensors per zone
From: Eduardo Valentin @ 2013-01-02 15:48 UTC (permalink / raw)
To: Durgadoss R
Cc: rui.zhang, linux-pm, wni, amit.kachhap, hongbo.zhang,
sachin.kamat
In-Reply-To: <1353149158-19102-1-git-send-email-durgadoss.r@intel.com>
Hello Durga,
First of all, sorry for the late answer. Happy New Year to you BTW. :-)
On 17-11-2012 12:45, Durgadoss R wrote:
> This patch series attempts to add support for multiple
> sensors per zone. The work is based on the Thermal discussion
> happened in plumbers conference 2012, here:
> http://www.linuxplumbersconf.org/2012/schedule/
> Title: "Enhancing the Thermal Management Infrastructure in Linux"
>
On the above discussion one point which was not really clear was if we
would create virtual thermal zones, with a fop to determine its
temperature in a given time, or if we would write APIs to fetch
temperature from a thermal zone and then in the platform code to would
derive the real temperature.
From this patch series, looks like we are going to both directions at
the same time. Let me try to understand your proposal by introducing a
simple example.
Let us assume a simple scenario which we have a thermal zone with 2
sensors, say, for skin management, one for back cover and one for LCD.
Assume also you have two different HW sensors, for whatever reason. By
your proposal, we would have two simple sensor drivers, one for each HW,
which is good. A platform driver that would add these two sensor
instances into a thermal zone.
Now. what I don't know is how to determine the temperature of that zone.
I believe we need to have a thermal zone fops with get temperature. I am
assuming the platform driver would be the one who introduces the thermal
zone, and adds the sensors, and knows how to determine the temperature
of that zone. This way, one can easily write a function to determine the
"summary temperature". Remember that using index to select one specific
temperature sensor for a given time may not be enough, as there are
scenarios in which one may write an equation which uses all sensors
temperature values to determine the ending zone temperature.
> The intention is to make it easy for generic sensor drivers
> to register with the framework, and let them participate in
> platform thermal management. Another goal is to expose the
> binding information in a consistent way so that user space
> can consume the information and potentially manage platform thermals.
>
> This series contains 7 patches:
> Patch 1/7: Creates new sensor level APIs
> Patch 2/7: Creates new zone level APIs. The existing tzd structure is
> kept as such for clarity and compatibility purposes.
> Patch 3/7: Creates functions to add/remove a cdev to/from a zone. The
> existing tcd structure need not be modified.
> Patch 4/7: Adds a thermal_trip sysfs node, which exposes various trip
> points for all sensors present in a zone.
> Patch 5/7: Adds a thermal_map sysfs node. It is a compact representation
> of the binding relationship between a sensor and a cdev,
> within a zone.
> Patch 6/7: Creates Documentation for the new APIs. A new file is
> created for clarity. Final goal is to merge with the existing
> file or refactor the files, as whatever seems appropriate.
> Patch 7/7: A dummy driver that can be used for testing. This is not for merge.
>
> Next steps:
> 1. Move all the existing drivers to the new implementation model.
> Help welcomed from individual driver authors/maintainers for this.
> 2. Make the thermal governors work with this new model.
> 3. Remove old/unused code from thermal_sys.c.
> 4. Add more detailed documentation
>
> I didn't want to submit patches for all these in one-go, since it
> might end-up being difficult to comprehend, besides delaying the
> review process. The other obvious reason being I cannot test all
> the changes on various drivers for 1.
>
> All these patches have been tested on a Core-i5 desktop running
> ubuntu 12.04 and an atom notebook running ubuntu 11.10.
> Kindly help review.
>
> Durgadoss R (7):
> Thermal: Create sensor level APIs
> Thermal: Create zone level APIs
> Thermal: Add APIs to bind cdev to new zone structure
> Thermal: Add Thermal_trip sysfs node
> Thermal: Add 'thermal_map' sysfs node
> Thermal: Add Documentation to new APIs
> Thermal: Dummy driver used for testing
>
> Documentation/thermal/sysfs-api2.txt | 213 ++++++++
> drivers/thermal/Kconfig | 5 +
> drivers/thermal/Makefile | 3 +
> drivers/thermal/thermal_sys.c | 915 ++++++++++++++++++++++++++++++++++
> drivers/thermal/thermal_test.c | 321 ++++++++++++
> include/linux/thermal.h | 118 +++++
> 6 files changed, 1575 insertions(+)
> create mode 100644 Documentation/thermal/sysfs-api2.txt
> create mode 100644 drivers/thermal/thermal_test.c
>
^ permalink raw reply
* [PATCH RESEND 4/4] thermal: check for invalid trip setup when registering thermal device
From: Eduardo Valentin @ 2013-01-02 15:29 UTC (permalink / raw)
To: rui.zhang; +Cc: durgadoss.r, linux-pm, linux-pm, Eduardo Valentin
In-Reply-To: <1357140582-8151-1-git-send-email-eduardo.valentin@ti.com>
This patch adds an extra check in the data structure while registering
a thermal device. The check is to avoid registering zones with a number
of trips greater than zero, but with no .get_trip_temp nor .get_trip_type
callbacks. Receiving such data structure may end in wrong data access.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
drivers/thermal/thermal_sys.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index fba27c3..0a1bf6b 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -1530,6 +1530,9 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type,
if (!ops || !ops->get_temp)
return ERR_PTR(-EINVAL);
+ if (trips > 0 && !ops->get_trip_type)
+ return ERR_PTR(-EINVAL);
+
tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL);
if (!tz)
return ERR_PTR(-ENOMEM);
--
1.7.7.1.488.ge8e1c
^ permalink raw reply related
* [PATCH RESEND 3/4] thermal: cleanup: use dev_* helper functions
From: Eduardo Valentin @ 2013-01-02 15:29 UTC (permalink / raw)
To: rui.zhang; +Cc: durgadoss.r, linux-pm, linux-pm, Eduardo Valentin
In-Reply-To: <1357140582-8151-1-git-send-email-eduardo.valentin@ti.com>
Change the logging messages to used dev_* helper functions.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
drivers/thermal/thermal_sys.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 70ce100..fba27c3 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -354,8 +354,9 @@ static void handle_critical_trips(struct thermal_zone_device *tz,
tz->ops->notify(tz, trip, trip_type);
if (trip_type == THERMAL_TRIP_CRITICAL) {
- pr_emerg("Critical temperature reached(%d C),shutting down\n",
- tz->temperature / 1000);
+ dev_emerg(&tz->device,
+ "critical temperature reached(%d C),shutting down\n",
+ tz->temperature / 1000);
orderly_poweroff(true);
}
}
@@ -386,7 +387,8 @@ static void update_temperature(struct thermal_zone_device *tz)
ret = tz->ops->get_temp(tz, &temp);
if (ret) {
- pr_warn("failed to read out thermal zone %d\n", tz->id);
+ dev_warn(&tz->device, "failed to read out thermal zone %d\n",
+ tz->id);
goto exit;
}
@@ -1770,7 +1772,7 @@ int thermal_generate_netlink_event(struct thermal_zone_device *tz,
result = genlmsg_multicast(skb, 0, thermal_event_mcgrp.id, GFP_ATOMIC);
if (result)
- pr_info("failed to send netlink event:%d\n", result);
+ dev_err(&tz->device, "Failed to send netlink event:%d", result);
return result;
}
--
1.7.7.1.488.ge8e1c
^ permalink raw reply related
* [PATCH RESEND 2/4] thermal: remove unnecessary include
From: Eduardo Valentin @ 2013-01-02 15:29 UTC (permalink / raw)
To: rui.zhang; +Cc: durgadoss.r, linux-pm, linux-pm, Eduardo Valentin
In-Reply-To: <1357140582-8151-1-git-send-email-eduardo.valentin@ti.com>
No need for spinlocks in this file, then removing its header.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
drivers/thermal/thermal_sys.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index d85f51f..70ce100 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -32,7 +32,6 @@
#include <linux/kdev_t.h>
#include <linux/idr.h>
#include <linux/thermal.h>
-#include <linux/spinlock.h>
#include <linux/reboot.h>
#include <net/netlink.h>
#include <net/genetlink.h>
--
1.7.7.1.488.ge8e1c
^ permalink raw reply related
* [PATCH RESEND 1/4] thermal: Use thermal zone device id in netlink messages
From: Eduardo Valentin @ 2013-01-02 15:29 UTC (permalink / raw)
To: rui.zhang; +Cc: durgadoss.r, linux-pm, linux-pm, Eduardo Valentin
In-Reply-To: <1357140582-8151-1-git-send-email-eduardo.valentin@ti.com>
This patch changes the function thermal_generate_netlink_event
to receive a thermal zone device instead of a originator id.
This way, the messages will always be bound to a thermal zone.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
Documentation/thermal/sysfs-api.txt | 5 +++--
drivers/thermal/thermal_sys.c | 8 ++++++--
include/linux/thermal.h | 6 ++++--
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index 88c0233..526d4b9 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -329,8 +329,9 @@ The framework includes a simple notification mechanism, in the form of a
netlink event. Netlink socket initialization is done during the _init_
of the framework. Drivers which intend to use the notification mechanism
just need to call thermal_generate_netlink_event() with two arguments viz
-(originator, event). Typically the originator will be an integer assigned
-to a thermal_zone_device when it registers itself with the framework. The
+(originator, event). The originator is a pointer to struct thermal_zone_device
+from where the event has been originated. An integer which represents the
+thermal zone device will be used in the message to identify the zone. The
event will be one of:{THERMAL_AUX0, THERMAL_AUX1, THERMAL_CRITICAL,
THERMAL_DEV_FAULT}. Notification can be sent when the current temperature
crosses any of the configured thresholds.
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 8c8ce80..d85f51f 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -1711,7 +1711,8 @@ static struct genl_multicast_group thermal_event_mcgrp = {
.name = THERMAL_GENL_MCAST_GROUP_NAME,
};
-int thermal_generate_netlink_event(u32 orig, enum events event)
+int thermal_generate_netlink_event(struct thermal_zone_device *tz,
+ enum events event)
{
struct sk_buff *skb;
struct nlattr *attr;
@@ -1721,6 +1722,9 @@ int thermal_generate_netlink_event(u32 orig, enum events event)
int result;
static unsigned int thermal_event_seqnum;
+ if (!tz)
+ return -EINVAL;
+
/* allocate memory */
size = nla_total_size(sizeof(struct thermal_genl_event)) +
nla_total_size(0);
@@ -1755,7 +1759,7 @@ int thermal_generate_netlink_event(u32 orig, enum events event)
memset(thermal_event, 0, sizeof(struct thermal_genl_event));
- thermal_event->orig = orig;
+ thermal_event->orig = tz->id;
thermal_event->event = event;
/* send multicast genetlink message */
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index fe82022..e85ac70 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -244,9 +244,11 @@ int thermal_register_governor(struct thermal_governor *);
void thermal_unregister_governor(struct thermal_governor *);
#ifdef CONFIG_NET
-extern int thermal_generate_netlink_event(u32 orig, enum events event);
+extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
+ enum events event);
#else
-static inline int thermal_generate_netlink_event(u32 orig, enum events event)
+static int thermal_generate_netlink_event(struct thermal_zone_device *tz,
+ enum events event)
{
return 0;
}
--
1.7.7.1.488.ge8e1c
^ permalink raw reply related
* [PATCH RESEND 0/4] thermal sys: couple of fixes and cleanups
From: Eduardo Valentin @ 2013-01-02 15:29 UTC (permalink / raw)
To: rui.zhang; +Cc: durgadoss.r, linux-pm, linux-pm, Eduardo Valentin
Hello Rui,
Here is a couple of fixes and cleanups on the thermal_sys.c.
I am resending this series because it has been idling in the mainling list
for some months already. So, before we forget them, I decided to resend.
Again, one important change is the netlink channel, which I am proposing
to have the zone id in each message.
So far, looks like we can deprecate this API, but in this series, I keep
it but now every message has the zone id.
All best,
Eduardo Valentin (4):
thermal: Use thermal zone device id in netlink messages
thermal: remove unnecessary include
thermal: cleanup: use dev_* helper functions
thermal: check for invalid trip setup when registering thermal device
Documentation/thermal/sysfs-api.txt | 5 +++--
drivers/thermal/thermal_sys.c | 22 +++++++++++++++-------
include/linux/thermal.h | 6 ++++--
3 files changed, 22 insertions(+), 11 deletions(-)
--
1.7.7.1.488.ge8e1c
^ permalink raw reply
* Re: [PATCH 1/3] cpufreq: Manage only online cpus
From: Viresh Kumar @ 2013-01-02 6:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linaro-dev, nicolas.pitre, amit.kucheria, mathieu.poirier,
linux-kernel, cpufreq, pdsw-power-team, linux-pm
In-Reply-To: <CAKohpomfEHGrCdbZ-EakRN4=qF8epd5seX5TWRcErQj9BEFpNA@mail.gmail.com>
On 16 December 2012 19:07, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 16 December 2012 18:34, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> Well, this series makes sense to me, but I'd like to hear what the other people
>> think.
>
> That sounds great :)
>
> Some more information for others about how i reached to these issues
> is present here:
>
> https://lkml.org/lkml/2012/12/10/44
Hmm.. I don't know, if we are going to get any feedback from others :(
BTW, i consider them as fixes and so would make sense to get them in next rc.
What do you think?
--
viresh
^ permalink raw reply
* Re: [PATCH V2] Fix problem with cpufreq_ondemand or cpufreq_conservative
From: Viresh Kumar @ 2013-01-02 4:12 UTC (permalink / raw)
To: Larry Finger; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list, LKML
In-Reply-To: <50E3B32A.8070807@lwfinger.net>
On 2 January 2013 09:40, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>> Index: wireless-testing-new/drivers/cpufreq/cpufreq_governor.c
>>
>>
>> How are you creating these patches? wireless-testing-new (linux directory
>> names)
>> aren't supposed to be present here.
You Missed this one?
> I was not adding myself - my name is not Alexander Clouter. When we were
> creating a new module, I got the author from the module that
> cpufreq_governor was originally a part. Perhaps I got the name wrong.
Err.. I read it wrong... sorry :)
^ permalink raw reply
* Re: [PATCH V2] Fix problem with cpufreq_ondemand or cpufreq_conservative
From: Larry Finger @ 2013-01-02 4:10 UTC (permalink / raw)
To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list, LKML
In-Reply-To: <CAOh2x==ER3j7P1U+VQEtv00LWWa8JJHu=22--+gTUPFdhiC_cQ@mail.gmail.com>
On 01/01/2013 09:56 PM, Viresh Kumar wrote:
> I know, V4 is already accepted, but i had an small comment with one
> of your earlier change, which doesn't exist anymore :)
>
> On Sat, Dec 29, 2012 at 5:51 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> Index: wireless-testing-new/drivers/cpufreq/cpufreq_governor.c
>
> How are you creating these patches? wireless-testing-new (linux directory names)
> aren't supposed to be present here.
>
>> ===================================================================
>> --- wireless-testing-new.orig/drivers/cpufreq/cpufreq_governor.c
>> +++ wireless-testing-new/drivers/cpufreq/cpufreq_governor.c
>> @@ -316,3 +316,8 @@ second_time:
>> return 0;
>> }
>> EXPORT_SYMBOL_GPL(cpufreq_governor_dbs);
>> +
>> +MODULE_AUTHOR("Alexander Clouter <alex@digriz.org.uk>");
>
> You shouldn't be adding yourself as author here :)
>
> MODULE_AUTHOR("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
> MODULE_AUTHOR("Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>");
I was not adding myself - my name is not Alexander Clouter. When we were
creating a new module, I got the author from the module that cpufreq_governor
was originally a part. Perhaps I got the name wrong.
Thanks for the review mentioned in the next Email.
Larry
^ permalink raw reply
* Re: [PATCH V3] Fix problem with cpufreq_ondemand or cpufreq_conservative
From: Viresh Kumar @ 2013-01-02 3:57 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Larry Finger, fabio.baltieri, linux-kernel, linux-pm
In-Reply-To: <2035804.da5iyiYDGE@vostro.rjw.lan>
On Sat, Dec 29, 2012 at 6:57 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday, December 28, 2012 07:55:20 PM Larry Finger wrote:
>> V3 changes only Kconfig and Makefile and avoids creating a new module.
>
> OK, thanks for the patch!
>
> If you don't mind, I'll rename CONFIG_CPU_FREQ_GOVERNOR to
> CONFIG_CPU_FREQ_GOV_COMMON when applying it, though.
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* Re: [PATCH V2] Fix problem with cpufreq_ondemand or cpufreq_conservative
From: Viresh Kumar @ 2013-01-02 3:56 UTC (permalink / raw)
To: Larry Finger; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list, LKML
In-Reply-To: <50DE378D.4090008@lwfinger.net>
I know, V4 is already accepted, but i had an small comment with one
of your earlier change, which doesn't exist anymore :)
On Sat, Dec 29, 2012 at 5:51 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Index: wireless-testing-new/drivers/cpufreq/cpufreq_governor.c
How are you creating these patches? wireless-testing-new (linux directory names)
aren't supposed to be present here.
> ===================================================================
> --- wireless-testing-new.orig/drivers/cpufreq/cpufreq_governor.c
> +++ wireless-testing-new/drivers/cpufreq/cpufreq_governor.c
> @@ -316,3 +316,8 @@ second_time:
> return 0;
> }
> EXPORT_SYMBOL_GPL(cpufreq_governor_dbs);
> +
> +MODULE_AUTHOR("Alexander Clouter <alex@digriz.org.uk>");
You shouldn't be adding yourself as author here :)
MODULE_AUTHOR("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
MODULE_AUTHOR("Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>");
^ permalink raw reply
* Re: [PATCH] cpuidle - fix lock contention in the idle path
From: Russ Anderson @ 2012-12-31 15:08 UTC (permalink / raw)
To: Daniel Lezcano
Cc: rafael.j.wysocki, linux-pm, pdeschrijver, akpm, linux-kernel, rja
In-Reply-To: <50DEBFD7.5000104@linaro.org>
On Sat, Dec 29, 2012 at 11:03:03AM +0100, Daniel Lezcano wrote:
>
> Hi Russ,
>
> Is it possible you try this patch on your 2048 cpus ?
Yes, I will try it later today.
Thanks
> Thanks
>
> -- Daniel
>
> On 12/26/2012 11:01 AM, Daniel Lezcano wrote:
> > The commit bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92 introduces
> > a lock in the cpuidle_get_cpu_driver function. This function
> > is used in the idle_call function.
> >
> > The problem is the contention with a large number of cpus because
> > they try to access the idle routine at the same time.
> >
> > The lock could be safely removed because of how is used the
> > cpuidle api. The cpuidle_register_driver is called first but
> > until the cpuidle_register_device is not called we don't
> > enter in the cpuidle idle call function because the device
> > is not enabled.
> >
> > The cpuidle_unregister_driver function, leading the a NULL driver,
> > is not called before the cpuidle_unregister_device.
> >
> > This is how is used the cpuidle api from the different drivers.
> >
> > However, a cleanup around the lock and a proper refcounting
> > mechanism should be used to ensure the consistency in the api,
> > like cpuidle_unregister_driver should failed if its refcounting
> > is not 0.
> >
> > These modifications will need some code reorganization and rewrite
> > which does not fit with a fix.
> >
> > The following patch is a hot fix by returning to the initial behavior
> > by removing the lock when getting the driver.
> >
> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > ---
> > drivers/cpuidle/driver.c | 8 +-------
> > 1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> > index 3af841f..c2b281a 100644
> > --- a/drivers/cpuidle/driver.c
> > +++ b/drivers/cpuidle/driver.c
> > @@ -235,16 +235,10 @@ EXPORT_SYMBOL_GPL(cpuidle_get_driver);
> > */
> > struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
> > {
> > - struct cpuidle_driver *drv;
> > -
> > if (!dev)
> > return NULL;
> >
> > - spin_lock(&cpuidle_driver_lock);
> > - drv = __cpuidle_get_cpu_driver(dev->cpu);
> > - spin_unlock(&cpuidle_driver_lock);
> > -
> > - return drv;
> > + return __cpuidle_get_cpu_driver(dev->cpu);
> > }
> > EXPORT_SYMBOL_GPL(cpuidle_get_cpu_driver);
> >
> >
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@sgi.com
^ permalink raw reply
* Re: [PATCH] ARM: EXYNOS5: Support Exynos5-bus devfreq driver
From: Abhilash Kesavan @ 2012-12-31 2:12 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-kernel, linux-pm, kgene.kim, myungjoo.ham, kyungmin.park,
rjw, jhbird.choi
In-Reply-To: <20121230061542.GA21331@quad.lixom.net>
On Sun, Dec 30, 2012 at 11:45 AM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
Hi Olof,
>> +# ppmu support
>> +
>> +obj-$(CONFIG_EXYNOS5250_PPMU) += exynos_ppmu.o exynos5_ppmu.o
>
> Quite obvious that it's ppmu support from the file names. No need for
> a comment.
Will improve the commenting in the file.
Also, will fix the whitespace, empty lines in the file.
>
>> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
>> index 578a610..a285080 100644
>> --- a/arch/arm/mach-exynos/common.c
>> +++ b/arch/arm/mach-exynos/common.c
>> @@ -308,6 +308,31 @@ static struct map_desc exynos5_iodesc[] __initdata = {
>> .pfn = __phys_to_pfn(EXYNOS5_PA_UART),
>> .length = SZ_512K,
>> .type = MT_DEVICE,
>> + }, {
>> + .virtual = (unsigned long)S5P_VA_PPMU_CPU,
>> + .pfn = __phys_to_pfn(EXYNOS5_PA_PPMU_CPU),
>> + .length = SZ_8K,
>> + .type = MT_DEVICE,
>> + }, {
>> + .virtual = (unsigned long)S5P_VA_PPMU_DDR_C,
>> + .pfn = __phys_to_pfn(EXYNOS5_PA_PPMU_DDR_C),
>> + .length = SZ_8K,
>> + .type = MT_DEVICE,
>> + }, {
>> + .virtual = (unsigned long)S5P_VA_PPMU_DDR_R1,
>> + .pfn = __phys_to_pfn(EXYNOS5_PA_PPMU_DDR_R1),
>> + .length = SZ_8K,
>> + .type = MT_DEVICE,
>> + }, {
>> + .virtual = (unsigned long)S5P_VA_PPMU_DDR_L,
>> + .pfn = __phys_to_pfn(EXYNOS5_PA_PPMU_DDR_L),
>> + .length = SZ_8K,
>> + .type = MT_DEVICE,
>> + }, {
>> + .virtual = (unsigned long)S5P_VA_PPMU_RIGHT,
>> + .pfn = __phys_to_pfn(EXYNOS5_PA_PPMU_RIGHT),
>> + .length = SZ_8K,
>> + .type = MT_DEVICE,
>> },
>
> You should add the ppmu device to the device tree, and get the addresses from
> there instead (via ioremap).
>
> That way you can make this driver probe using regular methods too.
Will re-work to remove these static mappings.
>
>> +
>> +#include <mach/exynos_ppmu.h>
>> +#include <mach/exynos5_ppmu.h>
>
> Can you avoid adding new mach includes for this, perhaps? We're working hard on
> removing them for all platforms, even though exynos is lagging behind on it.
> Local defines that are used in just one C file can either go in that file, or
> in a header file that sits next to it instead of in the shared directory. For
> the devfreq driver, include/linux/* is a better location.
Will do.
>
>> +#define FIXED_POINT_OFFSET 8
>> +#define FIXED_POINT_MASK ((1 << FIXED_POINT_OFFSET) - 1)
>
> 0xff. Easier to read for a single entry like this.
OK
Thanks,
Abhilash
^ permalink raw reply
* Re: [PATCH RFC] PM/Devfreq: Add Exynos5-bus devfreq driver for Exynos5250.
From: Abhilash Kesavan @ 2012-12-31 2:11 UTC (permalink / raw)
To: Olof Johansson
Cc: myungjoo.ham, kyungmin.park, rjw, linux-kernel, linux-pm,
kgene.kim, jhbird.choi
In-Reply-To: <20121230061843.GB21331@quad.lixom.net>
Hi,
[...]
> Why can't they be in drivers/busfreq? Create a subdirectory for
> platform-specific subdrivers if needed, but they definitiely do NOT
> belong in drivers/misc, and there seems to be little reason to have them
> in arch/arm.
Myungjoo, can you please indicate your preference with respect to where
I should place the PPMU driver. I'll re-work based on that.
Abhilash
^ 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