Re: [RFC] the generic thermal layer enhancement

[Eduardo Valentin <eduardo.valentin@xxxxxx>]

hello,

On Thu, May 31, 2012 at 11:32:41AM +0800, Zhang Rui wrote:
> On 三, 2012-05-30 at 14:17 +0300, Eduardo Valentin wrote:
> > 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?
> > 
> yep.
> BTW, Overlaps should be possible and we should handle this as well.
> > 
> > 
> > > 
> > > > 
> > > > 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...
> > 
> Hah, seems a lot of work is in progress in this area.
> 
> > > 
> > > > > >     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?
> > 
> Durga and I are investigating how to introduce some concepts like
> "influence/weight" to generic thermal layer. :)

What do you mean here? Describing the cooling devices effectiveness on each zone and
derive algorithms to act accordingly?

> 
> thanks,
> rui
> 
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm