Hi, Eduardo, On 三, 2012-05-30 at 13:30 +0300, Eduardo Valentin wrote: > > > > > > 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. > > For G1+G2, I agree with your proposal. I had some discussion with Amit > regarding this. In his series of patches we increase / decrease the cooling > device state linearly and steadily. > > But if we would have what you are saying, we could bind cooling device > set of states with trip points. > Great. But further more, IMO, with G3/G4 solved, this patch set can use passive trip points instead of active trip points for processors, right? > > > > > > 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. > > I fully support this option and could cook up something on this. > The TC1 and TC2 should go inside the .get_trend() callbacks for ACPI. > Should probably go away from the registration function that we have > currently. > > We could have generic trending computation though. Based on timestamping > and temperature reads, and make it available for zones that want to used it. > Agreed. I already have this patch in hand. > > > > > > 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. > > Yeah, I guess we need to solve G1+G2 first to allow this. yes. > But I also agree > that ideally, there should be possibility to have multiple passive trip points. > I think this is still an open question for Amit. As I mentioned above, the idea comes from Amit's patch set, and what I'm doing here is to try to make the passive cooling implementation works well on exynos platforms. As we know, in his patch set, MONITOR_ZONE and WARN_ZONE are mapped to active trip points. But actually, with G2/G3/G4 solved, they SHOULD be passive trip points as all the cooling devices are processors, right? So, my question, and probably this is also the question from Matthew, would be: Why we need two passive trip points? What if we use all p-state for MONITOR_ZONE and discard the WARN_ZONE? I'd like to see Amit's explanation on this. :) > > > > > > 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. > > OK... > > > > 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(); > > Would the get_trend take into account if we are cooling with active or passive > cooling device? > YES. We need this as a hint for active/passive cooling management. But how it actually works depends on the implementation of the .get_trend callback in the platform driver. Say, for active trip points, .get_trend can always return HEATING, so that fan will start to run faster and faster when the temperature keeps higher than the trip point. Or it can return COOLING when cur_temperature < last_temperature, so that the fan will slow down when the temperature is dropping, but still higher than the trip point. > > > if (trend == HEATING) > > > cdev->ops->set_cur_state(cdev, cur_state++); > > > else if (trend == COOLING) > > > cdev->ops->set_cur_state(cdev, cur_state--); > > > break; > > I believe we should have something for temperature stabilization there as well. > > Besides, if we go with this generic policy, then the zone update would be much > simpler no? > Agree with Durga. > > > > > > Here are the gaps in my point of view, I'd like to get your ideas about > > > which are reasonable and which are not. > > Here are some other thoughts: > G6. Another point is, would it make sense to allow for policy extension? Meaning, > the zone update would call a callback to request for update from the zone > device driver? > I'm not against this idea. But do we really have a request for such a case? And BTW, if we really have such a request, I think the first thing to do is to investigate if this is a general request that should be implemented in the generic thermal layer, rather than go to the zone device driver directly? > G7. How do we solve cooling devices being shared between different thermal zones? > Should we have a better cooling device constraint management? > Maybe we just need a simple Arbitrator in kernel? When changing a cooling device state, it can only override the cur_state value for the current cooling device instance! And the code should parse all the cooling device instance of this cooling device, and choose the deepest cooling state. what do you think? > G8. On same topic as G7, how are we currently making sure that thermal constraints > don't get overwritten by, let's say, userspace APIs? what kind of userspace APIs can change this? > I guess the generic CPU cooling > propose by Amit suffers of an issue. If user sets cpufreq governor to userspace > and sets the frequency to its maximum, say in a busy loop, the thermal cooling > could potentially be ruined. > that's true, but I don't think that's the case we need to cover. Setting cpufreq governor to "Userspace" means user needs to be responsible for the p-state controlling. If the system overheats, that's the thing that the user needs to worry about. > G9. Is there any possibility to have multiple sensors per thermal zone? > I do not think we need to consider this situation, until there is such an requirement. > G10. Do we want to represent other sensing stimuli other that temperature? Say, > current sensing? > what do you mean by "current sensing"? > G11. Do we want to allow for cross zoning policies? Sometimes a policy may use > temperature from different thermal zone in order to better represent what > is going on in its thermal zone. > Good question. This bothered me a lot actually. Each zone device just represents a certain part of the overall system, and these different zones may interact with each other. But the current implementation does not take care of this. Unfortunately I do not have any ideas about this yet. :) > > > > > > Any comments are appreciated! Thanks! > > > Thanks to you for starting this up! The above are points that come to my mind now. > I will keep updating the list if something else come to my mind. > They are all good points, thank you for your valuable feedback, Eduardo! -rui _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
