On Tue, 2015-04-28 at 10:47 -0600, Toshi Kani wrote: > On Wed, 2015-04-22 at 13:00 -0700, Dan Williams wrote: > > On Wed, Apr 22, 2015 at 12:38 PM, Toshi Kani <toshi.k...@hp.com> wrote: > > > On Wed, 2015-04-22 at 12:28 -0700, Dan Williams wrote: > > >> On Wed, Apr 22, 2015 at 11:23 AM, Toshi Kani <toshi.k...@hp.com> wrote: > > >> > On Wed, 2015-04-22 at 11:20 -0700, Dan Williams wrote: > > >> >> On Wed, Apr 22, 2015 at 11:00 AM, Linda Knippers > > >> >> <linda.knipp...@hp.com> wrote: > > >> >> Wait, point of clarification, DCRs (dimm-control-regions) have RFICs, > > >> >> not MEMDEVs (memory-device-to-spa-mapping). Toshi's original report > > >> >> was that an NFIT with a SPA+MEMDEV was failing to enable a PMEM > > >> >> device. That specific problem can be fixed by either deleting the > > >> >> MEMDEV, or adding a DCR. > > >> > > > >> > By a DCR, do you mean a DCR structure or SPA with Control Region GUID? > > >> > > >> Hmm, I meant a DCR as defined below. I agree you would not need a > > >> "SPA-DCR". > > >> > > >> > Adding a DCR structure does not solve this issue since it requires SPA > > >> > with Control Region GUID, which battery-backed DIMMs do not have. > > >> > > >> I would not go that far, half of a DCR entry is relevant for any > > >> NVDIMM, and half is only relevant if a DIMM offers BLK access: > > >> > > >> struct acpi_nfit_dcr { > > >> u16 type; > > >> u16 length; > > >> u16 dcr_index; > > >> u16 vendor_id; > > >> u16 device_id; > > >> u16 revision_id; > > >> u16 sub_vendor_id; > > >> u16 sub_device_id; > > >> u16 sub_revision_id; > > >> u8 reserved[6]; > > >> u32 serial_number; > > >> u16 fic; > > >> <<<<< BLK relevant fields start here <<<<< > > >> u16 num_bcw; > > >> u64 bcw_size; > > >> u64 cmd_offset; > > >> u64 cmd_size; > > >> u64 status_offset; > > >> u64 status_size; > > >> u16 flags; > > >> u8 reserved2[6]; > > >> }; > > > > > > Yes, we do have a DCR entry. But we do not have a SPA-DCR. > > > > Got it. will fix. > > Attached is an example implementation of the NFIT table with 2 > battery-backed NVDIMM cards, which I have used for testing. I hope this > provides a good example of an NFIT table with SPA(PMEM), MEMDEV and DCR > entries, which allows optional _DSMs for battery-backed NVDIMMs as > necessary. > > HP is also defining _DSM method for battery-backed NVDIMMs, and will > share the spec when it is ready.
Sorry, using ".txt" extension to a Linux text file caused my mailer to perform some unnecessary conversion... Attached is the same file without ".txt" this time. -Toshi
hp_nfit
Description: Binary data