On 10 Nov 25, Yong Shen wrote:
> On Wed, Nov 24, 2010 at 7:02 PM, Amit Kucheria <amit.kuche...@linaro.org>
> wrote:
> > On 10 Nov 24, Yong Shen wrote:
> >> Hi there,
> >>
> >> In power management group, we have a working item of exposing thermal
> >> information to user space through sysfs. However, so far, the thermal
> >> sensor drivers under 'drivers/hwmon' expose their information in
> >> various nodes under sysfs, which makes information collection
> >> difficult.
> >> Intel's thermal framework is located under 'drivers/thermal', but all
> >> the thermal drivers under hwmon don't make use of it due to some
> >> reason (part of the reason for this situation may be that intel's
> >> thermal framework is comparatively new therefore when those sensor
> >> drivers were implemented they did not have a framework to register
> >> themselves.)
> >
> > It is not that new (after checking)
> >
> > $ git describe 203d3d4aa482339b4816f131f713e1b8ee37f6dd
> > v2.6.24-6482-g203d3d4
> >
>
> I meant it is newer than drivers/hwmon which was first introduced in
> 2005, while drivers/thermal was introduced in 2008.
> >> We like to find out a simple and unified way to expose thermal related
> >> information, intel's thermal interface could be a choice. Using
> >> thermal framework is straightforward, below is a sample driver for
> >> this purpose. Thus all the information goes to /sys/class/thermal,
> >> like temperature, mode...
> >>
> >> ...
> >> #include <linux/module.h>
> >> #include <linux/device.h>
> >> #include <linux/thermal.h>
> >> #include <linux/hwmon.h>
> >> static int thermal_get_temp(struct thermal_zone_device *thermal,
> >> unsigned long *temp)
> >> {
> >> *temp = xxx;
> >> return 0;
> >> }
> >> static struct device *hwmon;
> >> static struct thermal_zone_device *thermal;
> >> static struct thermal_zone_device_ops ops = {
> >> .get_temp = thermal_get_temp,
> >> };
> >> static int __init sensor_init(void)
> >> {
> >> ...
> >> thermal = thermal_zone_device_register("sample", 0, 0,
> >> &ops, 0, 0, 0, 0);
> >> }
> >> static void __exit sensor_cleanup(void)
> >> {
> >> ...
> >> }
> >> module_init(sensor_init);
> >> module_exit(sensor_cleanup);
> >>
> >> Are there any better ideas about this? Your comments are highly
> >> appreciated.
> >
> > What is important is not just a user-space interface (in /sys), but also a
> > in-kernel interface that drivers can call.
> >
> > I had a brief look at the thermal API. There are two types of devices:
> > * Thermal Zone (a sensor)
> > * Cooling device (fan, processor, perhaps even a policy manager?)
> >
> > You can bind cooling devices with thermal zones.
> >
> > Can the thermal_zone_bind_cooling_device() function be used by external
> > drivers for registering call-backs for thermal trip conditions?
>
> Yes. If I understand right, you also want to let this thermal
> framework communicate directly with other kernel modules or drivers.
> In this case, other modules can appear as a cooling device although
> they don't have to be a real one, and register themselves with a
> thermal_cooling_device_ops. When thermal zone device updates its
> status, it will go through all the trip points and invoke related
> binding cooling devices to set their states (ops->set_cur_state).
> Correct me.
Yes that is the possibility I'm thinking of. Now the question to ask the
various SoC vendors is, is that the interface they'd prefer?
Kevin, any thoughts?
/Amit
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
