11:45 a.m.
Hi:
I am trying to figure out what changes might be needed in the NVDIMM driver set for
adding a new Region format interface code.
After some researching, I found the following constants were defined in the NFIT header
file but never really got referenced in the driver code. (It's used in the test code)
64 #define NFIT_FIC_BYTE cpu_to_le16(0x101) /* byte-addressable energy backed */
65 #define NFIT_FIC_BLK cpu_to_le16(0x201) /* block-addressable non-energy backed */
66 #define NFIT_FIC_BYTEN cpu_to_le16(0x301) /* byte-addressable non-energy backed */
Am I missing anything?
ThanskCheng-mean
5:53 p.m.
New subject: How is a Region format interface codec used in NFIT/PEME/BLK/BTT driver?
-----Original Message-----
From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On
Behalf Of Soccer Liu
Sent: Thursday, February 09, 2017 1:45 PM
Subject: How is a Region format interface codec used in
NFIT/PEME/BLK/BTT driver?
I am trying to figure out what changes might be needed in the
NVDIMM driver set for adding a new Region format interface code.
After some researching, I found the following constants were defined
in the NFIT header file but never really got referenced in the driver
code. (It's used in the test code)
64 #define NFIT_FIC_BYTE cpu_to_le16(0x101) /* byte-addressable
energy backed */
65 #define NFIT_FIC_BLK cpu_to_le16(0x201) /* block-addressable non-
energy backed */
66 #define NFIT_FIC_BYTEN cpu_to_le16(0x301) /* byte-addressable
non-energy backed */
JEDEC is the underlying assignment authority for these values.
The ACPI specification defines how the system fills in the 2-byte
little-endian Region Format Interface Code field in the NFIT NVDIMM
Control Region Structure:
"This field shall be set to the value of the NVDIMM SPD
Function Interface descriptor for the function interface
represented by the NVDIMM Control Region structure, with:
a) byte 0 bits 7:5 set to 000b;
b) byte 0 bits 4:0 set to the Function Interface field (i.e.,
Function Interface descriptor bits 4:0);
c) byte 1 bits 7:0 set to 000b; and
d) byte 1 bits 4:0 set to the Function Class field (i.e.,
Function Interface descriptor bits 9:5)."
The SPD EEPROM contents are defined by JESD21C Page 4.1.2.L
(Serial Presence Detect (SPD) for DDR4 SDRAM Modules):
For Function Class 0x0, Function Interface is:
* 0x00 = proprietary
* all others reserved
For Function Class 0x01, Function Interface is:
* 0x00 = proprietary
* 0x01 = JESD245 BAEBI (for NVDIMM-Ns)
* all others reserved
For Function Class 0x02, Function Interface is:
* 0x00 = proprietary
* 0x01 = some yet-to-be defined
block addressable interface
* all others reserved
For Function Class 0x03, Function Interface is:
* 0x00 = proprietary
* 0x01 = some yet-to-be defined
byte addressable non-energy backed interface
* all others reserved
All other Function Class values are reserved.
---
Robert Elliott, HPE Persistent Memory
6:02 p.m.
New subject: How is a Region format interface codec used in NFIT/PEME/BLK/BTT driver?
On Thu, Feb 9, 2017 at 11:45 AM, Soccer Liu <soccer_liu(a)yahoo.com> wrote:
Hi:
I am trying to figure out what changes might be needed in the NVDIMM driver set for
adding a new Region format interface code.
After some researching, I found the following constants were defined in the NFIT header
file but never really got referenced in the driver code. (It's used in the test code)
64 #define NFIT_FIC_BYTE cpu_to_le16(0x101) /* byte-addressable energy backed */
65 #define NFIT_FIC_BLK cpu_to_le16(0x201) /* block-addressable non-energy backed */
66 #define NFIT_FIC_BYTEN cpu_to_le16(0x301) /* byte-addressable non-energy backed */
Am I missing anything?
No, you're not missing anything. Linux simply doesn't care about the
format interface code and instead relies on the "Address Range Type
GUID" from the "System Physical Address (SPA) Range Structure" in the
NFIT. In other words Linux does not differentiate support for 0x101
and 0x301 because in both cases we end up with a "Byte Addressable
Persistent Memory (PM) Region" in the NFIT. We also don't care about
NFIT_FIC_BLK because that code is redundant with the definition of
block windows in the NFIT.
6:28 a.m.
New subject: How is a Region format interface codec used in NFIT/PEME/BLK/BTT driver?
On 2/9/2017 9:02 PM, Dan Williams wrote:
On Thu, Feb 9, 2017 at 11:45 AM, Soccer Liu
<soccer_liu(a)yahoo.com> wrote:
> Hi:
>
> I am trying to figure out what changes might be needed in the NVDIMM driver set for
adding a new Region format interface code.
> After some researching, I found the following constants were defined in the NFIT
header file but never really got referenced in the driver code. (It's used in the test
code)
> 64 #define NFIT_FIC_BYTE cpu_to_le16(0x101) /* byte-addressable energy backed */
> 65 #define NFIT_FIC_BLK cpu_to_le16(0x201) /* block-addressable non-energy backed
*/
> 66 #define NFIT_FIC_BYTEN cpu_to_le16(0x301) /* byte-addressable non-energy backed
*/
>
> Am I missing anything?
No, you're not missing anything. Linux simply doesn't care about the
format interface code and instead relies on the "Address Range Type
GUID" from the "System Physical Address (SPA) Range Structure" in the
NFIT. In other words Linux does not differentiate support for 0x101
and 0x301 because in both cases we end up with a "Byte Addressable
Persistent Memory (PM) Region" in the NFIT. We also don't care about
NFIT_FIC_BLK because that code is redundant with the definition of
block windows in the NFIT.
I suppose we could care about FIC in the future if there is a device
that doesn't quite fit the current driver, perhaps requiring something
special with initialization or management or error handling, but it
would depend on what the new device is.
The FIC is exposed through /sys so a management tool might care.
-- ljk
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm(a)lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
1529
days inactive
1530
days old
3 comments
4 participants
participants (4)
-
Dan Williams -
Elliott, Robert (Persistent Memory) -
Linda Knippers -
Soccer Liu