On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
> >> thermal_zone {
> >> type = "CPU";
> >
> > So what does this exactly mean? What is so special about CPU? What other
> > types you've got there? (Am I just lazy not looking at the numerous
> > links you provided? ;-)
>
> Hehehe. OK. Type is supposed to describe what your zone is representing.
As in "a name"? So, for example "The board", "PSU"? What I meant to ask
was: does the string carry any meaning?
> >> monitoring_device = <&sensor@xxxx
> >> &sensor@yyyy>;
> >>
> >> mask = <0x03>; /* trips writability */
> >> passive_delay = <250>; /* milliseconds */
> >> polling_delay = <1000>; /* milliseconds */
> >> policy = "step_wise";
> >
> > The word "policy" doesn't sound to me like a "hardware feature",
> > wouldn't you agree?
>
> Agreed. As I mentioned in other email, we can leave this to OS decide
> what to use, by default, for instance.
Cool, I believe it is the right thing to do.
> >
> >> trips {
> >> alert@100000{
> >> temperature = <100000>; /* milliCelsius
> >> hysteresis = <2000>; /* milliCelsius */
> >> type = <THERMAL_TRIP_PASSIVE>;
> >> };
> >> crit@125000{
> >> temperature = <125000>; /* milliCelsius
> >> hysteresis = <2000>; /* milliCelsius */
> >> type = <THERMAL_TRIP_CRITICAL>;
> >> };
> >> };
> >> bind_params {
> >> action@0{
> >> cooling_device = "thermal-cpufreq";
> >
> > Why is it a string? It seems very Linux-y... (cpufreq) Is there any
> > particular reason not to have phandles to the fans that have any impact
> > on the zone?
>
> Because fans are not the only way to cool your system, specially those
> systems that don't feature fans. Managing the speed of your CPU is one
> example of lowering temperature without fans. Managing the load on your
> system is another way. These are obviously, virtual concepts. And
> because we have physical ways and logical ways to cool the zone, then I
> didnt put a phandle to a device there.
"virtual concepts"... This is where my problem lies... It's not hardware
so it doesn't seem to belong in the tree at the first sight. Shouldn't
it focus on "physical data" instead? As in: point at devices that have
some impact on the conditions? For example, you can say "please, do the
right thing to cool your environment down" to both CPU and fan, can't
you? The "cooling driver" for the CPU would know that it has to slow
down, while a driver for the fan would know that it has to speed up ;-)
What I'm trying to say is that in my opinion the tree should simply link
the object, the sensor and the actuator. Nothing more, nothing less.
Thanks for your time!
Pawel
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
