On Wed, May 14, 2008 at 11:37:22AM -0400, Len Brown wrote: > No. > ACPI thermal zones with no passive trip points can be used > to simply report interesting temperature events to user-space > (via the spiffy new generic thermal class). > User-space then invokes corrective action -- which may be > something _other_ than throttling the CPU. If user space wants to decouple ACPI from the generic thermal model, then it can do so by using the mode file in the sysfs node. That doesn't change. > > Menlow has a more complex thermal model than machines we've seen up to > > now, but I was under the impression that this was to be handled by the > > new generic thermal class rather than the existing ACPI code. I don't > > see this patch as being in conflict with supporting that. > > No. > It is a direct conflict. > > Say the thermal zone is related to the communications chip. > If we create a phantom passive trip point for that zone > and throttle the CPU when it fires, we're shooting ourselves > in the head (when we should be poking ourselves in the ear, or some such:-) As I said, if userspace is managing the thermal envelope then it has to indicate this by writing a value into sysfs (see the get_mode and set_mode calls in the thermal_zone_device_ops structure). If that's done then it indicates to the kernel that it should leave control up to the userspace application. acpi_thermal_check will then return without handling the trip points (including the critical one, which I'm not sure sounds like a good idea...) As a result, this patch doesn't conflict with the userspace thermal management at all. The moment the userspace policy daemon starts up it'll disable the code that would fire on the passive trip point. If you're not using a userspace policy daemon, then the only hardware that can be used to drop the temperature is the processor. Which is what this patch does. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- 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
