| Message ID | 1423517653-11359-3-git-send-email-edubezval@gmail.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On 02/09/15 13:34, Eduardo Valentin wrote: > This change introduces a section in the Introduction Chapter to > list concepts used by the Thermal Framework. > > Signed-off-by: Eduardo Valentin <edubezval@gmail.com> > --- > Documentation/DocBook/thermal.tmpl | 129 ++++++++++++++++++++++++++++++++++++- > 1 file changed, 128 insertions(+), 1 deletion(-) > > diff --git a/Documentation/DocBook/thermal.tmpl b/Documentation/DocBook/thermal.tmpl > index f8fb8a2..66efed3 100644 > --- a/Documentation/DocBook/thermal.tmpl > +++ b/Documentation/DocBook/thermal.tmpl > @@ -84,5 +84,132 @@ > devices. > </para> > > - </chapter> > + <sect1 id="glossary"> > + <title>Glossary</title> > + <para>The Linux Kernel Thermal Framework uses a > + specific terminology to represent the entities involved > + in thermal constrained environments. This section > + summaries the terminology as dictionary. These terms are summarizes > + in use within the present document and in the source > + code of the Linux Kernel Thermal Framework. > + </para> > + <glossary> > + <glossentry> > + <glossterm>Thermal Zone</glossterm> > + <glossdef> > + <para>Thermal zones represent > + what is the current status of a > + thermal constrained zone in the > + hardware. The zone usually is a > + device or component. The status > + of a thermal zone is mainly with > + respect to temperature. > + Currently, the Linux Kernel > + Thermal Framework represents > + temperature in miliCelsius. The > + current abstraction covers for > + non negative temperatures and non-negative > + constraints. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Thermal Sensors</glossterm> > + <glossdef> > + <para>Thermal sensors provide > + temperature sensing capabilities > + on thermal zones. Typical > + devices are I2C ADC converters > + and bandgaps. These are nodes > + providing temperature data to > + thermal zones. Thermal sensor > + devices may control one or more > + internal sensors. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Trips Points</glossterm> Trip Points > + <glossdef> > + <para>The trip node describes a > + point in the temperature domain > + in which the system takes an > + action. This item describes just > + the point, not the action. Trip > + points are represented as > + temperature in miliCelsius. The > + current abstraction covers for > + non negative temperatures. non-negative > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Thermal Governor</glossterm> > + <glossdef> > + <para>Thermal Governors > + represent a policy to manage the > + thermal zone device temperature. > + The governor targets to keep > + temperature in an acceptable > + range which correlates to the > + power budget, while maximizing > + the performance. Governors can > + be implemented in Kernel Space > + or in User Space. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Thermal Cooling Device</glossterm> > + <glossdef> > + <para>Cooling devices provide > + control on power dissipation. > + There are essentially two ways > + to provide control on power > + dissipation. First is by means > + of regulating device > + performance, which is known as > + passive cooling. A typical > + passive cooling is a CPU that > + has dynamic voltage and > + frequency scaling (DVFS), and > + uses lower frequencies as > + cooling states. Second is by > + means of activating devices in > + order to remove the dissipated > + heat, which is known as active > + cooling, e.g. regulating fan > + speeds. In both cases, cooling > + devices shall have a way to > + determine the state of cooling > + in which the device is. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Cooling State</glossterm> > + <glossdef> > + <para>Any cooling device has a > + range of cooling states (i.e. > + different levels of heat > + dissipation). For example a > + fan's cooling states correspond > + to the different fan speeds > + possible. Cooling states are > + referred to by single unsigned > + integers, where larger numbers > + mean greater heat dissipation. > + The precise set of cooling > + states associated with a device > + (as referred to be the > + cooling-min-state and > + cooling-max-state properties) > + should be defined in a > + particular device's binding. > + </para> > + </glossdef> > + </glossentry> > + </glossary> > + </sect1> > + </chapter> > </book> >
On 02/09/2015 11:34 PM, Eduardo Valentin wrote: > This change introduces a section in the Introduction Chapter to > list concepts used by the Thermal Framework. > > Signed-off-by: Eduardo Valentin <edubezval@gmail.com> > --- > Documentation/DocBook/thermal.tmpl | 129 ++++++++++++++++++++++++++++++++++++- > 1 file changed, 128 insertions(+), 1 deletion(-) > > diff --git a/Documentation/DocBook/thermal.tmpl b/Documentation/DocBook/thermal.tmpl > index f8fb8a2..66efed3 100644 > --- a/Documentation/DocBook/thermal.tmpl > +++ b/Documentation/DocBook/thermal.tmpl > @@ -84,5 +84,132 @@ > devices. > </para> > > - </chapter> > + <sect1 id="glossary"> > + <title>Glossary</title> > + <para>The Linux Kernel Thermal Framework uses a > + specific terminology to represent the entities involved > + in thermal constrained environments. This section > + summaries the terminology as dictionary. These terms are > + in use within the present document and in the source > + code of the Linux Kernel Thermal Framework. > + </para> > + <glossary> > + <glossentry> > + <glossterm>Thermal Zone</glossterm> > + <glossdef> > + <para>Thermal zones represent > + what is the current status of a > + thermal constrained zone in the > + hardware. The zone usually is a > + device or component. The status > + of a thermal zone is mainly with > + respect to temperature. > + Currently, the Linux Kernel > + Thermal Framework represents > + temperature in miliCelsius. The milli-Celsius or millicelsius. Same change later too. > + current abstraction covers for > + non negative temperatures and > + constraints. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Thermal Sensors</glossterm> > + <glossdef> > + <para>Thermal sensors provide > + temperature sensing capabilities > + on thermal zones. Typical > + devices are I2C ADC converters > + and bandgaps. These are nodes > + providing temperature data to > + thermal zones. Thermal sensor > + devices may control one or more > + internal sensors. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Trips Points</glossterm> > + <glossdef> > + <para>The trip node describes a > + point in the temperature domain > + in which the system takes an > + action. This item describes just > + the point, not the action. Trip > + points are represented as > + temperature in miliCelsius. The here > + current abstraction covers for > + non negative temperatures. One thing I'd also like to see documented is the roles of the different trip types (PASSIVE, ACTIVE, HOT, CRITICAL) and when each should be used. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Thermal Governor</glossterm> > + <glossdef> > + <para>Thermal Governors > + represent a policy to manage the > + thermal zone device temperature. > + The governor targets to keep > + temperature in an acceptable > + range which correlates to the > + power budget, while maximizing > + the performance. Governors can > + be implemented in Kernel Space > + or in User Space. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Thermal Cooling Device</glossterm> > + <glossdef> > + <para>Cooling devices provide > + control on power dissipation. > + There are essentially two ways > + to provide control on power > + dissipation. First is by means > + of regulating device > + performance, which is known as > + passive cooling. A typical > + passive cooling is a CPU that > + has dynamic voltage and > + frequency scaling (DVFS), and > + uses lower frequencies as > + cooling states. Second is by > + means of activating devices in > + order to remove the dissipated > + heat, which is known as active > + cooling, e.g. regulating fan > + speeds. In both cases, cooling > + devices shall have a way to > + determine the state of cooling > + in which the device is. > + </para> > + </glossdef> > + </glossentry> > + <glossentry> > + <glossterm>Cooling State</glossterm> > + <glossdef> > + <para>Any cooling device has a > + range of cooling states (i.e. > + different levels of heat > + dissipation). For example a > + fan's cooling states correspond > + to the different fan speeds > + possible. Cooling states are > + referred to by single unsigned > + integers, where larger numbers > + mean greater heat dissipation. > + The precise set of cooling > + states associated with a device > + (as referred to be the > + cooling-min-state and > + cooling-max-state properties) > + should be defined in a > + particular device's binding. > + </para> > + </glossdef> > + </glossentry> > + </glossary> > + </sect1> > + </chapter> > </book> > Cheers, Mikko. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Randy On Tue, Feb 10, 2015 at 02:50:47PM -0800, Randy Dunlap wrote: > On 02/09/15 13:34, Eduardo Valentin wrote: > > This change introduces a section in the Introduction Chapter to > > list concepts used by the Thermal Framework. > > > > Signed-off-by: Eduardo Valentin <edubezval@gmail.com> > > --- > > Documentation/DocBook/thermal.tmpl | 129 ++++++++++++++++++++++++++++++++++++- > > 1 file changed, 128 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/DocBook/thermal.tmpl b/Documentation/DocBook/thermal.tmpl > > index f8fb8a2..66efed3 100644 > > --- a/Documentation/DocBook/thermal.tmpl > > +++ b/Documentation/DocBook/thermal.tmpl > > @@ -84,5 +84,132 @@ > > devices. > > </para> > > > > - </chapter> > > + <sect1 id="glossary"> > > + <title>Glossary</title> > > + <para>The Linux Kernel Thermal Framework uses a > > + specific terminology to represent the entities involved > > + in thermal constrained environments. This section > > + summaries the terminology as dictionary. These terms are > > summarizes > > > + in use within the present document and in the source > > + code of the Linux Kernel Thermal Framework. > > + </para> > > + <glossary> > > + <glossentry> > > + <glossterm>Thermal Zone</glossterm> > > + <glossdef> > > + <para>Thermal zones represent > > + what is the current status of a > > + thermal constrained zone in the > > + hardware. The zone usually is a > > + device or component. The status > > + of a thermal zone is mainly with > > + respect to temperature. > > + Currently, the Linux Kernel > > + Thermal Framework represents > > + temperature in miliCelsius. The > > + current abstraction covers for > > + non negative temperatures and > > non-negative > > > + constraints. > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Thermal Sensors</glossterm> > > + <glossdef> > > + <para>Thermal sensors provide > > + temperature sensing capabilities > > + on thermal zones. Typical > > + devices are I2C ADC converters > > + and bandgaps. These are nodes > > + providing temperature data to > > + thermal zones. Thermal sensor > > + devices may control one or more > > + internal sensors. > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Trips Points</glossterm> > > Trip Points > > > + <glossdef> > > + <para>The trip node describes a > > + point in the temperature domain > > + in which the system takes an > > + action. This item describes just > > + the point, not the action. Trip > > + points are represented as > > + temperature in miliCelsius. The > > + current abstraction covers for > > + non negative temperatures. > > non-negative > > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Thermal Governor</glossterm> > > + <glossdef> > > + <para>Thermal Governors > > + represent a policy to manage the > > + thermal zone device temperature. > > + The governor targets to keep > > + temperature in an acceptable > > + range which correlates to the > > + power budget, while maximizing > > + the performance. Governors can > > + be implemented in Kernel Space > > + or in User Space. > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Thermal Cooling Device</glossterm> > > + <glossdef> > > + <para>Cooling devices provide > > + control on power dissipation. > > + There are essentially two ways > > + to provide control on power > > + dissipation. First is by means > > + of regulating device > > + performance, which is known as > > + passive cooling. A typical > > + passive cooling is a CPU that > > + has dynamic voltage and > > + frequency scaling (DVFS), and > > + uses lower frequencies as > > + cooling states. Second is by > > + means of activating devices in > > + order to remove the dissipated > > + heat, which is known as active > > + cooling, e.g. regulating fan > > + speeds. In both cases, cooling > > + devices shall have a way to > > + determine the state of cooling > > + in which the device is. > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Cooling State</glossterm> > > + <glossdef> > > + <para>Any cooling device has a > > + range of cooling states (i.e. > > + different levels of heat > > + dissipation). For example a > > + fan's cooling states correspond > > + to the different fan speeds > > + possible. Cooling states are > > + referred to by single unsigned > > + integers, where larger numbers > > + mean greater heat dissipation. > > + The precise set of cooling > > + states associated with a device > > + (as referred to be the > > + cooling-min-state and > > + cooling-max-state properties) > > + should be defined in a > > + particular device's binding. > > + </para> > > + </glossdef> > > + </glossentry> > > + </glossary> > > + </sect1> > > + </chapter> > > </book> > > > > > -- > ~Randy Fixing all the above in next version. Thanks, Eduardo Valentin
Terve Mikko, On Mon, Feb 16, 2015 at 03:01:25PM +0200, Mikko Perttunen wrote: > On 02/09/2015 11:34 PM, Eduardo Valentin wrote: > > This change introduces a section in the Introduction Chapter to > > list concepts used by the Thermal Framework. > > > > Signed-off-by: Eduardo Valentin <edubezval@gmail.com> > > --- > > Documentation/DocBook/thermal.tmpl | 129 ++++++++++++++++++++++++++++++++++++- > > 1 file changed, 128 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/DocBook/thermal.tmpl b/Documentation/DocBook/thermal.tmpl > > index f8fb8a2..66efed3 100644 > > --- a/Documentation/DocBook/thermal.tmpl > > +++ b/Documentation/DocBook/thermal.tmpl > > @@ -84,5 +84,132 @@ > > devices. > > </para> > > > > - </chapter> > > + <sect1 id="glossary"> > > + <title>Glossary</title> > > + <para>The Linux Kernel Thermal Framework uses a > > + specific terminology to represent the entities involved > > + in thermal constrained environments. This section > > + summaries the terminology as dictionary. These terms are > > + in use within the present document and in the source > > + code of the Linux Kernel Thermal Framework. > > + </para> > > + <glossary> > > + <glossentry> > > + <glossterm>Thermal Zone</glossterm> > > + <glossdef> > > + <para>Thermal zones represent > > + what is the current status of a > > + thermal constrained zone in the > > + hardware. The zone usually is a > > + device or component. The status > > + of a thermal zone is mainly with > > + respect to temperature. > > + Currently, the Linux Kernel > > + Thermal Framework represents > > + temperature in miliCelsius. The > > milli-Celsius or millicelsius. Same change later too. OK. I will standardize. > > > + current abstraction covers for > > + non negative temperatures and > > + constraints. > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Thermal Sensors</glossterm> > > + <glossdef> > > + <para>Thermal sensors provide > > + temperature sensing capabilities > > + on thermal zones. Typical > > + devices are I2C ADC converters > > + and bandgaps. These are nodes > > + providing temperature data to > > + thermal zones. Thermal sensor > > + devices may control one or more > > + internal sensors. > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Trips Points</glossterm> > > + <glossdef> > > + <para>The trip node describes a > > + point in the temperature domain > > + in which the system takes an > > + action. This item describes just > > + the point, not the action. Trip > > + points are represented as > > + temperature in miliCelsius. The > > here > > > + current abstraction covers for > > + non negative temperatures. > > One thing I'd also like to see documented is the roles of the different > trip types (PASSIVE, ACTIVE, HOT, CRITICAL) and when each should be used. OK. That makes sense to me. I will include either a chapter about thermal zones and have a section about it, or include in here, in the glossary. I will think about it. Thanks for your thoughts! > > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Thermal Governor</glossterm> > > + <glossdef> > > + <para>Thermal Governors > > + represent a policy to manage the > > + thermal zone device temperature. > > + The governor targets to keep > > + temperature in an acceptable > > + range which correlates to the > > + power budget, while maximizing > > + the performance. Governors can > > + be implemented in Kernel Space > > + or in User Space. > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Thermal Cooling Device</glossterm> > > + <glossdef> > > + <para>Cooling devices provide > > + control on power dissipation. > > + There are essentially two ways > > + to provide control on power > > + dissipation. First is by means > > + of regulating device > > + performance, which is known as > > + passive cooling. A typical > > + passive cooling is a CPU that > > + has dynamic voltage and > > + frequency scaling (DVFS), and > > + uses lower frequencies as > > + cooling states. Second is by > > + means of activating devices in > > + order to remove the dissipated > > + heat, which is known as active > > + cooling, e.g. regulating fan > > + speeds. In both cases, cooling > > + devices shall have a way to > > + determine the state of cooling > > + in which the device is. > > + </para> > > + </glossdef> > > + </glossentry> > > + <glossentry> > > + <glossterm>Cooling State</glossterm> > > + <glossdef> > > + <para>Any cooling device has a > > + range of cooling states (i.e. > > + different levels of heat > > + dissipation). For example a > > + fan's cooling states correspond > > + to the different fan speeds > > + possible. Cooling states are > > + referred to by single unsigned > > + integers, where larger numbers > > + mean greater heat dissipation. > > + The precise set of cooling > > + states associated with a device > > + (as referred to be the > > + cooling-min-state and > > + cooling-max-state properties) > > + should be defined in a > > + particular device's binding. > > + </para> > > + </glossdef> > > + </glossentry> > > + </glossary> > > + </sect1> > > + </chapter> > > </book> > > > > Cheers, > Mikko. >
On Wed, Feb 18, 2015 at 08:58:18AM -0800, Srinivas Pandruvada wrote: > On Wed, 2015-02-18 at 11:52 +0000, Javi Merino wrote: > > Hi Eduardo, > > > > On Mon, Feb 09, 2015 at 09:34:03PM +0000, Eduardo Valentin wrote: > > > This change introduces a section in the Introduction Chapter to > > > list concepts used by the Thermal Framework. > > > > > > Signed-off-by: Eduardo Valentin <edubezval@gmail.com> > > > --- > > > Documentation/DocBook/thermal.tmpl | 129 ++++++++++++++++++++++++++++++++++++- > > > 1 file changed, 128 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/DocBook/thermal.tmpl b/Documentation/DocBook/thermal.tmpl > > > index f8fb8a2..66efed3 100644 > > > --- a/Documentation/DocBook/thermal.tmpl > > > +++ b/Documentation/DocBook/thermal.tmpl > > > @@ -84,5 +84,132 @@ > > > devices. > > > </para> > > > > > > - </chapter> > > > + <sect1 id="glossary"> > > > + <title>Glossary</title> > > > + <para>The Linux Kernel Thermal Framework uses a > > > + specific terminology to represent the entities involved > > > + in thermal constrained environments. This section > > > + summaries the terminology as dictionary. These terms are > > > + in use within the present document and in the source > > > + code of the Linux Kernel Thermal Framework. > > > + </para> > > > + <glossary> > > > + <glossentry> > > > + <glossterm>Thermal Zone</glossterm> > > > + <glossdef> > > > + <para>Thermal zones represent > > > + what is the current status of a > > > + thermal constrained zone in the > > > + hardware. The zone usually is a > > > + device or component. The status > > > + of a thermal zone is mainly with > > > + respect to temperature. > > > + Currently, the Linux Kernel > > > + Thermal Framework represents > > > + temperature in miliCelsius. The > > > + current abstraction covers for > > > + non negative temperatures and > > > + constraints. > > > + </para> > > > > Shall we point out that a thermal zone doesn't necessarily imply a > > thermal sensor? I find it very common to assume that if you have 10 > > sensors, you should have 10 thermal zones. From my point of view, a > > thermal zone is an area that has similar thermal characteristics. > > Therefore, the temperature of the thermal zone doesn't necessarily > > have to come from on sensor, and can be defined as a combination of > > the input from multiple thermal sensors. Yes, I agree that here we should mention that we are talking about an area/zone in hardware. > > Currently since you can have one temperature input per zone > (irrespective of whether the temperature is combination of many sensors > or virtual sensor), so separating thermal sensor and zone can be more > confusing IMO from a user space perspective. I believe we should make it clear in the documentation what is the relation between each entity. I will add a section about the relations, clarifying from concept perspective, implementation wise, and from userspace perspective. > > This was a feature proposed and submitted for thermal sysfs 2.0 (or next > version), where sensors and zones are separated. I think there was some > plan to adopt this. Rui Zhang can comment more. Yes, I agree. However, the sysfs 2.0 never made upstream. The current documentation project targets what is in the kernel tree. > > Thanks, > Srinivas > > > > > > I don't know how to put this in proper words for the documentation, > > but I think it's worth hinting it here. > > > > Cheers, > > Javi > >
Hi Eduardo, On Mon, Feb 09, 2015 at 09:34:03PM +0000, Eduardo Valentin wrote: > This change introduces a section in the Introduction Chapter to > list concepts used by the Thermal Framework. > > Signed-off-by: Eduardo Valentin <edubezval@gmail.com> > --- > Documentation/DocBook/thermal.tmpl | 129 ++++++++++++++++++++++++++++++++++++- > 1 file changed, 128 insertions(+), 1 deletion(-) > > diff --git a/Documentation/DocBook/thermal.tmpl b/Documentation/DocBook/thermal.tmpl > index f8fb8a2..66efed3 100644 > --- a/Documentation/DocBook/thermal.tmpl > +++ b/Documentation/DocBook/thermal.tmpl > @@ -84,5 +84,132 @@ > devices. > </para> > > - </chapter> > + <sect1 id="glossary"> > + <title>Glossary</title> > + <para>The Linux Kernel Thermal Framework uses a > + specific terminology to represent the entities involved > + in thermal constrained environments. This section > + summaries the terminology as dictionary. These terms are > + in use within the present document and in the source > + code of the Linux Kernel Thermal Framework. > + </para> > + <glossary> > + <glossentry> > + <glossterm>Thermal Zone</glossterm> > + <glossdef> > + <para>Thermal zones represent > + what is the current status of a > + thermal constrained zone in the > + hardware. The zone usually is a > + device or component. The status > + of a thermal zone is mainly with > + respect to temperature. > + Currently, the Linux Kernel > + Thermal Framework represents > + temperature in miliCelsius. The > + current abstraction covers for > + non negative temperatures and > + constraints. > + </para> Shall we point out that a thermal zone doesn't necessarily imply a thermal sensor? I find it very common to assume that if you have 10 sensors, you should have 10 thermal zones. From my point of view, a thermal zone is an area that has similar thermal characteristics. Therefore, the temperature of the thermal zone doesn't necessarily have to come from on sensor, and can be defined as a combination of the input from multiple thermal sensors. I don't know how to put this in proper words for the documentation, but I think it's worth hinting it here. Cheers, Javi -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2015-02-18 at 11:52 +0000, Javi Merino wrote: > Hi Eduardo, > > On Mon, Feb 09, 2015 at 09:34:03PM +0000, Eduardo Valentin wrote: > > This change introduces a section in the Introduction Chapter to > > list concepts used by the Thermal Framework. > > > > Signed-off-by: Eduardo Valentin <edubezval@gmail.com> > > --- > > Documentation/DocBook/thermal.tmpl | 129 ++++++++++++++++++++++++++++++++++++- > > 1 file changed, 128 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/DocBook/thermal.tmpl b/Documentation/DocBook/thermal.tmpl > > index f8fb8a2..66efed3 100644 > > --- a/Documentation/DocBook/thermal.tmpl > > +++ b/Documentation/DocBook/thermal.tmpl > > @@ -84,5 +84,132 @@ > > devices. > > </para> > > > > - </chapter> > > + <sect1 id="glossary"> > > + <title>Glossary</title> > > + <para>The Linux Kernel Thermal Framework uses a > > + specific terminology to represent the entities involved > > + in thermal constrained environments. This section > > + summaries the terminology as dictionary. These terms are > > + in use within the present document and in the source > > + code of the Linux Kernel Thermal Framework. > > + </para> > > + <glossary> > > + <glossentry> > > + <glossterm>Thermal Zone</glossterm> > > + <glossdef> > > + <para>Thermal zones represent > > + what is the current status of a > > + thermal constrained zone in the > > + hardware. The zone usually is a > > + device or component. The status > > + of a thermal zone is mainly with > > + respect to temperature. > > + Currently, the Linux Kernel > > + Thermal Framework represents > > + temperature in miliCelsius. The > > + current abstraction covers for > > + non negative temperatures and > > + constraints. > > + </para> > > Shall we point out that a thermal zone doesn't necessarily imply a > thermal sensor? I find it very common to assume that if you have 10 > sensors, you should have 10 thermal zones. From my point of view, a > thermal zone is an area that has similar thermal characteristics. > Therefore, the temperature of the thermal zone doesn't necessarily > have to come from on sensor, and can be defined as a combination of > the input from multiple thermal sensors. Currently since you can have one temperature input per zone (irrespective of whether the temperature is combination of many sensors or virtual sensor), so separating thermal sensor and zone can be more confusing IMO from a user space perspective. This was a feature proposed and submitted for thermal sysfs 2.0 (or next version), where sensors and zones are separated. I think there was some plan to adopt this. Rui Zhang can comment more. Thanks, Srinivas > > I don't know how to put this in proper words for the documentation, > but I think it's worth hinting it here. > > Cheers, > Javi -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/DocBook/thermal.tmpl b/Documentation/DocBook/thermal.tmpl index f8fb8a2..66efed3 100644 --- a/Documentation/DocBook/thermal.tmpl +++ b/Documentation/DocBook/thermal.tmpl @@ -84,5 +84,132 @@ devices. </para> - </chapter> + <sect1 id="glossary"> + <title>Glossary</title> + <para>The Linux Kernel Thermal Framework uses a + specific terminology to represent the entities involved + in thermal constrained environments. This section + summaries the terminology as dictionary. These terms are + in use within the present document and in the source + code of the Linux Kernel Thermal Framework. + </para> + <glossary> + <glossentry> + <glossterm>Thermal Zone</glossterm> + <glossdef> + <para>Thermal zones represent + what is the current status of a + thermal constrained zone in the + hardware. The zone usually is a + device or component. The status + of a thermal zone is mainly with + respect to temperature. + Currently, the Linux Kernel + Thermal Framework represents + temperature in miliCelsius. The + current abstraction covers for + non negative temperatures and + constraints. + </para> + </glossdef> + </glossentry> + <glossentry> + <glossterm>Thermal Sensors</glossterm> + <glossdef> + <para>Thermal sensors provide + temperature sensing capabilities + on thermal zones. Typical + devices are I2C ADC converters + and bandgaps. These are nodes + providing temperature data to + thermal zones. Thermal sensor + devices may control one or more + internal sensors. + </para> + </glossdef> + </glossentry> + <glossentry> + <glossterm>Trips Points</glossterm> + <glossdef> + <para>The trip node describes a + point in the temperature domain + in which the system takes an + action. This item describes just + the point, not the action. Trip + points are represented as + temperature in miliCelsius. The + current abstraction covers for + non negative temperatures. + </para> + </glossdef> + </glossentry> + <glossentry> + <glossterm>Thermal Governor</glossterm> + <glossdef> + <para>Thermal Governors + represent a policy to manage the + thermal zone device temperature. + The governor targets to keep + temperature in an acceptable + range which correlates to the + power budget, while maximizing + the performance. Governors can + be implemented in Kernel Space + or in User Space. + </para> + </glossdef> + </glossentry> + <glossentry> + <glossterm>Thermal Cooling Device</glossterm> + <glossdef> + <para>Cooling devices provide + control on power dissipation. + There are essentially two ways + to provide control on power + dissipation. First is by means + of regulating device + performance, which is known as + passive cooling. A typical + passive cooling is a CPU that + has dynamic voltage and + frequency scaling (DVFS), and + uses lower frequencies as + cooling states. Second is by + means of activating devices in + order to remove the dissipated + heat, which is known as active + cooling, e.g. regulating fan + speeds. In both cases, cooling + devices shall have a way to + determine the state of cooling + in which the device is. + </para> + </glossdef> + </glossentry> + <glossentry> + <glossterm>Cooling State</glossterm> + <glossdef> + <para>Any cooling device has a + range of cooling states (i.e. + different levels of heat + dissipation). For example a + fan's cooling states correspond + to the different fan speeds + possible. Cooling states are + referred to by single unsigned + integers, where larger numbers + mean greater heat dissipation. + The precise set of cooling + states associated with a device + (as referred to be the + cooling-min-state and + cooling-max-state properties) + should be defined in a + particular device's binding. + </para> + </glossdef> + </glossentry> + </glossary> + </sect1> + </chapter> </book>
This change introduces a section in the Introduction Chapter to list concepts used by the Thermal Framework. Signed-off-by: Eduardo Valentin <edubezval@gmail.com> --- Documentation/DocBook/thermal.tmpl | 129 ++++++++++++++++++++++++++++++++++++- 1 file changed, 128 insertions(+), 1 deletion(-)