On 01/06/2014 10:54 PM, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On 06-01-2014 09:51, Mark Rutland wrote: >> On Thu, Jan 02, 2014 at 05:50:06PM +0000, Matthew Longnecker wrote: >>> >>>> I think the platform driver may set governor for the thermal zone, >>>> so how about to add a property named as "governor", >>>> and parse it to tzp->governor_name, >>>> something like: >>>> ret = of_property_read_string(child, "governor", &str); >>>> if (ret == 0) >>>> if (strlen(str) < THERMAL_NAME_LENGTH) >>>> strcpy(tzp->governor_name, str); >>>> >>>> Thanks. >>>> Wei. >>> >>> DT is supposed to describe the hardware, right? The governor isn't >>> hardware -- it's a software control policy. On the other hand, that >>> control policy must be tuned according to the behaviors of the platform >>> hardware otherwise the system will be unstable. >>> >>> Is it appropriate to be naming the governor in DT? If so, is it equally >>> appropriate to describe any governor-specific parameters in DT (even >>> though they are pure software constructs)? >> >> The dt should be relatively static -- if the hardware doesn't change the >> dt shouldn't have to. >> >> The governers are not static. We can introduce new ones and throw away >> old ones at any time. Tuning parameters can also change at any time. >> >> I'd prefer to not have governer details described in the dt, and the >> choice of governer and configuration of its tuning parameters should be >> made at runtime somehow. > > Agreed. Yes, I think so, but the of-thermal driver handle the thermal_zone_device_register, and pass the "tzp" without governor_name, so the created thermal_zone's governor will be NULL, then it can't run into the governor->throttle() if needed. And currently there have no interface to support updating governor and configuration at runtime. I think it's better to initialize the governor_name when register the thermal zone device in the of-thermal driver. Thanks. > >> >> Thanks, >> Mark. >> >> > > _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
