mirror of
https://github.com/Fishwaldo/Star64_linux.git
synced 2025-04-02 04:24:05 +00:00
dt-bindings: mtd: Add YAML schemas for the generic NAND options
The NAND chips in MTD have a bunch of generic options that are needed in a device tree. Add a YAML schemas for those. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
This commit is contained in:
Maxime Ripard
Miquel Raynal
parent
cf3bbe67be
commit
212e496935
2 changed files with 143 additions and 75 deletions
143
Documentation/devicetree/bindings/mtd/nand-controller.yaml
Normal file
143
Documentation/devicetree/bindings/mtd/nand-controller.yaml
Normal file
|
|
@ -0,0 +1,143 @@
|
||||||
|
# SPDX-License-Identifier: GPL-2.0
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/mtd/nand-controller.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: NAND Chip and NAND Controller Generic Binding
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Miquel Raynal <miquel.raynal@bootlin.com>
|
||||||
|
- Richard Weinberger <richard@nod.at>
|
||||||
|
|
||||||
|
description: |
|
||||||
|
The NAND controller should be represented with its own DT node, and
|
||||||
|
all NAND chips attached to this controller should be defined as
|
||||||
|
children nodes of the NAND controller. This representation should be
|
||||||
|
enforced even for simple controllers supporting only one chip.
|
||||||
|
|
||||||
|
The ECC strength and ECC step size properties define the user
|
||||||
|
desires in terms of correction capability of a controller. Together,
|
||||||
|
they request the ECC engine to correct {strength} bit errors per
|
||||||
|
{size} bytes.
|
||||||
|
|
||||||
|
The interpretation of these parameters is implementation-defined, so
|
||||||
|
not all implementations must support all possible
|
||||||
|
combinations. However, implementations are encouraged to further
|
||||||
|
specify the value(s) they support.
|
||||||
|
|
||||||
|
properties:
|
||||||
|
$nodename:
|
||||||
|
pattern: "^nand-controller(@.*)?"
|
||||||
|
|
||||||
|
"#address-cells":
|
||||||
|
const: 1
|
||||||
|
|
||||||
|
"#size-cells":
|
||||||
|
const: 0
|
||||||
|
|
||||||
|
ranges: true
|
||||||
|
|
||||||
|
patternProperties:
|
||||||
|
"^nand@[a-f0-9]$":
|
||||||
|
properties:
|
||||||
|
reg:
|
||||||
|
description:
|
||||||
|
Contains the native Ready/Busy IDs.
|
||||||
|
|
||||||
|
nand-ecc-mode:
|
||||||
|
allOf:
|
||||||
|
- $ref: /schemas/types.yaml#/definitions/string
|
||||||
|
- enum: [ none, soft, hw, hw_syndrome, hw_oob_first, on-die ]
|
||||||
|
description:
|
||||||
|
Desired ECC engine, either hardware (most of the time
|
||||||
|
embedded in the NAND controller) or software correction
|
||||||
|
(Linux will handle the calculations). soft_bch is deprecated
|
||||||
|
and should be replaced by soft and nand-ecc-algo.
|
||||||
|
|
||||||
|
nand-ecc-algo:
|
||||||
|
allOf:
|
||||||
|
- $ref: /schemas/types.yaml#/definitions/string
|
||||||
|
- enum: [ hamming, bch, rs ]
|
||||||
|
description:
|
||||||
|
Desired ECC algorithm.
|
||||||
|
|
||||||
|
nand-bus-width:
|
||||||
|
allOf:
|
||||||
|
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||||
|
- enum: [ 8, 16 ]
|
||||||
|
- default: 8
|
||||||
|
description:
|
||||||
|
Bus width to the NAND chip
|
||||||
|
|
||||||
|
nand-on-flash-bbt:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/flag
|
||||||
|
description:
|
||||||
|
With this property, the OS will search the device for a Bad
|
||||||
|
Block Table (BBT). If not found, it will create one, reserve
|
||||||
|
a few blocks at the end of the device to store it and update
|
||||||
|
it as the device ages. Otherwise, the out-of-band area of a
|
||||||
|
few pages of all the blocks will be scanned at boot time to
|
||||||
|
find Bad Block Markers (BBM). These markers will help to
|
||||||
|
build a volatile BBT in RAM.
|
||||||
|
|
||||||
|
nand-ecc-strength:
|
||||||
|
allOf:
|
||||||
|
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||||
|
- minimum: 1
|
||||||
|
description:
|
||||||
|
Maximum number of bits that can be corrected per ECC step.
|
||||||
|
|
||||||
|
nand-ecc-step-size:
|
||||||
|
allOf:
|
||||||
|
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||||
|
- minimum: 1
|
||||||
|
description:
|
||||||
|
Number of data bytes covered by a single ECC step.
|
||||||
|
|
||||||
|
nand-ecc-maximize:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/flag
|
||||||
|
description:
|
||||||
|
Whether or not the ECC strength should be maximized. The
|
||||||
|
maximum ECC strength is both controller and chip
|
||||||
|
dependent. The ECC engine has to select the ECC config
|
||||||
|
providing the best strength and taking the OOB area size
|
||||||
|
constraint into account. This is particularly useful when
|
||||||
|
only the in-band area is used by the upper layers, and you
|
||||||
|
want to make your NAND as reliable as possible.
|
||||||
|
|
||||||
|
nand-is-boot-medium:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/flag
|
||||||
|
description:
|
||||||
|
Whether or not the NAND chip is a boot medium. Drivers might
|
||||||
|
use this information to select ECC algorithms supported by
|
||||||
|
the boot ROM or similar restrictions.
|
||||||
|
|
||||||
|
nand-rb:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||||
|
description:
|
||||||
|
Contains the native Ready/Busy IDs.
|
||||||
|
|
||||||
|
required:
|
||||||
|
- reg
|
||||||
|
|
||||||
|
required:
|
||||||
|
- "#address-cells"
|
||||||
|
- "#size-cells"
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
nand-controller {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
/* controller specific properties */
|
||||||
|
|
||||||
|
nand@0 {
|
||||||
|
reg = <0>;
|
||||||
|
nand-ecc-mode = "soft";
|
||||||
|
nand-ecc-algo = "bch";
|
||||||
|
|
||||||
|
/* controller specific properties */
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
@ -1,75 +0,0 @@
|
||||||
* NAND chip and NAND controller generic binding
|
|
||||||
|
|
||||||
NAND controller/NAND chip representation:
|
|
||||||
|
|
||||||
The NAND controller should be represented with its own DT node, and all
|
|
||||||
NAND chips attached to this controller should be defined as children nodes
|
|
||||||
of the NAND controller. This representation should be enforced even for
|
|
||||||
simple controllers supporting only one chip.
|
|
||||||
|
|
||||||
Mandatory NAND controller properties:
|
|
||||||
- #address-cells: depends on your controller. Should at least be 1 to
|
|
||||||
encode the CS line id.
|
|
||||||
- #size-cells: depends on your controller. Put zero unless you need a
|
|
||||||
mapping between CS lines and dedicated memory regions
|
|
||||||
|
|
||||||
Optional NAND controller properties
|
|
||||||
- ranges: only needed if you need to define a mapping between CS lines and
|
|
||||||
memory regions
|
|
||||||
|
|
||||||
Optional NAND chip properties:
|
|
||||||
|
|
||||||
- nand-ecc-mode : String, operation mode of the NAND ecc mode.
|
|
||||||
Supported values are: "none", "soft", "hw", "hw_syndrome",
|
|
||||||
"hw_oob_first", "on-die".
|
|
||||||
Deprecated values:
|
|
||||||
"soft_bch": use "soft" and nand-ecc-algo instead
|
|
||||||
- nand-ecc-algo: string, algorithm of NAND ECC.
|
|
||||||
Valid values are: "hamming", "bch", "rs".
|
|
||||||
- nand-bus-width : 8 or 16 bus width if not present 8
|
|
||||||
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
|
|
||||||
|
|
||||||
- nand-ecc-strength: integer representing the number of bits to correct
|
|
||||||
per ECC step.
|
|
||||||
|
|
||||||
- nand-ecc-step-size: integer representing the number of data bytes
|
|
||||||
that are covered by a single ECC step.
|
|
||||||
|
|
||||||
- nand-ecc-maximize: boolean used to specify that you want to maximize ECC
|
|
||||||
strength. The maximum ECC strength is both controller and
|
|
||||||
chip dependent. The controller side has to select the ECC
|
|
||||||
config providing the best strength and taking the OOB area
|
|
||||||
size constraint into account.
|
|
||||||
This is particularly useful when only the in-band area is
|
|
||||||
used by the upper layers, and you want to make your NAND
|
|
||||||
as reliable as possible.
|
|
||||||
- nand-is-boot-medium: Whether the NAND chip is a boot medium. Drivers might use
|
|
||||||
this information to select ECC algorithms supported by
|
|
||||||
the boot ROM or similar restrictions.
|
|
||||||
|
|
||||||
- nand-rb: shall contain the native Ready/Busy ids.
|
|
||||||
|
|
||||||
The ECC strength and ECC step size properties define the correction capability
|
|
||||||
of a controller. Together, they say a controller can correct "{strength} bit
|
|
||||||
errors per {size} bytes".
|
|
||||||
|
|
||||||
The interpretation of these parameters is implementation-defined, so not all
|
|
||||||
implementations must support all possible combinations. However, implementations
|
|
||||||
are encouraged to further specify the value(s) they support.
|
|
||||||
|
|
||||||
Example:
|
|
||||||
|
|
||||||
nand-controller {
|
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
|
|
||||||
/* controller specific properties */
|
|
||||||
|
|
||||||
nand@0 {
|
|
||||||
reg = <0>;
|
|
||||||
nand-ecc-mode = "soft";
|
|
||||||
nand-ecc-algo = "bch";
|
|
||||||
|
|
||||||
/* controller specific properties */
|
|
||||||
};
|
|
||||||
};
|
|
||||||
Loading…
Add table
Reference in a new issue