To reach higher capacities, arrays of chips are now pretty common.
Unfortunately, most of the controllers have been designed a decade ago
and did not all anticipate the need for several chip-selects. The new
cs-gpios property allows to workaround this limitation by adding as many
GPIO chip-select as needed.
Signed-off-by: Miquel Raynal <miquel.raynal@xxxxxxxxxxx>
---
.../devicetree/bindings/mtd/nand-controller.yaml | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index 678b39952502..70a400e385b2 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -38,6 +38,15 @@ properties:
ranges: true
+ cs-gpios:
+ description:
+ Array of chip-select available to the controller. The first
+ entries are a 1:1 mapping of the available chip-select on the
+ NAND controller (even if they are not used). As many additional
+ chip-select as needed may follow and should be phandles of GPIO
+ lines. 'reg' entries of the NAND chip subnodes become indexes of
+ this array when this property is present.
+
patternProperties:
"^nand@[a-f0-9]$":
type: object
@@ -164,14 +173,19 @@ examples:
nand-controller {
#address-cells = <1>;
#size-cells = <0>;
+ gpio-cs = <0>, <&gpioA 1>; /* A single native CS is available */
/* controller specific properties */
nand@0 {
- reg = <0>;
+ reg = <0>; /* Native CS */
nand-use-soft-ecc-engine;
nand-ecc-algo = "bch";
/* controller specific properties */
};
+
+ nand@1 {
+ reg = <1>; /* GPIO CS */
+ };
};
--
2.27.0
