Re: [RFC] the generic thermal layer enhancement

Hello Durga,

On Wed, May 30, 2012 at 11:05:18AM +0000, R, Durgadoss wrote:

Hi Eduardo,

quoted

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?

quoted

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 :-)

quoted

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...

quoted

quoted

quoted

    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.

quoted

quoted

quoted

         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!

quoted

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