Hello Durga, On Wed, May 30, 2012 at 11:05:18AM +0000, R, Durgadoss wrote: > Hi Eduardo, > > > > > 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. > > True, We want to bind the levels of cooling with the trips points a thermal zone has. > But we might not get a 1-1 mapping always. Just to make sure we are all taking the same thing. In this case a cooling device would have 1-N states. And this set could be partitioned and each partition would be assigned to a specific trip point of a thermal zone, right? > > > > > 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. > > I realize I just said the same thing :-) Cool :-) > > > > > We could have generic trending computation though. Based on timestamping > > and temperature reads, and make it available for zones that want to used it. > > Agree, but I would like this go into the platform thermal drivers. And then when > those drivers notify the framework they can specify the trend also. This sort of > notification is not there, but that is what I am implementing these days.. > Hope to submit this patch in a week's time.. Nice, I actually have something being cooked for the same thing. We should probably align to avoid work duplication... > > > > > 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? > > To me, it does not matter. It is up to the framework to decide and throttle, > the respective cooling devices according to the trend. OK. For me it doesn't really matter as well. Having a simplified zone update is better. > > > > > > > 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? > > Yes, and that’s what we want too :-) Nice! > > > 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? > > > > G7. How do we solve cooling devices being shared between different thermal > > zones? > > Should we have a better cooling device constraint management? > > This is another thing that was haunting me for quite some time. > And What I have in mind is a mapping kind of thing in the platform layer, > that will provide details about which cooling device is shared with whom. > The framework can then use this and figure out the association among various devices. > I am testing it out, and will submit once it comes to a good shape. Right, I am not sure we want to go in this direction? Maybe a better way would be to have sort of pm/thermal contraint framework, which would map these per device, at LDM level? I am copying Jean-Pihet, he has been working in this front. Jean, any thoughts? > > Thanks, > Durga > All Best, -- Eduardo _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
