On 3/29/2017 6:26 PM, Elliott, Robert (Persistent Memory) wrote:
-----Original Message-----
From: Linux-nvdimm [mailto:[email protected]] On Behalf
Of [email protected]
Sent: Wednesday, March 29, 2017 4:41 PM
To: [email protected]; [email protected]
Subject: RE: [PATCH v2] libndctl: add support for the MSFT family of DSM
functions
-----Original Message-----
From: Dan Williams [mailto:[email protected]]
From: Lijun Pan <[email protected]>
This patch retrieves the health data from NVDIMM-N via
the MSFT _DSM function[1], following JESD245A[2] standards.
Now 'ndctl list --dimms --health --idle' could work
on MSFT type NVDIMM-N, but limited to health_state,
temperature_celsius, and life_used_percentage.
...
Output is something like,
"health":{
"health_state":"ok",
"temperature_celsius":193.750000,
"life_used_percentage":1
}
If the BIOS returns a value say 45.75, how can it be represented in (__u16)
instead of using a 'double' type? I think the ((__u16) temp & 0x0FFC) already
represents a temperature in 1/16 Celsius granularity. No need to multiple it
by
16 again.
Below I quote the section 7.8 of JESD245.pdf
Bit 3 has a resolution of 1/2 Celsius,
Bit 2 has a resolution of 1/4 Celsius,
Bit 1 has 1/8 Celsius, but is reserved, so I assume it be zero,
Bit 0 has 1/16 Celsius, but is reserved, so I assume it be zero.
((__u16) temp & 0x0FFC) will only get the bit11 - bit 0. This presents the
1/16 Celsius resolution, kind of left shifted 4 bits.
So we don't need to do
'return CMD_MSFT_SMART(cmd)->temp * 16;' again.
==== = quotation starts =====
"
Temperature measurement shall have a minimum resolution of 0.25 Celsius.
Registers containing measured temperature value shall be 16-bits and report
temperature as a 10-bit value based on the following definition.
Table 3: Temperature value bit definition
Bit15 Bit14 Bit13 Bit12 Bit11 Bit10 Bit9 Bit8
Reserved Reserved Reserved Reserved 128 64
32 16
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0
8 4 2 1 0.5 0.25 Reserved Reserved
Examples:
A temperature value of 10.5 Celsius is represented as 0000000010101000b.
A temperature value of 64.75 Celsius is represented as 0000010000001100b.
"
==== quotation ends ========
Lijun
...so users know what to expect. With that change and addressing
Linda's comment about the temperature multiplier I think we're good to
go.
You should plan to support temperatures compliant with JESD21C
Page 4.1.6-2 (TSE2004 SPD EEPROM with Temperature Sensor), which include:
* a sign bit to support negative temperatures (in bit 12)
* 0.125 and 0.0625 degrees C precision (i.e., bits 1 and 0 are defined)
Industrial Grade and Automotive Grade components operate down to
-40 degrees C, so negative values will be required.
The importance of extra precision is a but fuzzy given that sensor
accuracy varies from +/- 1 to +/- 3 degrees C (depending on the
temperature range). A software API should pass along all the
available information, though.
Interesting, but until someone changes their DSM spec, none of that matters.
This patch is supposed to be implementing the MSFT DSM spec.
-- ljk
---
Robert Elliott, HPE Persistent Memory
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
