From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 829CF2264A21F for ; Wed, 4 Apr 2018 07:04:03 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id b5-v6so17476303itj.1 for ; Wed, 04 Apr 2018 07:04:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180404220750.0436bbe1@gmail.com> References: <20180403142415.30083-1-oohall@gmail.com> <20180403142415.30083-3-oohall@gmail.com> <20180404220750.0436bbe1@gmail.com> From: Oliver Date: Thu, 5 Apr 2018 00:04:01 +1000 Message-ID: Subject: Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Balbir Singh Cc: Device Tree , linuxppc-dev , linux-nvdimm List-ID: On Wed, Apr 4, 2018 at 10:07 PM, Balbir Singh wrote: > On Tue, 3 Apr 2018 10:37:51 -0700 > Dan Williams wrote: > >> On Tue, Apr 3, 2018 at 7:24 AM, Oliver O'Halloran wrote: >> > Add device-tree binding documentation for the nvdimm region driver. >> > >> > Cc: devicetree@vger.kernel.org >> > Signed-off-by: Oliver O'Halloran >> > --- >> > v2: Changed name from nvdimm-region to pmem-region. >> > Cleaned up the example binding and fixed the overlapping regions. >> > Added support for multiple regions in a single reg. >> > --- >> > .../devicetree/bindings/pmem/pmem-region.txt | 80 ++++++++++++++++++++++ >> > MAINTAINERS | 1 + >> > 2 files changed, 81 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/pmem/pmem-region.txt >> >> Device-tree folks, does this look, ok? >> >> Oliver, is there any concept of a management interface to the >> device(s) backing these regions? libnvdimm calls these "nmem" devices >> and support operations like health status and namespace label >> management. It's something I'm planning on implementing as soon as someone gives me some hardware that isn't hacked up lab crap. I'm posting this version with just regions since people have been asking for something in upstream even if it's not fully featured. Grumbling aside, the plan is to have separate drivers for the DIMM type. Discovering DIMM devices happens via the normal discovery mechanisms (e.g. an NVDIMM supporting the JEDEC interface is an I2C device) and when binding to a specific DIMM device it registers a DIMM descriptor structure and a ndctl implementation for that DIMM type with of_pmem. When of_pmem binds to a region it can plug everything into the region specific bus. There's a few details to work out, but I think it's a reasonable approach. > We would need a way to have nmem and pmem-regions find each other. Since we > don't have the ACPI abstractions, the nmem region would need to add the > ability for a driver to have a phandle to the interleaving and nmem properties. > > I guess that would be a separate driver, that would manage the nmem devices > and there would be a way to relate the pmem and nmems. Oliver? Yes, that's the plan. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm