Intel 6 SERIES CHIPSET - DATASHEET 01-2011 Datasheet page 234

When the external controller sees the TEMP_ALERT# signal low, it knows some device
is out of range. It can read the temperatures and then change the limits for the
devices. Note that it may take up to 250 ms before the actual writes cause the signal to
change state. For instance if the PCH is at 105 degrees and the limit is 100, the alert is
triggered. If the controller changes the limits to 110, the TEMP_ALERT# signal may
remain low until the next thermal sampling window (every 200 ms) occurs and only
then go high, assuming the PCH was still within its limits.
At boot, the controller can monitor the TEMP_ALERT# signal state. When BIOS has
finished all the initialization and enabled the temperature comparators, the
TEMP_ALERT# signal will be asserted since the default state of the limit registers is 0h;
hence, when the PCH first reads temperatures, they will be out of range. This is the
positive indication that the external controller may now read thermal information and
get valid data. If the TEMP_ALERT# signal is enabled and not asserted within 30
seconds after PLTRST#, the external controller should assume there is a fatal error and
handle accordingly. In general the TEMP_ALERT# signal will assert within a 1–4
seconds, depending on the actual BIOS implementation and flow.
Note: The TEMP_ALERT# assertion is only valid when PLTRST# is deasserted. The controller
should mask the state of this signal when PLTRST# is asserted. Since the controller
may be powered even when the PCH and the rest of the platform are not, the signal
may glitch as power is being asserted; thus, the controller should wait until PLTRST#
has deasserted before monitoring the signal.
5.21.2.6.1 Special Conditions
The external controller should have a graceful means of handling the following:
1. TEMP_ALERT# asserts, and the controller reads PCH, but all temperature values
are within limits.
In this case, the controller should assume that by the time the controller could read
the data, it had changed and moved back within the limits.
2. External controller writes new values to temperature limits, but TEMP_ALERT# is
still asserted after several hundred msecs. When read, the values are back within
limits.
In this case, the controller should treat this as case where the temperature
changed and caused TEMP_ALERT# assertion, and then changed again to be back
within limits.
3. There is the case where the external controller writes an update to the limit
register, while the PCH is collecting the thermal information and updating the
thermal registers. The limit change will only take affect when the write completes
and the Intel
process of collecting data and doing the compares, then it will continue to use the
old limits during this round of compares, and then use the new limits in the next
compare window.
4. Each SMBus write to change the limits is an atomic operation, but is distinct in
itself. Therefore the external controller could write PCH limit, and then write DIMM
limit. In the middle of those 2 writes, the thermal collecting procedure could be
called by the Intel
new PCH limits but the old DIMM limits.
Note: The limit writes are done when the SMBus write is complete; therefore, the limits are
updated atomically with respect to the thermal updates and compares. There is never a
case where the compares and the thermal update are interrupted in the middle by the
write of new limits. The thermal updates and compares are done as one non-
interruptible routine, and then the limit writes would change the limit value outside of
that routine.
234
®
ME can process this change. If the Intel
®
ME, so that the comparisons for the limits are done with the
Functional Description
®
ME is already in the
Datasheet