Re: [RFC] the generic thermal layer enhancement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

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

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

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

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

Thanks,
Durga

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



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux