[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1342144273.1682.237.camel@rui.sh.intel.com>
Date: Fri, 13 Jul 2012 09:51:13 +0800
From: Zhang Rui <rui.zhang@...el.com>
To: "R, Durgadoss" <durgadoss.r@...el.com>
Cc: Wei Ni <wni@...dia.com>, "Brown, Len" <len.brown@...el.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"khali@...ux-fr.org" <khali@...ux-fr.org>,
"joe@...ches.com" <joe@...ches.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-tegra@....kernel.org" <linux-tegra@....kernel.org>,
"acourbot@...dia.com" <acourbot@...dia.com>
Subject: 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:wni@...dia.com]
> > Sent: Thursday, July 12, 2012 3:53 PM
> > To: Zhang, Rui; Brown, Len; akpm@...ux-foundation.org; khali@...ux-fr.org;
> > joe@...ches.com; R, Durgadoss
> > Cc: linux-kernel@...r.kernel.org; linux-tegra@....kernel.org;
> > acourbot@...dia.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 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