On Fri, 16 Jan 2009, Thomas Renninger wrote: > On Wednesday 17 December 2008 04:12:15 Matthew Garrett wrote: > > On Wed, Dec 17, 2008 at 11:02:18AM +0800, Zhang Rui wrote: > > > On Mon, 2008-12-08 at 20:59 +0800, Matthew Garrett wrote: > > > > They're needed if you want to implement any sort of sensible > > > > implementation of passive cooling. They might not be expressed in quite > > > > the same way, but the basic concept is identical. > > > > > > Seeing tc1, tc2, tsp under /sys/class/thermal/ is not good because we > > > don't want to make the generic thermal driver too ACPI specific, before > > > we've really concluded some basic concepts for passive cooling. > > > so why not do this after we have another generic thermal user with > > > passive cooling support? > > > > They're not exposed in /sys/class, and I don't think doing so is a > > sensible thing to do. If you know values for the hardware in question > > then they should be supplied by the firmware. But even so, the generic > > thermal layer needs a way of implementing passive cooling. Doing so > > involves deriving a formula to describe the behaviour of the system > > around the passive trip level, and the best used implementation of that > > in Linux at the moment is the one described in the ACPI spec. I don't > > see any real need to generate new terms to describe well documented > > concepts, even if other implementations don't use ACPI. > > If others need a specific algorithm, another (set of) callback function(s) > could be added later which would provide the possibility of > a platform specific override? yeah, that is probalby the way to do it. But until we have a 2nd customer besides ACPI, we are kidding outselves if we think we can dream up a real "generic" that will not need later modification... -- Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
