Re: [linux-pm] [RFC] the generic thermal layer enhancement

Zhang Rui
2012-05-30T08:49:34Z

On 三, 2012-05-30 at 16:49 +0800, Zhang Rui wrote:
> Hi, all,
>
> It is great to see more and more users of the generic thermal layer.
> But as we know, the original design of the generic thermal layer comes
> from ACPI thermal management, and some of its implementation seems to be
> too ACPI specific nowadays.
>
> Recently I'm thinking of enhance the generic thermal layer so that it
> works well for more platforms.
>
> Below are some thoughts of mine, after reading the patches from Amit
> Daniel Kachhap, and ACPI 3.0 thermal model. Actually, I have started
> coding some RFC patches. But I do really want to get feedback from you
> before going on.
>
> G1. supporting multiple cooling states for active cooling devices.
>
> The current active cooling device supports two cooling states only,
> please refer to the code below, in driver/thermal/thermal_sys.c
> case THERMAL_TRIP_ACTIVE:
> ...
> if (temp >= trip_temp)
> cdev->ops->set_cur_state(cdev, 1);
> else
> cdev->ops->set_cur_state(cdev, 0);
> break;
>
> This is an ACPI specific thing, as our ACPI FAN used to support
> ON/OFF only.
> I think it is reasonable to support multiple active cooling states
> as they are common on many platforms, and note that this is also
> true for ACPI 3.0 FAN device (_FPS).
>
> G2. introduce cooling states range for a certain trip point
>
> This problem comes with the first one.
> If the cooling devices support multiple cooling states, and surely
> we may want only several cooling states for a certain trip point,
> and other cooling states for other active trip points.
> To do this, we should be able to describe the cooling device
> behavior for a certain trip point, rather than for the entire
> thermal zone.
>
> G3. kernel thermal passive cooling algorithm
>
> Currently, tc1 and tc2 are hard requirements for kernel passive
> cooling. But non-ACPI platforms do not have this information
> (please correct me if I'm wrong).
> Say, for the patches here
> http://marc.info/?l=linux-acpi&m=133681581305341&w=2

Sorry, forgot to cc Amit, the author of this patch set.

thanks,
rui
> They just want to slow down the processor when current temperature
> is higher than the trip point and speed up the processor when the
> temperature is lower than the trip point.
>
> According to Matthew, the platform drivers are responsible to
> provide proper tc1 and tc2 values to use kernel passive cooling.
> But I'm just wondering if we can use something instead.
> Say, introduce .get_trend() in thermal_zone_device_ops.
> And we set cur_state++ or cur_state-- based on the value returned
> by .get_trend(), instead of using tc1 and tc2.
>
> G4. Multiple passive trip points
>
> I get this idea also from the patches at
> http://marc.info/?l=linux-acpi&m=133681581305341&w=2
>
> IMO, they want to get an acceptable performance at a tolerable
> temperature.
> Say, a platform with four P-states. P3 is really low.
> And I'm okay with the temperature at 60C, but 80C? No.
> With G2 resolved, we can use processor P0~P2 for Passive trip point
> 0 (50C), and P3 for Passive trip point 1 (70C). And then the
> temperature may be jumping at around 60C or even 65C, without
> entering P3.
>
> Further more, IMO, this also works for ACPI platforms.
> Say, we can easily change p-state to cool the system, but using
> t-state is definitely what we do not want to see. The current
> implementation does not expose this difference to the generic
> thermal layer, but if we can have two passive trip points, and use
> p-state for the first one only... (this works if we start polling
> after entering passive cooling mode, without hardware notification)
>
> G5. unify active cooling and passive cooling code
>
> If G4 and G5 are resolved, a new problem to me is that there is no
> difference between passive cooling and active cooling except the
> cooling policy.
> Then we can share the same code for both active and passive cooling.
> maybe something like:
>
> case THERMAL_TRIP_ACTIVE:
> case THERMAL_TRIP_PASSIVE:
> ...
> tz->ops->get_trend();
> if (trend == HEATING)
> cdev->ops->set_cur_state(cdev, cur_state++);
> else if (trend == COOLING)
> cdev->ops->set_cur_state(cdev, cur_state--);
> break;
>
> Here are the gaps in my point of view, I'd like to get your ideas about
> which are reasonable and which are not.
>
> Any comments are appreciated! Thanks!
>
> -rui
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html