Re: [RFC] the generic thermal layer enhancement

[Eduardo Valentin <eduardo.valentin@ti.com>]

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@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm