Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1407222 > unrolled thread
| Started by | Moritz Fischer <moritz.fischer@ettus.com> |
|---|---|
| First post | 2016-05-25 23:30 +0200 |
| Last post | 2016-05-27 15:30 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem Moritz Fischer <moritz.fischer@ettus.com> - 2016-05-25 23:30 +0200
Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-26 10:10 +0200
Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem Moritz Fischer <moritz.fischer@ettus.com> - 2016-05-26 19:30 +0200
Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-27 15:30 +0200
| From | Moritz Fischer <moritz.fischer@ettus.com> |
|---|---|
| Date | 2016-05-25 23:30 +0200 |
| Subject | [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem |
| Message-ID | <rCOxk-5WN-27@gated-at.bofh.it> |
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>;
+ };
+ };
+ };
+}
--
2.5.5
[toc] | [next] | [standalone]
| From | Boris Brezillon <boris.brezillon@free-electrons.com> |
|---|---|
| Date | 2016-05-26 10:10 +0200 |
| Subject | Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem |
| Message-ID | <rCYwG-3W0-5@gated-at.bofh.it> |
| In reply to | #1407222 |
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
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | Moritz Fischer <moritz.fischer@ettus.com> |
|---|---|
| Date | 2016-05-26 19:30 +0200 |
| Subject | Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem |
| Message-ID | <rD7gC-NT-7@gated-at.bofh.it> |
| In reply to | #1407437 |
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
[toc] | [prev] | [next] | [standalone]
| From | Boris Brezillon <boris.brezillon@free-electrons.com> |
|---|---|
| Date | 2016-05-27 15:30 +0200 |
| Subject | Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem |
| Message-ID | <rDpZU-3Y5-37@gated-at.bofh.it> |
| In reply to | #1407645 |
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
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web