Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031045AbbD1U7r (ORCPT ); Tue, 28 Apr 2015 16:59:47 -0400 Received: from mail-wg0-f50.google.com ([74.125.82.50]:33234 "EHLO mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030857AbbD1U7o (ORCPT ); Tue, 28 Apr 2015 16:59:44 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150428181203.35812.60474.stgit@dwillia2-desk3.amr.corp.intel.com> Date: Tue, 28 Apr 2015 13:59:43 -0700 Message-ID: Subject: Re: [PATCH v2 00/20] libnd: non-volatile memory device support From: Dan Williams To: Andy Lutomirski Cc: linux-nvdimm , Boaz Harrosh , Neil Brown , Dave Chinner , "H. Peter Anvin" , Ingo Molnar , "Rafael J. Wysocki" , Robert Moore , Christoph Hellwig , Linux ACPI , Jeff Moyer , Nicholas Moulin , Matthew Wilcox , Ross Zwisler , Vishal Verma , Jens Axboe , Borislav Petkov , Thomas Gleixner , Greg KH , "linux-kernel@vger.kernel.org" , Andrew Morton , Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2523 Lines: 50 On Tue, Apr 28, 2015 at 1:52 PM, Andy Lutomirski wrote: > On Tue, Apr 28, 2015 at 11:24 AM, Dan Williams wrote: >> Changes since v1 [1]: Incorporates feedback received prior to April 24. >> >> 1/ Ingo said [2]: >> >> "So why on earth is this whole concept and the naming itself >> ('drivers/block/nd/' stands for 'NFIT Defined', apparently) >> revolving around a specific 'firmware' mindset and revolving >> around specific, weirdly named, overly complicated looking >> firmware interfaces that come with their own new weird >> glossary??" >> >> Indeed, we of course consulted the NFIT specification to determine >> the shape of the sub-system, but then let its terms and data >> structures permeate too deep into the implementation. That is fixed >> now with all NFIT specifics factored out into acpi.c. The NFIT is no >> longer required reading to review libnd. Only three concepts are >> needed: >> >> i/ PMEM - contiguous memory range where cpu stores are >> persistent once they are flushed through the memory >> controller. >> >> ii/ BLK - mmio apertures (sliding windows) that can be >> programmed to access an aperture's-worth of persistent >> media at a time. >> >> iii/ DPA - "dimm-physical-address", address space local to a >> dimm. A dimm may provide both PMEM-mode and BLK-mode >> access to a range of DPA. libnd manages allocation of DPA >> to either PMEM or BLK-namespaces to resolve this aliasing. > > Mostly for my understanding: is there a name for "address relative to > the address lines on the DIMM"? That is, a DIMM that exposes 8 GB of > apparent physical memory, possibly interleaved, broken up, or weirdly > remapped by the memory controller, would still have addresses between > 0 and 8 GB. Some of those might be PMEM windows, some might be MMIO, > some might be BLK apertures, etc. > > IIUC "DPA" refers to actual addressable storage, not this type of address? No, DPA is exactly as you describe above. You can't directly access it except through a PMEM mapping (possibly interleaved with DPA from other DIMMs) or a BLK aperture (mmio window into DPA). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/