| Message ID | 20200224021029.142701-3-adelva@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3,1/3] libnvdimm/of_pmem: factor out region registration | expand |
On Sun, Feb 23, 2020 at 06:10:29PM -0800, Alistair Delva wrote: > From: Kenny Root <kroot@google.com> > > Add documentation and example for memory-region in pmem. > > Signed-off-by: Kenny Root <kroot@google.com> > Signed-off-by: Alistair Delva <adelva@google.com> > Cc: "Oliver O'Halloran" <oohall@gmail.com> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: Vishal Verma <vishal.l.verma@intel.com> > Cc: Dave Jiang <dave.jiang@intel.com> > Cc: Ira Weiny <ira.weiny@intel.com> > Cc: devicetree@vger.kernel.org > Cc: linux-nvdimm@lists.01.org > Cc: kernel-team@android.com > --- > [v3: adelva: remove duplicate "From:"] > .../devicetree/bindings/pmem/pmem-region.txt | 29 +++++++++++++++++++ > 1 file changed, 29 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pmem/pmem-region.txt b/Documentation/devicetree/bindings/pmem/pmem-region.txt > index 5cfa4f016a00..0ec87bd034e0 100644 > --- a/Documentation/devicetree/bindings/pmem/pmem-region.txt > +++ b/Documentation/devicetree/bindings/pmem/pmem-region.txt > @@ -29,6 +29,18 @@ Required properties: > in a separate device node. Having multiple address ranges in a > node implies no special relationship between the two ranges. > > + This property may be replaced or supplemented with a > + memory-region property. Only one of reg or memory-region > + properties is required. > + > + - memory-region: > + Reference to the reserved memory node. The reserved memory > + node should be defined as per the bindings in > + reserved-memory.txt Though we've never enforced it, but /reserved-memory should be within the bounds of /memory node(s). Is that the intent here? If so, how does that work? Wouldn't all the memory be persistent then? Or some other system processor is preserving the contents? > + > + This property may be replaced or supplemented with a reg > + property. Only one of reg or memory-region is required. > + > Optional properties: > - Any relevant NUMA assocativity properties for the target platform. > > @@ -63,3 +75,20 @@ Examples: > volatile; > }; > > + > + /* > + * This example uses a reserved-memory entry instead of > + * specifying the memory region directly in the node. > + */ > + > + reserved-memory { > + pmem_1: pmem@5000 { > + no-map; Just add 'compatible = "pmem-region";' here and be done with it. Why add a layer of indirection? > + reg = <0x00005000 0x00001000>; > + }; > + }; > + > + pmem@1 { No 'reg', so shouldn't have a unit-address here. > + compatible = "pmem-region"; > + memory-region = <&pmem_1>; > + }; > -- > 2.25.0.265.gbab2e86ba0-goog >
Hi Rob, Thanks for reviewing. On Thu, Feb 27, 2020 at 3:22 PM Rob Herring <robh@kernel.org> wrote: >> On Sun, Feb 23, 2020 at 06:10:29PM -0800, Alistair Delva wrote: > > From: Kenny Root <kroot@google.com> > > > > Add documentation and example for memory-region in pmem. > > > > Signed-off-by: Kenny Root <kroot@google.com> > > Signed-off-by: Alistair Delva <adelva@google.com> > > Cc: "Oliver O'Halloran" <oohall@gmail.com> > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: Dan Williams <dan.j.williams@intel.com> > > Cc: Vishal Verma <vishal.l.verma@intel.com> > > Cc: Dave Jiang <dave.jiang@intel.com> > > Cc: Ira Weiny <ira.weiny@intel.com> > > Cc: devicetree@vger.kernel.org > > Cc: linux-nvdimm@lists.01.org > > Cc: kernel-team@android.com > > --- > > [v3: adelva: remove duplicate "From:"] > > .../devicetree/bindings/pmem/pmem-region.txt | 29 +++++++++++++++++++ > > 1 file changed, 29 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/pmem/pmem-region.txt b/Documentation/devicetree/bindings/pmem/pmem-region.txt > > index 5cfa4f016a00..0ec87bd034e0 100644 > > --- a/Documentation/devicetree/bindings/pmem/pmem-region.txt > > +++ b/Documentation/devicetree/bindings/pmem/pmem-region.txt > > @@ -29,6 +29,18 @@ Required properties: > > in a separate device node. Having multiple address ranges in a > > node implies no special relationship between the two ranges. > > > > + This property may be replaced or supplemented with a > > + memory-region property. Only one of reg or memory-region > > + properties is required. > > + > > + - memory-region: > > + Reference to the reserved memory node. The reserved memory > > + node should be defined as per the bindings in > > + reserved-memory.txt > > Though we've never enforced it, but /reserved-memory should be within > the bounds of /memory node(s). Is that the intent here? If so, how does > that work? Wouldn't all the memory be persistent then? Or some other > system processor is preserving the contents? On the systems we're working with, the RAM remains refreshed across reboots, but the contents of RAM could be changed by something outside of Linux (i.e. the bootloader). By reserving this region in DT for pmem we are saying "this is persistent like the rest of RAM on this device, but it is also not going to be touched by anything besides this Linux driver". > > + > > + This property may be replaced or supplemented with a reg > > + property. Only one of reg or memory-region is required. > > + > > Optional properties: > > - Any relevant NUMA assocativity properties for the target platform. > > > > @@ -63,3 +75,20 @@ Examples: > > volatile; > > }; > > > > + > > + /* > > + * This example uses a reserved-memory entry instead of > > + * specifying the memory region directly in the node. > > + */ > > + > > + reserved-memory { > > + pmem_1: pmem@5000 { > > + no-map; > > Just add 'compatible = "pmem-region";' here and be done with it. Why add > a layer of indirection? Sure, I'll do that.. > > + reg = <0x00005000 0x00001000>; > > + }; > > + }; > > + > > + pmem@1 { > > No 'reg', so shouldn't have a unit-address here. ..then I guess I can just delete this. v4 incoming. > > + compatible = "pmem-region"; > > + memory-region = <&pmem_1>; > > + }; > > -- > > 2.25.0.265.gbab2e86ba0-goog > > > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >
diff --git a/Documentation/devicetree/bindings/pmem/pmem-region.txt b/Documentation/devicetree/bindings/pmem/pmem-region.txt index 5cfa4f016a00..0ec87bd034e0 100644 --- a/Documentation/devicetree/bindings/pmem/pmem-region.txt +++ b/Documentation/devicetree/bindings/pmem/pmem-region.txt @@ -29,6 +29,18 @@ Required properties: in a separate device node. Having multiple address ranges in a node implies no special relationship between the two ranges. + This property may be replaced or supplemented with a + memory-region property. Only one of reg or memory-region + properties is required. + + - memory-region: + Reference to the reserved memory node. The reserved memory + node should be defined as per the bindings in + reserved-memory.txt + + This property may be replaced or supplemented with a reg + property. Only one of reg or memory-region is required. + Optional properties: - Any relevant NUMA assocativity properties for the target platform. @@ -63,3 +75,20 @@ Examples: volatile; }; + + /* + * This example uses a reserved-memory entry instead of + * specifying the memory region directly in the node. + */ + + reserved-memory { + pmem_1: pmem@5000 { + no-map; + reg = <0x00005000 0x00001000>; + }; + }; + + pmem@1 { + compatible = "pmem-region"; + memory-region = <&pmem_1>; + };