Hi Guenter,
[snip..]
> > It was just a suggestion from me that we can handle the interrupts from
> > within therm_throt since there was code in there, doing this already.
> > I did not know (in fact do not know..) how to catch these interrupts
> > inside coretemp. That's why I thought of adding code in therm_throt.
> >
> > If it's not the right way to go, I am open to other ideas.
> >
> > On the other hand, I am fine with the idea of having tempX_threshold[0-7]
> > and their alarms. We can use the 'status' bits in the THERM_STATUS
> > register to represent the alarm. The logic can be something like this:
> >
> > //Log bits indicate the input temperature reached the configured threshold;
> > //but we do not know from which direction.
> > if (msr_val & THERM_LOG_THRESHOLD0) {
> > //if the status bit is one, the input temperature is higher than the
> > //configured threshold. If it is zero, the input temperature is lower
> > //than the configured threshold.
> > bool alarm = msr_val & THERM_STATUS_THRESHOLD0;
> > print: alarm
> > //Let the user space take care of 0/1 from the *_alarm interfaces.
> > }
> >
> So there is a clear notion of "exceed" associated with those thresholds ?
Sorry Guenter. I don't get what you mean by this :-(
> I thought there was just an interrupt whenever the threshold is reached
> from either side. Looks like I missed that one.
>
> Personally, I don't think "alarm" would be appropriate here, since we don't
> know if the threshold is supposed to be a lower or an upper limit, and if
> it reflects an alarm to start with. If we define a new set of attributes for
> unspecified thresholds, I would prefer something like
> "tempX_thresholdY_triggered".
>
For me, it looks like, we need not know whether the threshold is upper or lower.
Anyway, for every threshold, we will get two interrupts (for either direction)
So, the user space can assume either a lower threshold and look for 0 in the
Corresponding alarm interface Or a higher threshold and look for 1 in the
alarm interface. Will this not work ?
Thanks,
Durga
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
