Re: [RFC] the generic thermal layer enhancement

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

 



Hi, Durga,

On 三, 2012-05-30 at 04:44 -0600, R, Durgadoss wrote:
> Hi Rui,
> 
> > G1. supporting multiple cooling states for active cooling devices.
> > 
> >     The current active cooling device supports two cooling states only,
> >     please refer to the code below, in driver/thermal/thermal_sys.c
> >                 case THERMAL_TRIP_ACTIVE:
> >                         ...
> >                         if (temp >= trip_temp)
> >                                 cdev->ops->set_cur_state(cdev, 1);
> >                         else
> >                                 cdev->ops->set_cur_state(cdev, 0);
> >                         break;
> > 
> >     This is an ACPI specific thing, as our ACPI FAN used to support
> >     ON/OFF only.
> >     I think it is reasonable to support multiple active cooling states
> >     as they are common on many platforms, and note that this is also
> >     true for ACPI 3.0 FAN device (_FPS).
> > 
> > G2. introduce cooling states range for a certain trip point
> > 
> >     This problem comes with the first one.
> >     If the cooling devices support multiple cooling states, and surely
> >     we may want only several cooling states for a certain trip point,
> >     and other cooling states for other active trip points.
> >     To do this, we should be able to describe the cooling device
> >     behavior for a certain trip point, rather than for the entire
> >     thermal zone.
> > 
> > G3. kernel thermal passive cooling algorithm
> > 
> >     Currently, tc1 and tc2 are hard requirements for kernel passive
> >     cooling. But non-ACPI platforms do not have this information
> >     (please correct me if I'm wrong).
> >     Say, for the patches here
> >     http://marc.info/?l=linux-acpi&m=133681581305341&w=2
> >     They just want to slow down the processor when current temperature
> >     is higher than the trip point and speed up the processor when the
> >     temperature is lower than the trip point.
> > 
> >     According to Matthew, the platform drivers are responsible to
> >     provide proper tc1 and tc2 values to use kernel passive cooling.
> >     But I'm just wondering if we can use something instead.
> >     Say, introduce .get_trend() in thermal_zone_device_ops.
> >     And we set cur_state++ or cur_state-- based on the value returned
> >     by .get_trend(), instead of using tc1 and tc2.
> 
> Yes we should do that. I would also like to remove these values from the
> registration API's. That makes the registration code way more simpler.
> Right now, I do not see any driver using thermal_zone_device_register
> with values other than 0's for these.
> 
Agreed.

> > 
> > G4. Multiple passive trip points
> > 
> >     I get this idea also from the patches at
> >     http://marc.info/?l=linux-acpi&m=133681581305341&w=2
> > 
> >     IMO, they want to get an acceptable performance at a tolerable
> >     temperature.
> >     Say, a platform with four P-states. P3 is really low.
> >     And I'm okay with the temperature at 60C, but 80C? No.
> >     With G2 resolved, we can use processor P0~P2 for Passive trip point
> >     0 (50C), and P3 for Passive trip point 1 (70C). And then the
> >     temperature may be jumping at around 60C or even 65C, without
> >     entering P3.
> > 
> >     Further more, IMO, this also works for ACPI platforms.
> >     Say, we can easily change p-state to cool the system, but using
> >     t-state is definitely what we do not want to see. The current
> >     implementation does not expose this difference to the generic
> >     thermal layer, but if we can have two passive trip points, and use
> >     p-state for the first one only... (this works if we start polling
> >     after entering passive cooling mode, without hardware notification)
> > 
> > G5. unify active cooling and passive cooling code
> > 
> >     If G4 and G5 are resolved, a new problem to me is that there is no
> >     difference between passive cooling and active cooling except the
> >     cooling policy.
> 
> Correct...
> 
> >     Then we can share the same code for both active and passive cooling.
> >     maybe something like:
> 
> Or just use TRIP_PASSIVE...
> 
what do you mean? Remove THERMAL_TRIP_ACTIVE?

Maybe I'm not clear enough here.
We may disable the passive cooling or active cooling because of the
thermal management policy.
Say, if we are running on AC, we may want to use active cooling only to
avoid any performance loss. If we are running on Battery, we may want to
use passive cooling only to get longer battery life.

So the code would be:
   static void thermal_cooling()
   {
      ...
      tz->ops->get_trend();
      if (trend == HEATING)
         cdev->ops->set_cur_state(cdev, cur_state++);
      else if (trend == COOLING)
         cdev->ops->set_cur_state(cdev, cur_state--);
   }

   void thermal_zone_device_update()
   {
       ...
       case THERMAL_TRIP_ACTIVE:
            if (policy & ACTIVE_COOLING)
               thermal_cooling();
            break;
       case THERMAL_TRIP_PASSIVE:
            if (policy & PASSIVE_COOLING)
               thermal_cooling();
            break;
       ...
   }

thanks,
rui


_______________________________________________
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