| Message ID | 1464211607-8843-2-git-send-email-moritz.fischer@ettus.com |
|---|---|
| State | Superseded |
| Delegated to: | Brian Norris |
| Headers | show |
Hi Moritz, On Wed, 25 May 2016 14:26:46 -0700 Moritz Fischer <moritz.fischer@ettus.com> wrote: > This commit adds documentation describing the bindings for > exposing mtd flash otp regions as nvmem providers via devicetree. > > Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> > --- > .../devicetree/bindings/mtd/otp-nvmem.txt | 62 ++++++++++++++++++++++ > 1 file changed, 62 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/otp-nvmem.txt > > diff --git a/Documentation/devicetree/bindings/mtd/otp-nvmem.txt b/Documentation/devicetree/bindings/mtd/otp-nvmem.txt > new file mode 100644 > index 0000000..a83a7da > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/otp-nvmem.txt > @@ -0,0 +1,62 @@ > +Representing OTP regions in devicetree > + > +OTP regions can be represented by sub-nodes of an mtd device. > + > +The partition table should be a subnode of the mtd node and should be names > +'otp-partitions'. This node should have the following property: > + > +- compatible: (required) must be 'fixed-partitions' > + > +OTP regions are then defined in subnodes of the partitions node. > + > +Required properties for OTP regions: > +- reg: The region's offset and size within the mtd device > + > +Optional properties: > +- label: The label / name for this region. If ommited, the label is taken > + from the node name (excluding the unit address). > + > +Example: > + > +flash@0 { > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "uboot-spl"; > + reg = <0x0 0xe0000>; > + }; > + partition@1 { > + label = "uboot-env"; > + reg = <0xe0000 0x20000>; > + }; > + partition@2 { > + label = "uboot"; > + reg = <0x100000 0x100000>; > + }; > + }; > + > + otp-partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + region@0 { > + label = "factory-data"; > + reg = <0x0 0x40>; > + > + #address-cells = <0x1>; > + #size-cells = <0x1>; > + > + product: nvmem@0 { > + reg = <0x0 0x2>; > + }; > + > + revision: nvmem@3 { > + reg = <0x3 0x2>; > + }; > + }; > + }; > +} I think the MTD partition -> nvmem connection could benefit to non-OTP partitions too. So, how about defining the nvmem regions under the partition nodes, like that: flash@0 { partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; partition@0 { label = "uboot-spl"; reg = <0x0 0xe0000>; }; /* ... */ partition@X{ label = "factory-data-part"; reg = <0x200000 0x100000>; #address-cells = <1>; #size-cells = <1>; product: nvmem@0 { reg = <0x0 0x2>; }; revision: nvmem@3 { reg = <0x3 0x2>; }; }; }; otp-partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; partition@X{ label = "factory-data-part"; reg = <0x0 0x40>; #address-cells = <1>; #size-cells = <1>; product: nvmem@0 { reg = <0x0 0x2>; }; revision: nvmem@3 { reg = <0x3 0x2>; }; }; }; }; I know this requires changing the implementation to select the appropriate nvmem wrapper to use depending on whether we're interfacing with an OTP area or a regular one, but that should be doable. Regards, Boris
Hi Boris, On Thu, May 26, 2016 at 1:04 AM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > I think the MTD partition -> nvmem connection could benefit to non-OTP > partitions too. Yeah, I thought about that, too. Would you use the _read, and _write callbacks in that case? > So, how about defining the nvmem regions under the partition nodes, > like that: > > flash@0 { > partitions { > compatible = "fixed-partitions"; > #address-cells = <1>; > #size-cells = <1>; > > partition@0 { > label = "uboot-spl"; > reg = <0x0 0xe0000>; > }; > > /* ... */ > > partition@X{ > label = "factory-data-part"; > reg = <0x200000 0x100000>; > #address-cells = <1>; > #size-cells = <1>; > > product: nvmem@0 { > reg = <0x0 0x2>; > }; > > revision: nvmem@3 { > reg = <0x3 0x2>; > }; > }; > }; > > otp-partitions { > compatible = "fixed-partitions"; > #address-cells = <1>; > #size-cells = <1>; > > partition@X{ > label = "factory-data-part"; > reg = <0x0 0x40>; > #address-cells = <1>; > #size-cells = <1>; > > product: nvmem@0 { > reg = <0x0 0x2>; > }; > > revision: nvmem@3 { > reg = <0x3 0x2>; > }; > }; > }; > }; > > I know this requires changing the implementation to select the > appropriate nvmem wrapper to use depending on whether we're interfacing > with an OTP area or a regular one, but that should be doable. The implementation still needs work anyways, so I might as well add this to my list ... Would you do the nvmem mapping always, or conditionalize on a flag in the dt node like 'nvmem-export'? Thanks for the feedback, Moritz
Hi Moritz, On Thu, 26 May 2016 10:28:48 -0700 Moritz Fischer <moritz.fischer@ettus.com> wrote: > Hi Boris, > > On Thu, May 26, 2016 at 1:04 AM, Boris Brezillon > <boris.brezillon@free-electrons.com> wrote: > > > I think the MTD partition -> nvmem connection could benefit to non-OTP > > partitions too. > > Yeah, I thought about that, too. Would you use the _read, and _write > callbacks in that case? Yep, this means you'll need a flag to decide what kind of partition is exposed (OTP or normal), and then adjust the partition ->_read()/->_write() implementations. Actually, I'm not sure what will happen if you really expose OTP partitions, since these ones shouldn't implement norma ->_read()/_write(), or they should wrap those calls around their master ->_read/write_prot_xx(). I must admit I haven't looked at patch 2 yet, so maybe that's what you're doing. > > > So, how about defining the nvmem regions under the partition nodes, > > like that: > > > > flash@0 { > > partitions { > > compatible = "fixed-partitions"; > > #address-cells = <1>; > > #size-cells = <1>; > > > > partition@0 { > > label = "uboot-spl"; > > reg = <0x0 0xe0000>; > > }; > > > > /* ... */ > > > > partition@X{ > > label = "factory-data-part"; > > reg = <0x200000 0x100000>; > > #address-cells = <1>; > > #size-cells = <1>; > > > > product: nvmem@0 { > > reg = <0x0 0x2>; > > }; > > > > revision: nvmem@3 { > > reg = <0x3 0x2>; > > }; > > }; > > }; > > > > otp-partitions { > > compatible = "fixed-partitions"; > > #address-cells = <1>; > > #size-cells = <1>; > > > > partition@X{ > > label = "factory-data-part"; > > reg = <0x0 0x40>; > > #address-cells = <1>; > > #size-cells = <1>; > > > > product: nvmem@0 { > > reg = <0x0 0x2>; > > }; > > > > revision: nvmem@3 { > > reg = <0x3 0x2>; > > }; > > }; > > }; > > }; > > > > I know this requires changing the implementation to select the > > appropriate nvmem wrapper to use depending on whether we're interfacing > > with an OTP area or a regular one, but that should be doable. > > The implementation still needs work anyways, so I might as well add > this to my list ... > Would you do the nvmem mapping always, or conditionalize on a flag in > the dt node like 'nvmem-export'? Well, I asked myself the same question when I proposed the binding. You actually don't need the property since you can detect the presence of the #address/size-cells properties or the presence of child nodes, but maybe it's safer to make it dependent on an extra property (or use compatible = "mtd-to-nvmem"). I honestly don't know what's the best solution. Rob, any suggestion? Regards, Boris
diff --git a/Documentation/devicetree/bindings/mtd/otp-nvmem.txt b/Documentation/devicetree/bindings/mtd/otp-nvmem.txt new file mode 100644 index 0000000..a83a7da --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/otp-nvmem.txt @@ -0,0 +1,62 @@ +Representing OTP regions in devicetree + +OTP regions can be represented by sub-nodes of an mtd device. + +The partition table should be a subnode of the mtd node and should be names +'otp-partitions'. This node should have the following property: + +- compatible: (required) must be 'fixed-partitions' + +OTP regions are then defined in subnodes of the partitions node. + +Required properties for OTP regions: +- reg: The region's offset and size within the mtd device + +Optional properties: +- label: The label / name for this region. If ommited, the label is taken + from the node name (excluding the unit address). + +Example: + +flash@0 { + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "uboot-spl"; + reg = <0x0 0xe0000>; + }; + partition@1 { + label = "uboot-env"; + reg = <0xe0000 0x20000>; + }; + partition@2 { + label = "uboot"; + reg = <0x100000 0x100000>; + }; + }; + + otp-partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + region@0 { + label = "factory-data"; + reg = <0x0 0x40>; + + #address-cells = <0x1>; + #size-cells = <0x1>; + + product: nvmem@0 { + reg = <0x0 0x2>; + }; + + revision: nvmem@3 { + reg = <0x3 0x2>; + }; + }; + }; +}
This commit adds documentation describing the bindings for exposing mtd flash otp regions as nvmem providers via devicetree. Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> --- .../devicetree/bindings/mtd/otp-nvmem.txt | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/otp-nvmem.txt