Re: [Linux-nvdimm] [PATCH v2 03/20] nd_acpi, nfit-test: manufactured NFITs for interface development
On Fri, May 15, 2015 at 1:25 PM, Jeff Moyer wrote: > Dan Williams writes: > >> +config NFIT_TEST >> + tristate "NFIT TEST: Manufactured NFIT for interface testing" >> + depends on DMA_CMA >> + depends on LIBND=m >> + depends on ND_ACPI >> + depends on m >> + help >> + For development purposes register a manufactured >> + NFIT table to verify the resulting device model topology. >> + Note, this module arranges for ioremap_cache() to be >> + overridden locally to allow simulation of system-memory as an >> + io-memory-resource. >> + >> + Note, this test expects to be able to find at least 256MB of >> + CMA space (CONFIG_CMA_SIZE_MBYTES, cma=) or it will fail to >> + load. >> + >> + Say N unless you are doing development of the 'nd' subsystem. >> + > > Too many TLAs. I'm guessing CMA means Conventional Memory Area to you. > To me it means contiguous memory allocator. I means Contiguous Memory Allocator to me too. > Anyway, please define > acronyms when you use them, especially in help text. The help text also > doesn't really explain where it will find this memory. Would it be > possible to provide more direction there? I didn't think I needed to define CMA in the context of Kconfig, but I'll replace it with CONFIG_DMA_CMA to be more clear. > I don't have any useful commentary on the patch itself. I do wonder if > you shouldn't move this to the end, as it's hardly an integral part of > the patch set. True. The patches are currently in "development order" in that I created the test infrastructure before the rest of the implementation. But, I agree it makes sense to move this to the end for the next posting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 03/20] nd_acpi, nfit-test: manufactured NFITs for interface development
Dan Williams writes: > +config NFIT_TEST > + tristate "NFIT TEST: Manufactured NFIT for interface testing" > + depends on DMA_CMA > + depends on LIBND=m > + depends on ND_ACPI > + depends on m > + help > + For development purposes register a manufactured > + NFIT table to verify the resulting device model topology. > + Note, this module arranges for ioremap_cache() to be > + overridden locally to allow simulation of system-memory as an > + io-memory-resource. > + > + Note, this test expects to be able to find at least 256MB of > + CMA space (CONFIG_CMA_SIZE_MBYTES, cma=) or it will fail to > + load. > + > + Say N unless you are doing development of the 'nd' subsystem. > + Too many TLAs. I'm guessing CMA means Conventional Memory Area to you. To me it means contiguous memory allocator. Anyway, please define acronyms when you use them, especially in help text. The help text also doesn't really explain where it will find this memory. Would it be possible to provide more direction there? I don't have any useful commentary on the patch itself. I do wonder if you shouldn't move this to the end, as it's hardly an integral part of the patch set. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 03/20] nd_acpi, nfit-test: manufactured NFITs for interface development
On Fri, May 15, 2015 at 1:25 PM, Jeff Moyer jmo...@redhat.com wrote: Dan Williams dan.j.willi...@intel.com writes: +config NFIT_TEST + tristate NFIT TEST: Manufactured NFIT for interface testing + depends on DMA_CMA + depends on LIBND=m + depends on ND_ACPI + depends on m + help + For development purposes register a manufactured + NFIT table to verify the resulting device model topology. + Note, this module arranges for ioremap_cache() to be + overridden locally to allow simulation of system-memory as an + io-memory-resource. + + Note, this test expects to be able to find at least 256MB of + CMA space (CONFIG_CMA_SIZE_MBYTES, cma=) or it will fail to + load. + + Say N unless you are doing development of the 'nd' subsystem. + Too many TLAs. I'm guessing CMA means Conventional Memory Area to you. To me it means contiguous memory allocator. I means Contiguous Memory Allocator to me too. Anyway, please define acronyms when you use them, especially in help text. The help text also doesn't really explain where it will find this memory. Would it be possible to provide more direction there? I didn't think I needed to define CMA in the context of Kconfig, but I'll replace it with CONFIG_DMA_CMA to be more clear. I don't have any useful commentary on the patch itself. I do wonder if you shouldn't move this to the end, as it's hardly an integral part of the patch set. True. The patches are currently in development order in that I created the test infrastructure before the rest of the implementation. But, I agree it makes sense to move this to the end for the next posting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 03/20] nd_acpi, nfit-test: manufactured NFITs for interface development
Dan Williams dan.j.willi...@intel.com writes: +config NFIT_TEST + tristate NFIT TEST: Manufactured NFIT for interface testing + depends on DMA_CMA + depends on LIBND=m + depends on ND_ACPI + depends on m + help + For development purposes register a manufactured + NFIT table to verify the resulting device model topology. + Note, this module arranges for ioremap_cache() to be + overridden locally to allow simulation of system-memory as an + io-memory-resource. + + Note, this test expects to be able to find at least 256MB of + CMA space (CONFIG_CMA_SIZE_MBYTES, cma=) or it will fail to + load. + + Say N unless you are doing development of the 'nd' subsystem. + Too many TLAs. I'm guessing CMA means Conventional Memory Area to you. To me it means contiguous memory allocator. Anyway, please define acronyms when you use them, especially in help text. The help text also doesn't really explain where it will find this memory. Would it be possible to provide more direction there? I don't have any useful commentary on the patch itself. I do wonder if you shouldn't move this to the end, as it's hardly an integral part of the patch set. Cheers, Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/20] nd_acpi, nfit-test: manufactured NFITs for interface development
Manually create and register NFITs to describe 2 topologies. Topology1
is an advanced plausible configuration for BLK/PMEM aliased NVDIMMs.
Topology2 is an example configuration for current platforms that only
ship with a persistent address range.
Kernel provider "nfit_test.0" produces an NFIT with the following attributes:
(a) (b) DIMM BLK-REGION
+---++++
+--+ | pm0.0 | blk2.0 | pm1.0 | blk2.1 |0 region2
| imc0 +--+- - - region0- - - ++++
+--+---+ | pm0.0 | blk3.0 | pm1.0 | blk3.1 |1 region3
| +---+vv+
+--+---+ | |
| cpu0 | region1
+--+---+ | |
| +^^+
+--+---+ | blk4.0 | pm1.0 | blk4.0 |2 region4
| imc1 +--+|++
+--+ | blk5.0 | pm1.0 | blk5.0 |3 region5
++++
*) In this layout we have four dimms and two memory controllers in one
socket. Each unique interface ("block" or "pmem") to DPA space
is identified by a region device with a dynamically assigned id.
*) The first portion of dimm0 and dimm1 are interleaved as REGION0.
A single "pmem" namespace is created in the REGION0-"spa"-range
that spans dimm0 and dimm1 with a user-specified name of "pm0.0".
Some of that interleaved "spa" range is reclaimed as "bdw"
accessed space starting at offset (a) into each dimm. In that
reclaimed space we create two "bdw" "namespaces" from REGION2 and
REGION3 where "blk2.0" and "blk3.0" are just human readable names
that could be set to any user-desired name in the label.
*) In the last portion of dimm0 and dimm1 we have an interleaved
"spa" range, REGION1, that spans those two dimms as well as dimm2
and dimm3. Some of REGION1 allocated to a "pmem" namespace named
"pm1.0" the rest is reclaimed in 4 "bdw" namespaces (for each
dimm in the interleave set), "blk2.1", "blk3.1", "blk4.0", and
"blk5.0".
*) The portion of dimm2 and dimm3 that do not participate in the
REGION1 interleaved "spa" range (i.e. the DPA address below
offset (b) are also included in the "blk4.0" and "blk5.0"
namespaces. Note, that this example shows that "bdw" namespaces
don't need to be contiguous in DPA-space.
Kernel provider "nfit_test.1" produces an NFIT with the following attributes:
region2
+-+
|-|
|| pm2.0 ||
|-|
+-+
*) Describes a simple system-physical-address range with no backing
dimm or interleave description.
Cc:
Cc: Robert Moore
Cc: Rafael J. Wysocki
Signed-off-by: Dan Williams
---
drivers/block/nd/Kconfig | 19 +
drivers/block/nd/Makefile | 15 +
drivers/block/nd/acpi.c |3
drivers/block/nd/acpi_nfit.h | 11
drivers/block/nd/test/Makefile|5
drivers/block/nd/test/iomap.c | 151 +
drivers/block/nd/test/nfit.c | 1025 +
drivers/block/nd/test/nfit_test.h | 26 +
8 files changed, 1254 insertions(+), 1 deletion(-)
create mode 100644 drivers/block/nd/test/Makefile
create mode 100644 drivers/block/nd/test/iomap.c
create mode 100644 drivers/block/nd/test/nfit.c
create mode 100644 drivers/block/nd/test/nfit_test.h
diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
index 6d5d6b732f82..09f0135147ca 100644
--- a/drivers/block/nd/Kconfig
+++ b/drivers/block/nd/Kconfig
@@ -37,4 +37,23 @@ config ND_ACPI
addition to storage devices this also enables libnd craft
ACPI._DSM messages for platform/dimm configuration.
+config NFIT_TEST
+ tristate "NFIT TEST: Manufactured NFIT for interface testing"
+ depends on DMA_CMA
+ depends on LIBND=m
+ depends on ND_ACPI
+ depends on m
+ help
+ For development purposes register a manufactured
+ NFIT table to verify the resulting device model topology.
+ Note, this module arranges for ioremap_cache() to be
+ overridden locally to allow simulation of system-memory as an
+ io-memory-resource.
+
+ Note, this test expects to be able to find at least 256MB of
+ CMA space (CONFIG_CMA_SIZE_MBYTES, cma=) or it will fail to
+ load.
+
+ Say N unless you are doing development of the 'nd' subsystem.
+
endif
diff --git a/drivers/block/nd/Makefile b/drivers/block/nd/Makefile
index 944b5947c0cb..cf064db92589 100644
--- a/drivers/block/nd/Makefile
+++ b/drivers/block/nd/Makefile
@@ -1,5 +1,20 @@
+ifdef CONFIG_NFIT_TEST
+#
[PATCH v2 03/20] nd_acpi, nfit-test: manufactured NFITs for interface development
Manually create and register NFITs to describe 2 topologies. Topology1 is an advanced plausible configuration for BLK/PMEM aliased NVDIMMs. Topology2 is an example configuration for current platforms that only ship with a persistent address range. Kernel provider nfit_test.0 produces an NFIT with the following attributes: (a) (b) DIMM BLK-REGION +---++++ +--+ | pm0.0 | blk2.0 | pm1.0 | blk2.1 |0 region2 | imc0 +--+- - - region0- - - ++++ +--+---+ | pm0.0 | blk3.0 | pm1.0 | blk3.1 |1 region3 | +---+vv+ +--+---+ | | | cpu0 | region1 +--+---+ | | | +^^+ +--+---+ | blk4.0 | pm1.0 | blk4.0 |2 region4 | imc1 +--+|++ +--+ | blk5.0 | pm1.0 | blk5.0 |3 region5 ++++ *) In this layout we have four dimms and two memory controllers in one socket. Each unique interface (block or pmem) to DPA space is identified by a region device with a dynamically assigned id. *) The first portion of dimm0 and dimm1 are interleaved as REGION0. A single pmem namespace is created in the REGION0-spa-range that spans dimm0 and dimm1 with a user-specified name of pm0.0. Some of that interleaved spa range is reclaimed as bdw accessed space starting at offset (a) into each dimm. In that reclaimed space we create two bdw namespaces from REGION2 and REGION3 where blk2.0 and blk3.0 are just human readable names that could be set to any user-desired name in the label. *) In the last portion of dimm0 and dimm1 we have an interleaved spa range, REGION1, that spans those two dimms as well as dimm2 and dimm3. Some of REGION1 allocated to a pmem namespace named pm1.0 the rest is reclaimed in 4 bdw namespaces (for each dimm in the interleave set), blk2.1, blk3.1, blk4.0, and blk5.0. *) The portion of dimm2 and dimm3 that do not participate in the REGION1 interleaved spa range (i.e. the DPA address below offset (b) are also included in the blk4.0 and blk5.0 namespaces. Note, that this example shows that bdw namespaces don't need to be contiguous in DPA-space. Kernel provider nfit_test.1 produces an NFIT with the following attributes: region2 +-+ |-| || pm2.0 || |-| +-+ *) Describes a simple system-physical-address range with no backing dimm or interleave description. Cc: linux-a...@vger.kernel.org Cc: Robert Moore robert.mo...@intel.com Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com Signed-off-by: Dan Williams dan.j.willi...@intel.com --- drivers/block/nd/Kconfig | 19 + drivers/block/nd/Makefile | 15 + drivers/block/nd/acpi.c |3 drivers/block/nd/acpi_nfit.h | 11 drivers/block/nd/test/Makefile|5 drivers/block/nd/test/iomap.c | 151 + drivers/block/nd/test/nfit.c | 1025 + drivers/block/nd/test/nfit_test.h | 26 + 8 files changed, 1254 insertions(+), 1 deletion(-) create mode 100644 drivers/block/nd/test/Makefile create mode 100644 drivers/block/nd/test/iomap.c create mode 100644 drivers/block/nd/test/nfit.c create mode 100644 drivers/block/nd/test/nfit_test.h diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig index 6d5d6b732f82..09f0135147ca 100644 --- a/drivers/block/nd/Kconfig +++ b/drivers/block/nd/Kconfig @@ -37,4 +37,23 @@ config ND_ACPI addition to storage devices this also enables libnd craft ACPI._DSM messages for platform/dimm configuration. +config NFIT_TEST + tristate NFIT TEST: Manufactured NFIT for interface testing + depends on DMA_CMA + depends on LIBND=m + depends on ND_ACPI + depends on m + help + For development purposes register a manufactured + NFIT table to verify the resulting device model topology. + Note, this module arranges for ioremap_cache() to be + overridden locally to allow simulation of system-memory as an + io-memory-resource. + + Note, this test expects to be able to find at least 256MB of + CMA space (CONFIG_CMA_SIZE_MBYTES, cma=) or it will fail to + load. + + Say N unless you are doing development of the 'nd' subsystem. + endif diff --git a/drivers/block/nd/Makefile b/drivers/block/nd/Makefile index 944b5947c0cb..cf064db92589 100644 --- a/drivers/block/nd/Makefile +++
