Re: How to use the generic thermal sysfs.
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=134318814620429=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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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-acpim=134318814620429w=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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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=134318814620429=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 > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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-acpim=134318814620429w=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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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=134318814620429=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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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=134318814620429=2 thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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-acpim=134318814620429w=2 thanks, rui -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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-acpim=134318814620429w=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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 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 > > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 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 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 upperlower 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 upperlower 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 upperlower 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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:w...@nvidia.com] > > > > Sent: Thursday, July 12, 2012 3:53 PM > > > > To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; > > > > kh...@linux-fr.org; > > > > j...@perches.com; R, Durgadoss > > > > Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; > > > > acour...@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 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 > > > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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:w...@nvidia.com] > > > Sent: Thursday, July 12, 2012 3:53 PM > > > To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; > > > j...@perches.com; R, Durgadoss > > > Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; > > > acour...@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 > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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:w...@nvidia.com] Sent: Thursday, July 12, 2012 3:53 PM To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; j...@perches.com; R, Durgadoss Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; acour...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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:w...@nvidia.com] Sent: Thursday, July 12, 2012 3:53 PM To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; j...@perches.com; R, Durgadoss Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; acour...@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 upperlower 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 upperlower 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
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 upperlower 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
> -Original Message- > From: Alex Courbot [mailto:acour...@nvidia.com] > Sent: Friday, July 13, 2012 11:19 AM > To: R, Durgadoss > Cc: Wei Ni; Zhang, Rui; Brown, Len; a...@linux-foundation.org; khali@linux- > fr.org; j...@perches.com; linux-kernel@vger.kernel.org; linux- > te...@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.
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote: > Hi, > > > -Original Message- > > From: Wei Ni [mailto:w...@nvidia.com] > > Sent: Thursday, July 12, 2012 3:53 PM > > To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; > > j...@perches.com; R, Durgadoss > > Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; > > acour...@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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
Hi, > -Original Message- > From: Wei Ni [mailto:w...@nvidia.com] > Sent: Thursday, July 12, 2012 3:53 PM > To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; > j...@perches.com; R, Durgadoss > Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; > acour...@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
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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote: Hi, -Original Message- From: Wei Ni [mailto:w...@nvidia.com] Sent: Thursday, July 12, 2012 3:53 PM To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; j...@perches.com; R, Durgadoss Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; acour...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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? Thanks, Alex. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
-Original Message- From: Alex Courbot [mailto:acour...@nvidia.com] Sent: Friday, July 13, 2012 11:19 AM To: R, Durgadoss Cc: Wei Ni; Zhang, Rui; Brown, Len; a...@linux-foundation.org; khali@linux- fr.org; j...@perches.com; linux-kernel@vger.kernel.org; linux- te...@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
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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
Hi, -Original Message- From: Wei Ni [mailto:w...@nvidia.com] Sent: Thursday, July 12, 2012 3:53 PM To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; j...@perches.com; R, Durgadoss Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; acour...@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
