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. > > Thanks, > Mark. > > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
