How to use the generic thermal sysfs.

How to use the generic thermal sysfs.

[Wei Ni]

Hi, all
I'm working on the tegra thermal throttling upstream issue.
The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is
the sensor driver. We want to use the generic thermal sysfs.
 
My question is where should we register the thermal zone device? We may
have two place to do it:
1. register it in the sensor driver, such as lm90.c
In this way, the sensor driver doesn't need to export any APIs, such as
get_temp.
2. register in my tegra thermal framework.
In this way, the sensor driver need to export some APIs, which are used
to register the ops and do any other things.

How should I do it?

And in current codes, there have the event notification, in the form of
a netlink event. But it's difficult to be used in the kernel, it's
normally for the communication with user-space. How about to add a
notify call chain for it? So when the sensor has irq alert, it can send
a notify to my thermal framework in kernel.

Do anyone has suggestions?

Thanks.
Wei.

---
nvpublic

How to use the generic thermal sysfs.

[Wei Ni]

Hi, all
I'm working on the tegra thermal throttling upstream issue.
The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is
the sensor driver. We want to use the generic thermal sysfs.
 
My question is where should we register the thermal zone device? We may
have two place to do it:
1. register it in the sensor driver, such as lm90.c
In this way, the sensor driver doesn't need to export any APIs, such as
get_temp.
2. register in my tegra thermal framework.
In this way, the sensor driver need to export some APIs, which are used
to register the ops and do any other things.

How should I do it?

And in current codes, there have the event notification, in the form of
a netlink event. But it's difficult to be used in the kernel, it's
normally for the communication with user-space. How about to add a
notify call chain for it? So when the sensor has irq alert, it can send
a notify to my thermal framework in kernel.

Do anyone has suggestions?

Thanks.
Wei.

---
nvpublic

RE: How to use the generic thermal sysfs.

[R, Durgadoss]

Hi,

> -----Original Message-----
> From: Wei Ni [mailto:wni@nvidia.com]
> Sent: Thursday, July 12, 2012 3:53 PM
> To: Zhang, Rui; Brown, Len; akpm@linux-foundation.org; khali@linux-fr.org;
> joe@perches.com; R, Durgadoss
> Cc: linux-kernel@vger.kernel.org; linux-tegra@ger.kernel.org;
> acourbot@nvidia.com
> Subject: How to use the generic thermal sysfs.
> 
> Hi, all
> I'm working on the tegra thermal throttling upstream issue.
> The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is
> the sensor driver. We want to use the generic thermal sysfs.
> 
> My question is where should we register the thermal zone device? We may
> have two place to do it:
> 1. register it in the sensor driver, such as lm90.c
> In this way, the sensor driver doesn't need to export any APIs, such as
> get_temp.

This approach is preferred.

> 2. register in my tegra thermal framework.
> In this way, the sensor driver need to export some APIs, which are used
> to register the ops and do any other things.

What do you mean by "my tegra thermal framework" ? Where does the source
file for this sit in the mainline kernel ?

> 
> How should I do it?
> 
> And in current codes, there have the event notification, in the form of
> a netlink event. But it's difficult to be used in the kernel, it's
> normally for the communication with user-space. How about to add a
> notify call chain for it? So when the sensor has irq alert, it can send
> a notify to my thermal framework in kernel.

We are working on a notification API from any generic sensor driver to
the thermal framework.
Please have a look at the 'notify_thermal_framework' API in the patch here:
http://www.spinics.net/lists/linux-acpi/msg36049.html

Thanks,
Durga

RE: How to use the generic thermal sysfs.

[R, Durgadoss]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1889 bytes --]

Hi,

> -----Original Message-----
> From: Wei Ni [mailto:wni@nvidia.com]
> Sent: Thursday, July 12, 2012 3:53 PM
> To: Zhang, Rui; Brown, Len; akpm@linux-foundation.org; khali@linux-fr.org;
> joe@perches.com; R, Durgadoss
> Cc: linux-kernel@vger.kernel.org; linux-tegra@ger.kernel.org;
> acourbot@nvidia.com
> Subject: How to use the generic thermal sysfs.
> 
> Hi, all
> I'm working on the tegra thermal throttling upstream issue.
> The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is
> the sensor driver. We want to use the generic thermal sysfs.
> 
> My question is where should we register the thermal zone device? We may
> have two place to do it:
> 1. register it in the sensor driver, such as lm90.c
> In this way, the sensor driver doesn't need to export any APIs, such as
> get_temp.

This approach is preferred.

> 2. register in my tegra thermal framework.
> In this way, the sensor driver need to export some APIs, which are used
> to register the ops and do any other things.

What do you mean by "my tegra thermal framework" ? Where does the source
file for this sit in the mainline kernel ?

> 
> How should I do it?
> 
> And in current codes, there have the event notification, in the form of
> a netlink event. But it's difficult to be used in the kernel, it's
> normally for the communication with user-space. How about to add a
> notify call chain for it? So when the sensor has irq alert, it can send
> a notify to my thermal framework in kernel.

We are working on a notification API from any generic sensor driver to
the thermal framework.
Please have a look at the 'notify_thermal_framework' API in the patch here:
http://www.spinics.net/lists/linux-acpi/msg36049.html

Thanks,
Durga

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: How to use the generic thermal sysfs.

[Zhang Rui]

On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote:
> Hi,
> 
> > -----Original Message-----
> > From: Wei Ni [mailto:wni@nvidia.com]
> > Sent: Thursday, July 12, 2012 3:53 PM
> > To: Zhang, Rui; Brown, Len; akpm@linux-foundation.org; khali@linux-fr.org;
> > joe@perches.com; R, Durgadoss
> > Cc: linux-kernel@vger.kernel.org; linux-tegra@ger.kernel.org;
> > acourbot@nvidia.com
> > Subject: How to use the generic thermal sysfs.
> > 
> > Hi, all
> > I'm working on the tegra thermal throttling upstream issue.
> > The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is
> > the sensor driver. We want to use the generic thermal sysfs.
> > 
> > My question is where should we register the thermal zone device? We may
> > have two place to do it:
> > 1. register it in the sensor driver, such as lm90.c
> > In this way, the sensor driver doesn't need to export any APIs, such as
> > get_temp.
> 
> This approach is preferred.
> 
> > 2. register in my tegra thermal framework.
> > In this way, the sensor driver need to export some APIs, which are used
> > to register the ops and do any other things.
> 
> What do you mean by "my tegra thermal framework" ? Where does the source
> file for this sit in the mainline kernel ?
> 
I have the same question.
It sounds like that you want to use the tegra thermal framework to do
thermal management instead of the generic thermal layer, right?

IMO, the purpose of the generic thermal layer is
1) do kernel thermal management
2) export unique sysfs I/F to userspace so that users/userspace
applications can take over the thermal management.

what is the benefit to have another driver to do thermal management in
kernel?
If the current thermal management in the generic thermal layer can not
work well on your platform, it is a good chance to enhance the kernel
thermal manager. :)

thanks,
rui

> > 
> > How should I do it?
> > 
> > And in current codes, there have the event notification, in the form of
> > a netlink event. But it's difficult to be used in the kernel, it's
> > normally for the communication with user-space. How about to add a
> > notify call chain for it? So when the sensor has irq alert, it can send
> > a notify to my thermal framework in kernel.
> 
> We are working on a notification API from any generic sensor driver to
> the thermal framework.
> Please have a look at the 'notify_thermal_framework' API in the patch here:
> http://www.spinics.net/lists/linux-acpi/msg36049.html
> 
> Thanks,
> Durga
> 

Re: How to use the generic thermal sysfs.

[Alex Courbot]

On 07/12/2012 07:54 PM, R, Durgadoss wrote:
> We are working on a notification API from any generic sensor driver to
> the thermal framework.
> Please have a look at the 'notify_thermal_framework' API in the patch here:
> http://www.spinics.net/lists/linux-acpi/msg36049.html

At first sight these patches look close to what we need as well. Are you 
considering to support the definitions of thermal zones using the device 
tree? Is there a public git tree where we can pull the latest version of 
this code in order to keep in sync with you guys?

Thanks,
Alex.

RE: How to use the generic thermal sysfs.

[R, Durgadoss]

> -----Original Message-----
> From: Alex Courbot [mailto:acourbot@nvidia.com]
> Sent: Friday, July 13, 2012 11:19 AM
> To: R, Durgadoss
> Cc: Wei Ni; Zhang, Rui; Brown, Len; akpm@linux-foundation.org; khali@linux-
> fr.org; joe@perches.com; linux-kernel@vger.kernel.org; linux-
> tegra@ger.kernel.org
> Subject: Re: How to use the generic thermal sysfs.
> 
> On 07/12/2012 07:54 PM, R, Durgadoss wrote:
> > We are working on a notification API from any generic sensor driver to
> > the thermal framework.
> > Please have a look at the 'notify_thermal_framework' API in the patch here:
> > http://www.spinics.net/lists/linux-acpi/msg36049.html
> 
> At first sight these patches look close to what we need as well. Are you
> considering to support the definitions of thermal zones using the device
> tree? Is there a public git tree where we can pull the latest version of
> this code in order to keep in sync with you guys?

As of now, we are getting the definitions done through the platform layer
data. Considerations for device tree .. yes.. but I do not have any sample
implementation..

On the public tree:
Rui is trying to get a public tree from where we can pull Thermal subsystem
changes; and submit patches against this tree.

I hope Rui will publish the link very soon :-)

Thanks,
Durga

RE: How to use the generic thermal sysfs.

[R, Durgadoss]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1458 bytes --]

> -----Original Message-----
> From: Alex Courbot [mailto:acourbot@nvidia.com]
> Sent: Friday, July 13, 2012 11:19 AM
> To: R, Durgadoss
> Cc: Wei Ni; Zhang, Rui; Brown, Len; akpm@linux-foundation.org; khali@linux-
> fr.org; joe@perches.com; linux-kernel@vger.kernel.org; linux-
> tegra@ger.kernel.org
> Subject: Re: How to use the generic thermal sysfs.
> 
> On 07/12/2012 07:54 PM, R, Durgadoss wrote:
> > We are working on a notification API from any generic sensor driver to
> > the thermal framework.
> > Please have a look at the 'notify_thermal_framework' API in the patch here:
> > http://www.spinics.net/lists/linux-acpi/msg36049.html
> 
> At first sight these patches look close to what we need as well. Are you
> considering to support the definitions of thermal zones using the device
> tree? Is there a public git tree where we can pull the latest version of
> this code in order to keep in sync with you guys?

As of now, we are getting the definitions done through the platform layer
data. Considerations for device tree .. yes.. but I do not have any sample
implementation..

On the public tree:
Rui is trying to get a public tree from where we can pull Thermal subsystem
changes; and submit patches against this tree.

I hope Rui will publish the link very soon :-)

Thanks,
Durga
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: How to use the generic thermal sysfs.

[Alex Courbot]

On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote:
> As of now, we are getting the definitions done through the platform layer
> data. Considerations for device tree .. yes.. but I do not have any sample
> implementation..

Maybe we can help with that then, since we are going to need it.

> On the public tree:
> Rui is trying to get a public tree from where we can pull Thermal subsystem
> changes; and submit patches against this tree.
>
> I hope Rui will publish the link very soon :-)

Excellent. Could you keep us posted when this happens?

Thanks!
Alex.

Re: How to use the generic thermal sysfs.

[Zhang Rui]

On 五, 2012-07-13 at 15:08 +0900, Alex Courbot wrote:
> On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote:
> > As of now, we are getting the definitions done through the platform layer
> > data. Considerations for device tree .. yes.. but I do not have any sample
> > implementation..
> 
> Maybe we can help with that then, since we are going to need it.
> 
> > On the public tree:
> > Rui is trying to get a public tree from where we can pull Thermal subsystem
> > changes; and submit patches against this tree.
> >
> > I hope Rui will publish the link very soon :-)
> 
> Excellent. Could you keep us posted when this happens?
> 
sure.
I'm just working on a patch set and I hope to push them to
git.kernel.org by next week.

thanks,
rui

RE: How to use the generic thermal sysfs.

[Wei Ni]

On Fri, 2012-07-13 at 09:51 +0800, Zhang Rui wrote:
> On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote:
> > Hi,
> > 
> > > -----Original Message-----
> > > From: Wei Ni [mailto:wni@nvidia.com]
> > > Sent: Thursday, July 12, 2012 3:53 PM
> > > To: Zhang, Rui; Brown, Len; akpm@linux-foundation.org; khali@linux-fr.org;
> > > joe@perches.com; R, Durgadoss
> > > Cc: linux-kernel@vger.kernel.org; linux-tegra@ger.kernel.org;
> > > acourbot@nvidia.com
> > > Subject: How to use the generic thermal sysfs.
> > > 
> > > Hi, all
> > > I'm working on the tegra thermal throttling upstream issue.
> > > The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is
> > > the sensor driver. We want to use the generic thermal sysfs.
> > > 
> > > My question is where should we register the thermal zone device? We may
> > > have two place to do it:
> > > 1. register it in the sensor driver, such as lm90.c
> > > In this way, the sensor driver doesn't need to export any APIs, such as
> > > get_temp.
> > 
> > This approach is preferred.
> > 
> > > 2. register in my tegra thermal framework.
> > > In this way, the sensor driver need to export some APIs, which are used
> > > to register the ops and do any other things.
> > 
> > What do you mean by "my tegra thermal framework" ? Where does the source
> > file for this sit in the mainline kernel ?
> > 
> I have the same question.
> It sounds like that you want to use the tegra thermal framework to do
> thermal management instead of the generic thermal layer, right?
> 
> IMO, the purpose of the generic thermal layer is
> 1) do kernel thermal management
> 2) export unique sysfs I/F to userspace so that users/userspace
> applications can take over the thermal management.
> 
> what is the benefit to have another driver to do thermal management in
> kernel?
> If the current thermal management in the generic thermal layer can not
> work well on your platform, it is a good chance to enhance the kernel
> thermal manager. :)

Our tegra thermal framework also will use the generic thermal layer. It
will register the cooling device, and run the throttling in this generic
framework.
But we have a special mechanism, when the temp is below the trip temp,
we will set different cpu capability for different temp range. For
example, set the low/high temp as 20C/30C to the sensor, and set the cpu
to the max capability, it mean the cpu can run up to the max freq and
voltage in this temp range. if the temp is out that range, the sensor
will have irq/alert to notify the tegra framework, then we will set to
another temperature range and cpu capability.
I think we can try to add this mechanism to the generic framework as a
new policy, right?

> 
> thanks,
> rui
> 
> > > 
> > > How should I do it?
> > > 
> > > And in current codes, there have the event notification, in the form of
> > > a netlink event. But it's difficult to be used in the kernel, it's
> > > normally for the communication with user-space. How about to add a
> > > notify call chain for it? So when the sensor has irq alert, it can send
> > > a notify to my thermal framework in kernel.
> > 
> > We are working on a notification API from any generic sensor driver to
> > the thermal framework.
> > Please have a look at the 'notify_thermal_framework' API in the patch here:
> > http://www.spinics.net/lists/linux-acpi/msg36049.html

It's cool. I will cherry pick them to run it.

> > 
> > Thanks,
> > Durga
> > 
> 
> 

RE: How to use the generic thermal sysfs.

[Zhang Rui]

On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> On Fri, 2012-07-13 at 09:51 +0800, Zhang Rui wrote:
> > On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote:
> > > Hi,
> > > 
> > > > -----Original Message-----
> > > > From: Wei Ni [mailto:wni@nvidia.com]
> > > > Sent: Thursday, July 12, 2012 3:53 PM
> > > > To: Zhang, Rui; Brown, Len; akpm@linux-foundation.org; khali@linux-fr.org;
> > > > joe@perches.com; R, Durgadoss
> > > > Cc: linux-kernel@vger.kernel.org; linux-tegra@ger.kernel.org;
> > > > acourbot@nvidia.com
> > > > Subject: How to use the generic thermal sysfs.
> > > > 
> > > > Hi, all
> > > > I'm working on the tegra thermal throttling upstream issue.
> > > > The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is
> > > > the sensor driver. We want to use the generic thermal sysfs.
> > > > 
> > > > My question is where should we register the thermal zone device? We may
> > > > have two place to do it:
> > > > 1. register it in the sensor driver, such as lm90.c
> > > > In this way, the sensor driver doesn't need to export any APIs, such as
> > > > get_temp.
> > > 
> > > This approach is preferred.
> > > 
> > > > 2. register in my tegra thermal framework.
> > > > In this way, the sensor driver need to export some APIs, which are used
> > > > to register the ops and do any other things.
> > > 
> > > What do you mean by "my tegra thermal framework" ? Where does the source
> > > file for this sit in the mainline kernel ?
> > > 
> > I have the same question.
> > It sounds like that you want to use the tegra thermal framework to do
> > thermal management instead of the generic thermal layer, right?
> > 
> > IMO, the purpose of the generic thermal layer is
> > 1) do kernel thermal management
> > 2) export unique sysfs I/F to userspace so that users/userspace
> > applications can take over the thermal management.
> > 
> > what is the benefit to have another driver to do thermal management in
> > kernel?
> > If the current thermal management in the generic thermal layer can not
> > work well on your platform, it is a good chance to enhance the kernel
> > thermal manager. :)
> 
> Our tegra thermal framework also will use the generic thermal layer. It
> will register the cooling device, and run the throttling in this generic
> framework.
> But we have a special mechanism, when the temp is below the trip temp,
> we will set different cpu capability for different temp range. For
> example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> to the max capability, it mean the cpu can run up to the max freq and
> voltage in this temp range. if the temp is out that range, the sensor
> will have irq/alert to notify the tegra framework, then we will set to
> another temperature range and cpu capability.
> I think we can try to add this mechanism to the generic framework as a
> new policy, right?
> 
I think you can make use of the upper&lower limit in my patch set.
Say, here is your thermal policy
20C - 30C, P0
30C - 40C, P1 - P2
40C - 60C, P3 - P5
60C+, P6 ~ Pn

you can register to the thermal layer 4 passive trip points,
20C, 30C, 40C, 60C, and then
1) for trip 0 (20C), upper limit 0, lower limit 0
2) for trip 1 (30C), upper limit 2, lower limit 1
3) for trip 2 (40C), upper limit 5, lower limit 3
4) for trip 3 (60C), upper limit n, lower limit 6

you can program your own sensor to get interrupt when the temperature
hits 20C/30C/40C/60C, and the generic thermal layer will put the
processors to proper frequency for each trip point.

what do you think?

BTW, the upper and lower limit is introduced in the patch set I'm
testing, so maybe you were not aware of it.

thanks,
rui
> > 
> > thanks,
> > rui
> > 
> > > > 
> > > > How should I do it?
> > > > 
> > > > And in current codes, there have the event notification, in the form of
> > > > a netlink event. But it's difficult to be used in the kernel, it's
> > > > normally for the communication with user-space. How about to add a
> > > > notify call chain for it? So when the sensor has irq alert, it can send
> > > > a notify to my thermal framework in kernel.
> > > 
> > > We are working on a notification API from any generic sensor driver to
> > > the thermal framework.
> > > Please have a look at the 'notify_thermal_framework' API in the patch here:
> > > http://www.spinics.net/lists/linux-acpi/msg36049.html
> 
> It's cool. I will cherry pick them to run it.
> 
> > > 
> > > Thanks,
> > > Durga
> > > 
> > 
> > 
> 
> 

RE: How to use the generic thermal sysfs.

[Wei Ni]

On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > Our tegra thermal framework also will use the generic thermal layer. It
> > will register the cooling device, and run the throttling in this generic
> > framework.
> > But we have a special mechanism, when the temp is below the trip temp,
> > we will set different cpu capability for different temp range. For
> > example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> > to the max capability, it mean the cpu can run up to the max freq and
> > voltage in this temp range. if the temp is out that range, the sensor
> > will have irq/alert to notify the tegra framework, then we will set to
> > another temperature range and cpu capability.
> > I think we can try to add this mechanism to the generic framework as a
> > new policy, right?
> > 
> I think you can make use of the upper&lower limit in my patch set.
> Say, here is your thermal policy
> 20C - 30C, P0
> 30C - 40C, P1 - P2
> 40C - 60C, P3 - P5
> 60C+, P6 ~ Pn
> 
> you can register to the thermal layer 4 passive trip points,
> 20C, 30C, 40C, 60C, and then
> 1) for trip 0 (20C), upper limit 0, lower limit 0
> 2) for trip 1 (30C), upper limit 2, lower limit 1
> 3) for trip 2 (40C), upper limit 5, lower limit 3
> 4) for trip 3 (60C), upper limit n, lower limit 6
> 
> you can program your own sensor to get interrupt when the temperature
> hits 20C/30C/40C/60C, and the generic thermal layer will put the
> processors to proper frequency for each trip point.
> 
> what do you think?

It's great, this is exactly what we need.
I think for these trip points, we can use a new trip type, such as
TRIP_LIMIT, and use new policy. Because in these state, we only need to
set the processors to proper frequency capability, it's not like the
passive type, the currently passive type will try to set cooling device
state continually.
And for these trip temp, it's better to add hysteresis value, so that it
can avoid unnecessary interrupt.

> 
> BTW, the upper and lower limit is introduced in the patch set I'm
> testing, so maybe you were not aware of it.

How can I get these codes?

> 
> thanks,
> rui

RE: How to use the generic thermal sysfs.

[Wei Ni]

On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > Our tegra thermal framework also will use the generic thermal layer. It
> > will register the cooling device, and run the throttling in this generic
> > framework.
> > But we have a special mechanism, when the temp is below the trip temp,
> > we will set different cpu capability for different temp range. For
> > example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> > to the max capability, it mean the cpu can run up to the max freq and
> > voltage in this temp range. if the temp is out that range, the sensor
> > will have irq/alert to notify the tegra framework, then we will set to
> > another temperature range and cpu capability.
> > I think we can try to add this mechanism to the generic framework as a
> > new policy, right?
> > 
> I think you can make use of the upper&lower limit in my patch set.
> Say, here is your thermal policy
> 20C - 30C, P0
> 30C - 40C, P1 - P2
> 40C - 60C, P3 - P5
> 60C+, P6 ~ Pn
> 
> you can register to the thermal layer 4 passive trip points,
> 20C, 30C, 40C, 60C, and then
> 1) for trip 0 (20C), upper limit 0, lower limit 0
> 2) for trip 1 (30C), upper limit 2, lower limit 1
> 3) for trip 2 (40C), upper limit 5, lower limit 3
> 4) for trip 3 (60C), upper limit n, lower limit 6
> 
> you can program your own sensor to get interrupt when the temperature
> hits 20C/30C/40C/60C, and the generic thermal layer will put the
> processors to proper frequency for each trip point.
> 
> what do you think?

It's great, this is exactly what we need.
I think for these trip points, we can use a new trip type, such as
TRIP_LIMIT, and use new policy. Because in these state, we only need to
set the processors to proper frequency capability, it's not like the
passive type, the currently passive type will try to set cooling device
state continually.
And for these trip temp, it's better to add hysteresis value, so that it
can avoid unnecessary interrupt.

> 
> BTW, the upper and lower limit is introduced in the patch set I'm
> testing, so maybe you were not aware of it.

How can I get these codes?

> 
> thanks,
> rui

RE: How to use the generic thermal sysfs.

[Wei Ni]

On Fri, 2012-07-13 at 16:11 +0800, Wei Ni wrote:
> On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> > On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > > Our tegra thermal framework also will use the generic thermal layer. It
> > > will register the cooling device, and run the throttling in this generic
> > > framework.
> > > But we have a special mechanism, when the temp is below the trip temp,
> > > we will set different cpu capability for different temp range. For
> > > example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> > > to the max capability, it mean the cpu can run up to the max freq and
> > > voltage in this temp range. if the temp is out that range, the sensor
> > > will have irq/alert to notify the tegra framework, then we will set to
> > > another temperature range and cpu capability.
> > > I think we can try to add this mechanism to the generic framework as a
> > > new policy, right?
> > > 
> > I think you can make use of the upper&lower limit in my patch set.
> > Say, here is your thermal policy
> > 20C - 30C, P0
> > 30C - 40C, P1 - P2
> > 40C - 60C, P3 - P5
> > 60C+, P6 ~ Pn
> > 
> > you can register to the thermal layer 4 passive trip points,
> > 20C, 30C, 40C, 60C, and then
> > 1) for trip 0 (20C), upper limit 0, lower limit 0
> > 2) for trip 1 (30C), upper limit 2, lower limit 1
> > 3) for trip 2 (40C), upper limit 5, lower limit 3
> > 4) for trip 3 (60C), upper limit n, lower limit 6
> > 
> > you can program your own sensor to get interrupt when the temperature
> > hits 20C/30C/40C/60C, and the generic thermal layer will put the
> > processors to proper frequency for each trip point.
> > 
> > what do you think?
> 
> It's great, this is exactly what we need.
> I think for these trip points, we can use a new trip type, such as
> TRIP_LIMIT, and use new policy. Because in these state, we only need to
> set the processors to proper frequency capability, it's not like the
> passive type, the currently passive type will try to set cooling device
> state continually.

I read the patches of "Thermal Framework Enhancements", it seems the
fair_share governor can be used for this throttling.

Look forward to your public git tree, so that I can sync the entire
codes :)

> And for these trip temp, it's better to add hysteresis value, so that it
> can avoid unnecessary interrupt.
> 
> > 
> > BTW, the upper and lower limit is introduced in the patch set I'm
> > testing, so maybe you were not aware of it.
> 
> How can I get these codes?
> 
> > 
> > thanks,
> > rui
> 

RE: How to use the generic thermal sysfs.

[Wei Ni]

On Fri, 2012-07-13 at 16:11 +0800, Wei Ni wrote:
> On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> > On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > > Our tegra thermal framework also will use the generic thermal layer. It
> > > will register the cooling device, and run the throttling in this generic
> > > framework.
> > > But we have a special mechanism, when the temp is below the trip temp,
> > > we will set different cpu capability for different temp range. For
> > > example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> > > to the max capability, it mean the cpu can run up to the max freq and
> > > voltage in this temp range. if the temp is out that range, the sensor
> > > will have irq/alert to notify the tegra framework, then we will set to
> > > another temperature range and cpu capability.
> > > I think we can try to add this mechanism to the generic framework as a
> > > new policy, right?
> > > 
> > I think you can make use of the upper&lower limit in my patch set.
> > Say, here is your thermal policy
> > 20C - 30C, P0
> > 30C - 40C, P1 - P2
> > 40C - 60C, P3 - P5
> > 60C+, P6 ~ Pn
> > 
> > you can register to the thermal layer 4 passive trip points,
> > 20C, 30C, 40C, 60C, and then
> > 1) for trip 0 (20C), upper limit 0, lower limit 0
> > 2) for trip 1 (30C), upper limit 2, lower limit 1
> > 3) for trip 2 (40C), upper limit 5, lower limit 3
> > 4) for trip 3 (60C), upper limit n, lower limit 6
> > 
> > you can program your own sensor to get interrupt when the temperature
> > hits 20C/30C/40C/60C, and the generic thermal layer will put the
> > processors to proper frequency for each trip point.
> > 
> > what do you think?
> 
> It's great, this is exactly what we need.
> I think for these trip points, we can use a new trip type, such as
> TRIP_LIMIT, and use new policy. Because in these state, we only need to
> set the processors to proper frequency capability, it's not like the
> passive type, the currently passive type will try to set cooling device
> state continually.

I read the patches of "Thermal Framework Enhancements", it seems the
fair_share governor can be used for this throttling.

Look forward to your public git tree, so that I can sync the entire
codes :)

> And for these trip temp, it's better to add hysteresis value, so that it
> can avoid unnecessary interrupt.
> 
> > 
> > BTW, the upper and lower limit is introduced in the patch set I'm
> > testing, so maybe you were not aware of it.
> 
> How can I get these codes?
> 
> > 
> > thanks,
> > rui
> 

RE: How to use the generic thermal sysfs.

[Wei Ni]

On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > 
> > Our tegra thermal framework also will use the generic thermal layer. It
> > will register the cooling device, and run the throttling in this generic
> > framework.
> > But we have a special mechanism, when the temp is below the trip temp,
> > we will set different cpu capability for different temp range. For
> > example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> > to the max capability, it mean the cpu can run up to the max freq and
> > voltage in this temp range. if the temp is out that range, the sensor
> > will have irq/alert to notify the tegra framework, then we will set to
> > another temperature range and cpu capability.
> > I think we can try to add this mechanism to the generic framework as a
> > new policy, right?
> > 
> I think you can make use of the upper&lower limit in my patch set.
> Say, here is your thermal policy
> 20C - 30C, P0
> 30C - 40C, P1 - P2
> 40C - 60C, P3 - P5
> 60C+, P6 ~ Pn
> 
> you can register to the thermal layer 4 passive trip points,
> 20C, 30C, 40C, 60C, and then
> 1) for trip 0 (20C), upper limit 0, lower limit 0
> 2) for trip 1 (30C), upper limit 2, lower limit 1
> 3) for trip 2 (40C), upper limit 5, lower limit 3
> 4) for trip 3 (60C), upper limit n, lower limit 6
> 
> you can program your own sensor to get interrupt when the temperature
> hits 20C/30C/40C/60C, and the generic thermal layer will put the
> processors to proper frequency for each trip point.
> 
> what do you think?

Hi, Rui
I'm trying your upper/lower codes on our tegra platform.
Since we want to set limit value to the sensor to get interrupt, and
many sensor drivers can support the limit alert property, could we add a
new callback .set_limits() for the thermal zone device, so that we can
program it in the generic layer. when the temperature hits the
trip_temp, we can try to set to the next limit range.
I can try to add these codes base on your patches.

Thanks.
Wei.

> 
> BTW, the upper and lower limit is introduced in the patch set I'm
> testing, so maybe you were not aware of it.
> 
> thanks,
> rui

RE: How to use the generic thermal sysfs.

[Zhang Rui]

On 四, 2012-07-26 at 17:31 +0800, Wei Ni wrote:
> On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> > On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > > 
> > > Our tegra thermal framework also will use the generic thermal layer. It
> > > will register the cooling device, and run the throttling in this generic
> > > framework.
> > > But we have a special mechanism, when the temp is below the trip temp,
> > > we will set different cpu capability for different temp range. For
> > > example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> > > to the max capability, it mean the cpu can run up to the max freq and
> > > voltage in this temp range. if the temp is out that range, the sensor
> > > will have irq/alert to notify the tegra framework, then we will set to
> > > another temperature range and cpu capability.
> > > I think we can try to add this mechanism to the generic framework as a
> > > new policy, right?
> > > 
> > I think you can make use of the upper&lower limit in my patch set.
> > Say, here is your thermal policy
> > 20C - 30C, P0
> > 30C - 40C, P1 - P2
> > 40C - 60C, P3 - P5
> > 60C+, P6 ~ Pn
> > 
> > you can register to the thermal layer 4 passive trip points,
> > 20C, 30C, 40C, 60C, and then
> > 1) for trip 0 (20C), upper limit 0, lower limit 0
> > 2) for trip 1 (30C), upper limit 2, lower limit 1
> > 3) for trip 2 (40C), upper limit 5, lower limit 3
> > 4) for trip 3 (60C), upper limit n, lower limit 6
> > 
> > you can program your own sensor to get interrupt when the temperature
> > hits 20C/30C/40C/60C, and the generic thermal layer will put the
> > processors to proper frequency for each trip point.
> > 
> > what do you think?
> 
> Hi, Rui
> I'm trying your upper/lower codes on our tegra platform.
> Since we want to set limit value to the sensor to get interrupt, and
> many sensor drivers can support the limit alert property, could we add a
> new callback .set_limits() for the thermal zone device, so that we can
> program it in the generic layer. when the temperature hits the
> trip_temp,

at this time, there should be an interrupt, right?

>  we can try to set to the next limit range.

is it possible to program the sensor at this time, in your own thermal
driver?

thanks,
rui
> I can try to add these codes base on your patches.
> 
> Thanks.
> Wei.
> 
> > 
> > BTW, the upper and lower limit is introduced in the patch set I'm
> > testing, so maybe you were not aware of it.
> > 
> > thanks,
> > rui
> 
> 
> 

RE: How to use the generic thermal sysfs.

[Wei Ni]

On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote:
> On 四, 2012-07-26 at 17:31 +0800, Wei Ni wrote:
> > On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> > > On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > > > 
> > > > Our tegra thermal framework also will use the generic thermal layer. It
> > > > will register the cooling device, and run the throttling in this generic
> > > > framework.
> > > > But we have a special mechanism, when the temp is below the trip temp,
> > > > we will set different cpu capability for different temp range. For
> > > > example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> > > > to the max capability, it mean the cpu can run up to the max freq and
> > > > voltage in this temp range. if the temp is out that range, the sensor
> > > > will have irq/alert to notify the tegra framework, then we will set to
> > > > another temperature range and cpu capability.
> > > > I think we can try to add this mechanism to the generic framework as a
> > > > new policy, right?
> > > > 
> > > I think you can make use of the upper&lower limit in my patch set.
> > > Say, here is your thermal policy
> > > 20C - 30C, P0
> > > 30C - 40C, P1 - P2
> > > 40C - 60C, P3 - P5
> > > 60C+, P6 ~ Pn
> > > 
> > > you can register to the thermal layer 4 passive trip points,
> > > 20C, 30C, 40C, 60C, and then
> > > 1) for trip 0 (20C), upper limit 0, lower limit 0
> > > 2) for trip 1 (30C), upper limit 2, lower limit 1
> > > 3) for trip 2 (40C), upper limit 5, lower limit 3
> > > 4) for trip 3 (60C), upper limit n, lower limit 6
> > > 
> > > you can program your own sensor to get interrupt when the temperature
> > > hits 20C/30C/40C/60C, and the generic thermal layer will put the
> > > processors to proper frequency for each trip point.
> > > 
> > > what do you think?
> > 
> > Hi, Rui
> > I'm trying your upper/lower codes on our tegra platform.
> > Since we want to set limit value to the sensor to get interrupt, and
> > many sensor drivers can support the limit alert property, could we add a
> > new callback .set_limits() for the thermal zone device, so that we can
> > program it in the generic layer. when the temperature hits the
> > trip_temp,
> 
> at this time, there should be an interrupt, right?

Yes, there will have an interrupt.

> 
> >  we can try to set to the next limit range.
> 
> is it possible to program the sensor at this time, in your own thermal
> driver?

Since we are using the generic thermal driver lm90.c, I'm not sure if we
could program these limits in the generic driver, I think it's better to
have a generic interface to set the limits, so I wish to add a
callback .set_limits() in the generic thermal framework.

> 
> thanks,
> rui
> > I can try to add these codes base on your patches.
> > 
> > Thanks.
> > Wei.
> > 
> > > 
> > > BTW, the upper and lower limit is introduced in the patch set I'm
> > > testing, so maybe you were not aware of it.
> > > 
> > > thanks,
> > > rui
> > 
> > 
> > 
> 
> 

Re: How to use the generic thermal sysfs.

[Jean Delvare]

On Fri, 27 Jul 2012 10:58:21 +0800, Wei Ni wrote:
> On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote:
> > is it possible to program the sensor at this time, in your own thermal
> > driver?
> 
> Since we are using the generic thermal driver lm90.c, I'm not sure if we
> could program these limits in the generic driver, I think it's better to
> have a generic interface to set the limits, so I wish to add a
> callback .set_limits() in the generic thermal framework.

I can confirm that hwmon drivers do not set limits, it is up to
user-space to do it if they want. So if there is a need to do so in the
kernel itself, a proper interface at the generic thermal framework
level seems appropriate.

-- 
Jean Delvare

Re: How to use the generic thermal sysfs.

[Zhang Rui]

On 五, 2012-07-27 at 09:30 +0200, Jean Delvare wrote:
> On Fri, 27 Jul 2012 10:58:21 +0800, Wei Ni wrote:
> > On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote:
> > > is it possible to program the sensor at this time, in your own thermal
> > > driver?
> > 
> > Since we are using the generic thermal driver lm90.c, I'm not sure if we
> > could program these limits in the generic driver, I think it's better to
> > have a generic interface to set the limits, so I wish to add a
> > callback .set_limits() in the generic thermal framework.
> 
> I can confirm that hwmon drivers do not set limits, it is up to
> user-space to do it if they want. So if there is a need to do so in the
> kernel itself, a proper interface at the generic thermal framework
> level seems appropriate.
> 
oh, setting limits from userspace?
I think you can program the senor when writing the trip point?
with this patch,
http://marc.info/?l=linux-acpi&m=134318814620429&w=2

thanks,
rui

Re: How to use the generic thermal sysfs.

[Wei Ni]

On Fri, 2012-07-27 at 15:39 +0800, Zhang Rui wrote:
> On 五, 2012-07-27 at 09:30 +0200, Jean Delvare wrote:
> > On Fri, 27 Jul 2012 10:58:21 +0800, Wei Ni wrote:
> > > On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote:
> > > > is it possible to program the sensor at this time, in your own thermal
> > > > driver?
> > > 
> > > Since we are using the generic thermal driver lm90.c, I'm not sure if we
> > > could program these limits in the generic driver, I think it's better to
> > > have a generic interface to set the limits, so I wish to add a
> > > callback .set_limits() in the generic thermal framework.
> > 
> > I can confirm that hwmon drivers do not set limits, it is up to
> > user-space to do it if they want. So if there is a need to do so in the
> > kernel itself, a proper interface at the generic thermal framework
> > level seems appropriate.
> > 
> oh, setting limits from userspace?
> I think you can program the senor when writing the trip point?
> with this patch,
> http://marc.info/?l=linux-acpi&m=134318814620429&w=2

Do you mean it can use .set_trip_temp() to set limits when writing the
trip point? But I think this callback is used to change the trip_temp,
it could not used to set the limits, in here the limit value is used to
trigger the interrupt.

> 
> thanks,
> rui
> 
> 

Re: How to use the generic thermal sysfs.

[Zhang Rui]

On 五, 2012-07-27 at 18:48 +0800, Wei Ni wrote:
> On Fri, 2012-07-27 at 15:39 +0800, Zhang Rui wrote:
> > On 五, 2012-07-27 at 09:30 +0200, Jean Delvare wrote:
> > > On Fri, 27 Jul 2012 10:58:21 +0800, Wei Ni wrote:
> > > > On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote:
> > > > > is it possible to program the sensor at this time, in your own thermal
> > > > > driver?
> > > > 
> > > > Since we are using the generic thermal driver lm90.c, I'm not sure if we
> > > > could program these limits in the generic driver, I think it's better to
> > > > have a generic interface to set the limits, so I wish to add a
> > > > callback .set_limits() in the generic thermal framework.
> > > 
> > > I can confirm that hwmon drivers do not set limits, it is up to
> > > user-space to do it if they want. So if there is a need to do so in the
> > > kernel itself, a proper interface at the generic thermal framework
> > > level seems appropriate.
> > > 
> > oh, setting limits from userspace?
> > I think you can program the senor when writing the trip point?
> > with this patch,
> > http://marc.info/?l=linux-acpi&m=134318814620429&w=2
> 
> Do you mean it can use .set_trip_temp() to set limits when writing the
> trip point? But I think this callback is used to change the trip_temp,
> it could not used to set the limits, in here the limit value is used to
> trigger the interrupt.
> 
yes, you are right. .set_trip_temp does not work.

usually, this is needed to re-program the sensor when the temperature
hits a trip point , right?

can we make use of the thermal_zone_device_ops.notify()?
say we invoke .notify() in thermal_zone_device_update for each trip
point.

thanks,
rui
> > 
> > thanks,
> > rui
> > 
> > 
> 
> 

Re: How to use the generic thermal sysfs.

[Wei Ni]

On Wed, 2012-08-01 at 09:02 +0800, Zhang Rui wrote:
> On 五, 2012-07-27 at 18:48 +0800, Wei Ni wrote:
> > On Fri, 2012-07-27 at 15:39 +0800, Zhang Rui wrote:
> > > On 五, 2012-07-27 at 09:30 +0200, Jean Delvare wrote:
> > > > On Fri, 27 Jul 2012 10:58:21 +0800, Wei Ni wrote:
> > > > > On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote:
> > > > > > is it possible to program the sensor at this time, in your own thermal
> > > > > > driver?
> > > > > 
> > > > > Since we are using the generic thermal driver lm90.c, I'm not sure if we
> > > > > could program these limits in the generic driver, I think it's better to
> > > > > have a generic interface to set the limits, so I wish to add a
> > > > > callback .set_limits() in the generic thermal framework.
> > > > 
> > > > I can confirm that hwmon drivers do not set limits, it is up to
> > > > user-space to do it if they want. So if there is a need to do so in the
> > > > kernel itself, a proper interface at the generic thermal framework
> > > > level seems appropriate.
> > > > 
> > > oh, setting limits from userspace?
> > > I think you can program the senor when writing the trip point?
> > > with this patch,
> > > http://marc.info/?l=linux-acpi&m=134318814620429&w=2
> > 
> > Do you mean it can use .set_trip_temp() to set limits when writing the
> > trip point? But I think this callback is used to change the trip_temp,
> > it could not used to set the limits, in here the limit value is used to
> > trigger the interrupt.
> > 
> yes, you are right. .set_trip_temp does not work.
> 
> usually, this is needed to re-program the sensor when the temperature
> hits a trip point , right?

Yes, we need to re-program the sensor to set the limit value.

> 
> can we make use of the thermal_zone_device_ops.notify()?
> say we invoke .notify() in thermal_zone_device_update for each trip
> point.

oh, it's a good idea, we can re-program the sensor in the .notify(), is
it right?
I will try it later, thanks for your suggestions.

> 
> thanks,
> rui

How can I get the latest generic thermal framework

[Wei Ni]

Hi, all
Several months ago, I tried to use the generic thermal framework to work 
with the lm90 driver on our SOC, but this work was not completed, and it 
was pended.
Now I want to start it again. I noticed that many new patches of this 
framework were submitted, I checked linux-next.git, but it seems they 
were not merged.
How can I get the latest codes for this thermal framework? which git 
repository should I use?

Thanks.
Wei.

RE: How can I get the latest generic thermal framework

[R, Durgadoss]

Hi Wei,

You can pull the latest changes from Rui's -next tree here:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
(use -next branch)

Thanks,
Durga

> -----Original Message-----
> From: Wei Ni [mailto:wni@nvidia.com]
> Sent: Wednesday, October 17, 2012 12:46 PM
> To: Zhang, Rui; R, Durgadoss; Brown, Len
> Cc: khali@linux-fr.org; joe@perches.com; linux-kernel@vger.kernel.org;
> linux-tegra@ger.kernel.org; Alex Courbot
> Subject: How can I get the latest generic thermal framework
> 
> Hi, all
> Several months ago, I tried to use the generic thermal framework to work
> with the lm90 driver on our SOC, but this work was not completed, and it
> was pended.
> Now I want to start it again. I noticed that many new patches of this
> framework were submitted, I checked linux-next.git, but it seems they
> were not merged.
> How can I get the latest codes for this thermal framework? which git
> repository should I use?
> 
> Thanks.
> Wei.

RE: How can I get the latest generic thermal framework

[R, Durgadoss]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1129 bytes --]

Hi Wei,

You can pull the latest changes from Rui's -next tree here:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
(use -next branch)

Thanks,
Durga

> -----Original Message-----
> From: Wei Ni [mailto:wni@nvidia.com]
> Sent: Wednesday, October 17, 2012 12:46 PM
> To: Zhang, Rui; R, Durgadoss; Brown, Len
> Cc: khali@linux-fr.org; joe@perches.com; linux-kernel@vger.kernel.org;
> linux-tegra@ger.kernel.org; Alex Courbot
> Subject: How can I get the latest generic thermal framework
> 
> Hi, all
> Several months ago, I tried to use the generic thermal framework to work
> with the lm90 driver on our SOC, but this work was not completed, and it
> was pended.
> Now I want to start it again. I noticed that many new patches of this
> framework were submitted, I checked linux-next.git, but it seems they
> were not merged.
> How can I get the latest codes for this thermal framework? which git
> repository should I use?
> 
> Thanks.
> Wei.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥