Message-ID: <50EA953B.3040006@nvidia.com>
Date:	Mon, 7 Jan 2013 17:28:27 +0800
From:	Wei Ni <wni@...dia.com>
To:	"R, Durgadoss" <durgadoss.r@...el.com>
CC:	"Zhang, Rui" <rui.zhang@...el.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"eduardo.valentin@...com" <eduardo.valentin@...com>,
	"hongbo.zhang@...aro.org" <hongbo.zhang@...aro.org>
Subject: Re: [PATCH 6/9] Thermal: Add Documentation to new APIs

On 01/07/2013 04:53 PM, R, Durgadoss wrote:
>> -----Original Message-----
>> From: Wei Ni [mailto:wni@...dia.com]
>> Sent: Monday, January 07, 2013 2:10 PM
>> To: R, Durgadoss
>> Cc: Zhang, Rui; linux-pm@...r.kernel.org; linux-kernel@...r.kernel.org;
>> eduardo.valentin@...com; hongbo.zhang@...aro.org
>> Subject: Re: [PATCH 6/9] Thermal: Add Documentation to new APIs
>>
>> On 01/07/2013 03:13 PM, Durgadoss R wrote:
>>> This patch adds Documentation for the new APIs
>>> introduced in this patch set. The documentation
>>> also has a model sysfs structure for reference.
>>>
>>> Signed-off-by: Durgadoss R <durgadoss.r@...el.com>
>>> ---
>>>  Documentation/thermal/sysfs-api2.txt |  248
>> ++++++++++++++++++++++++++++++++++
>>>  1 file changed, 248 insertions(+)
>>>  create mode 100644 Documentation/thermal/sysfs-api2.txt
>>>
>>> diff --git a/Documentation/thermal/sysfs-api2.txt
>> b/Documentation/thermal/sysfs-api2.txt
>>> new file mode 100644
>>> index 0000000..ffd0402
>>> --- /dev/null
>>> +++ b/Documentation/thermal/sysfs-api2.txt
>>> @@ -0,0 +1,248 @@
>>> +Thermal Framework
>>> +-----------------
>>> +
>>> +Written by Durgadoss R <durgadoss.r@...el.com>
>>> +Copyright (c) 2012 Intel Corporation
>>> +
>>> +Created on: 4 November 2012
>>> +Updated on: 18 December 2012
>>> +
>>> +0. Introduction
>>> +---------------
>>> +The Linux thermal framework provides a set of interfaces for thermal
>>> +sensors and thermal cooling devices (fan, processor...) to register
>>> +with the thermal management solution and to be a part of it.
>>> +
>>> +This document focuses on how to enable new thermal sensors and
>> cooling
>>> +devices to participate in thermal management. This solution is intended
>>> +to be 'light-weight' and platform/architecture independent. Any thermal
>>> +sensor/cooling device should be able to use the infrastructure easily.
>>> +
>>> +The goal of thermal framework is to expose the thermal sensor/zone and
>>> +cooling device attributes in a consistent way. This will help the
>>> +thermal governors to make use of the information to manage platform
>>> +thermals efficiently.
>>> +
>>> +The thermal sensor source file can be generic (can be any sensor driver,
>>> +in any subsystem). This driver will use the sensor APIs and register with
>>> +thermal framework to participate in platform Thermal management. This
>>> +does not (and should not) know about which zone it belongs to, or any
>>> +other information about platform thermals. A sensor driver is a
>> standalone
>>> +piece of code, which can optionally register with thermal framework.
>>> +
>>> +However, for any platform, there should be a platformX_thermal.c file,
>>> +which will know about the platform thermal characteristics (like how many
>>> +sensors, zones, cooling devices, etc.. And how they are related to each
>> other
>>> +i.e the mapping information). Only in this file, the zone level APIs should
>>> +be used, in which case the file will have all information required to attach
>>> +various sensors to a particular zone.
>>> +
>>> +This way, we can have one platform level thermal file, which can support
>>> +multiple platforms (may be)using the same set of sensors (but)binded in
>>> +a different way. This file can get the platform thermal information
>>> +through Firmware, ACPI tables, device tree etc.
>>> +
>>> +Unfortunately, today we don't have many drivers that can be clearly
>>> +differentiated as 'sensor_file.c' and 'platform_thermal_file.c'.
>>> +But very soon we will need/have. The reason I am saying this is because
>>> +we are seeing a lot of chip drivers, starting to use thermal framework,
>>> +and we should keep it really light-weight for them to do so.
>>> +
>>> +An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver
>>> +In one platform this sensor can belong to 'ZoneA' and in another the
>>> +same can belong to 'ZoneB'. But, emc1403.c does not really care about
>>> +where does it belong. It just reports temperature.
>>> +
>>> +1. Terminology
>>> +--------------
>>> +This section describes the terminology used in the rest of this
>>> +document as well as the thermal framework code.
>>> +
>>> +thermal_sensor: Hardware that can report temperature of a particular
>>> +               spot in the platform, where it is placed. The temperature
>>> +               reported by the sensor is the 'real' temperature reported
>>> +               by the hardware.
>>> +thermal_zone:  A virtual area on the device, that gets heated up. It may
>>> +               have one or more thermal sensors attached to it.
>>> +cooling_device:        Any component that can help in reducing the
>> temperature of
>>> +               a 'hot spot' either by reducing its performance (passive
>>> +               cooling) or by other means(Active cooling E.g. Fan)
>>> +
>>> +trip_points:   Various temperature levels for each sensor. As of now, we
>>> +               have four levels namely active, passive, hot and critical.
>>> +               Hot and critical trip point support only one value whereas
>>> +               active and passive can have any number of values. These
>>> +               temperature values can come from platform data, and are
>>> +               exposed through sysfs in a consistent manner. Stand-alone
>>> +               thermal sensor drivers are not expected to know these values.
>>> +               These values are RO.
>>> +thresholds:    These are programmable temperature limits, on reaching
>> which
>>> +               the thermal sensor generates an interrupt. The framework is
>>> +               notified about this interrupt to take appropriate action.
>>> +               There can be as many number of thresholds as that of the
>>> +               hardware supports. These values are RW.
>>
>> Hi,
>> When generate interrupt, we could call something like
>> notify_thermal_framework(), is it right? but it just notify the
>> framework, how to notify the platform driver? I think the platform
>> driver will wish to update the limited values when interrupt occur.
>> Will we have a thermal zone fops like ops.notify()?
>> I noticed there have "struct thermal_zone *ops" in the thermal_zone
>> structure, will it be used for callback?
> 
> Yes, you are right. I missed adding a .notify() call back to thermal_zone ops.
> I will wait to see if we get more comments on this version of the patches.
> If so, will fix this in v3. Otherwise, will submit a patch, once these
> patches make it to Rui's tree. Hope this works for you :-)

Got it, thanks :)

Wei.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists