Hi,
This series picks up Ramuthevar's effort on converting the Cadence QSPI
bindings to yaml [0]. During the conversion process, I discovered that
some TI device tree files were not using the compatible correctly. Those
are fixed in patches 1-3.
[0] https://patchwork.kernel.org/project/spi-devel-general/patch/20201116031003.19062-6-vadivel.muruganx.ramuthevar@linux.intel.com/
Pratyush Yadav (3):
arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible
arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible
arm64: dts: ti: k3-am64-main: Fix ospi compatible
Ramuthevar Vadivel Murugan (1):
dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
.../bindings/spi/cadence-quadspi.txt | 68 ---------
.../bindings/spi/cdns,qspi-nor.yaml | 143 ++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 2 +-
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 2 +-
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 +-
5 files changed, 147 insertions(+), 72 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
--
2.30.0
The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <[email protected]>
---
arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index 5408ec815d58..2ab5a7a15bd5 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -271,7 +271,7 @@ hbmc: hyperbus@47034000 {
};
ospi0: spi@47040000 {
- compatible = "ti,am654-ospi";
+ compatible = "ti,am654-ospi", "cdns,qspi-nor";
reg = <0x0 0x47040000 0x0 0x100>,
<0x5 0x00000000 0x1 0x0000000>;
interrupts = <GIC_SPI 840 IRQ_TYPE_LEVEL_HIGH>;
--
2.30.0
The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <[email protected]>
---
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index 6c44afae9187..d56e3475aee7 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -180,7 +180,7 @@ fss: fss@47000000 {
ranges;
ospi0: spi@47040000 {
- compatible = "ti,am654-ospi";
+ compatible = "ti,am654-ospi", "cdns,qspi-nor";
reg = <0x0 0x47040000 0x0 0x100>,
<0x5 0x00000000 0x1 0x0000000>;
interrupts = <GIC_SPI 840 IRQ_TYPE_LEVEL_HIGH>;
@@ -197,7 +197,7 @@ ospi0: spi@47040000 {
};
ospi1: spi@47050000 {
- compatible = "ti,am654-ospi";
+ compatible = "ti,am654-ospi", "cdns,qspi-nor";
reg = <0x0 0x47050000 0x0 0x100>,
<0x7 0x00000000 0x1 0x00000000>;
interrupts = <GIC_SPI 841 IRQ_TYPE_LEVEL_HIGH>;
--
2.30.0
The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <[email protected]>
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index b997d13f9ec5..3cbdd33384a0 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -592,7 +592,7 @@ fss: bus@fc00000 {
ranges;
ospi0: spi@fc40000 {
- compatible = "ti,am654-ospi";
+ compatible = "ti,am654-ospi", "cdns,qspi-nor";
reg = <0x00 0x0fc40000 0x00 0x100>,
<0x05 0x00000000 0x01 0x00000000>;
interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
--
2.30.0
From: Ramuthevar Vadivel Murugan <[email protected]>
There is no way as of now to have a parent or bus defining properties
for child nodes. For now, avoid it in the example to silence warnings on
dt_schema_check. We can figure out how to deal with actual dts files
later.
Signed-off-by: Ramuthevar Vadivel Murugan <[email protected]>
Signed-off-by: Pratyush Yadav <[email protected]>
[[email protected]: Fix how compatible is defined, make reset optional, fix
minor typos, remove subnode properties in example, update commit
message.]
---
.../bindings/spi/cadence-quadspi.txt | 68 ---------
.../bindings/spi/cdns,qspi-nor.yaml | 143 ++++++++++++++++++
2 files changed, 143 insertions(+), 68 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
deleted file mode 100644
index 8ace832a2d80..000000000000
--- a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-* Cadence Quad SPI controller
-
-Required properties:
-- compatible : should be one of the following:
- Generic default - "cdns,qspi-nor".
- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
- For Intel LGM SoC - "intel,lgm-qspi", "cdns,qspi-nor".
-- reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
-- interrupts : Unit interrupt specifier for the controller interrupt.
-- clocks : phandle to the Quad SPI clock.
-- cdns,fifo-depth : Size of the data FIFO in words.
-- cdns,fifo-width : Bus width of the data FIFO in bytes.
-- cdns,trigger-address : 32-bit indirect AHB trigger address.
-
-Optional properties:
-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
-
-Optional subnodes:
-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
-custom properties:
-- cdns,read-delay : Delay for read capture logic, in clock cycles
-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
- mode chip select outputs are de-asserted between
- transactions.
-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
- de-activated and the activation of another.
-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
- transaction and deasserting the device chip select
- (qspi_n_ss_out).
-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
- and first bit transfer.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include either "qspi" and/or "qspi-ocp".
-
-Example:
-
- qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa00000 0x1000>;
- interrupts = <0 151 4>;
- clocks = <&qspi_clk>;
- cdns,is-decoded-cs;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x00000000>;
- resets = <&rst QSPI_RESET>, <&rst QSPI_OCP_RESET>;
- reset-names = "qspi", "qspi-ocp";
-
- flash0: n25q00@0 {
- ...
- cdns,read-delay = <4>;
- cdns,tshsl-ns = <50>;
- cdns,tsd2d-ns = <50>;
- cdns,tchsh-ns = <4>;
- cdns,tslch-ns = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
new file mode 100644
index 000000000000..0e7087cc8bf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence Quad SPI controller
+
+maintainers:
+ - Pratyush Yadav <[email protected]>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ti,k2g-qspi
+ - ti,am654-ospi
+ - intel,lgm-qspi
+ - const: cdns,qspi-nor
+ - const: cdns,qspi-nor
+
+ reg:
+ items:
+ - description: the controller register set
+ - description: the controller data area
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ cdns,fifo-depth:
+ description:
+ Size of the data FIFO in words.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 128, 256 ]
+ default: 128
+
+ cdns,fifo-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Bus width of the data FIFO in bytes.
+ default: 4
+
+ cdns,trigger-address:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ 32-bit indirect AHB trigger address.
+
+ cdns,is-decoded-cs:
+ type: boolean
+ description:
+ Flag to indicate whether decoder is used to select different chip select
+ for different memory regions.
+
+ cdns,rclk-en:
+ type: boolean
+ description:
+ Flag to indicate that QSPI return clock is used to latch the read
+ data rather than the QSPI clock. Make sure that QSPI return clock
+ is populated on the board before using this property.
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [ qspi, qspi-ocp ]
+
+# subnode's properties
+patternProperties:
+ "@[0-9a-f]+$":
+ type: object
+ description:
+ Flash device uses the below defined properties in the subnode.
+
+ properties:
+ cdns,read-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay for read capture logic, in clock cycles.
+
+ cdns,tshsl-ns:
+ description:
+ Delay in nanoseconds for the length that the master mode chip select
+ outputs are de-asserted between transactions.
+
+ cdns,tsd2d-ns:
+ description:
+ Delay in nanoseconds between one chip select being de-activated
+ and the activation of another.
+
+ cdns,tchsh-ns:
+ description:
+ Delay in nanoseconds between last bit of current transaction and
+ deasserting the device chip select (qspi_n_ss_out).
+
+ cdns,tslch-ns:
+ description:
+ Delay in nanoseconds between setting qspi_n_ss_out low and
+ first bit transfer.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - cdns,fifo-depth
+ - cdns,fifo-width
+ - cdns,trigger-address
+ - '#address-cells'
+ - '#size-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ qspi: spi@ff705000 {
+ compatible = "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xff705000 0x1000>,
+ <0xffa00000 0x1000>;
+ interrupts = <0 151 4>;
+ clocks = <&qspi_clk>;
+ cdns,fifo-depth = <128>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x00000000>;
+ resets = <&rst 0x1>, <&rst 0x2>;
+ reset-names = "qspi", "qspi-ocp";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ };
+ };
--
2.30.0
On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote:
> From: Ramuthevar Vadivel Murugan <[email protected]>
>
> There is no way as of now to have a parent or bus defining properties
> for child nodes. For now, avoid it in the example to silence warnings on
> dt_schema_check. We can figure out how to deal with actual dts files
> later.
>
> Signed-off-by: Ramuthevar Vadivel Murugan <[email protected]>
> Signed-off-by: Pratyush Yadav <[email protected]>
> [[email protected]: Fix how compatible is defined, make reset optional, fix
> minor typos, remove subnode properties in example, update commit
> message.]
> ---
> .../bindings/spi/cadence-quadspi.txt | 68 ---------
> .../bindings/spi/cdns,qspi-nor.yaml | 143 ++++++++++++++++++
> 2 files changed, 143 insertions(+), 68 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> new file mode 100644
> index 000000000000..0e7087cc8bf9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> @@ -0,0 +1,143 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence Quad SPI controller
> +
> +maintainers:
> + - Pratyush Yadav <[email protected]>
> +
> +allOf:
> + - $ref: spi-controller.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - ti,k2g-qspi
> + - ti,am654-ospi
> + - intel,lgm-qspi
> + - const: cdns,qspi-nor
> + - const: cdns,qspi-nor
> +
> + reg:
> + items:
> + - description: the controller register set
> + - description: the controller data area
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + cdns,fifo-depth:
> + description:
> + Size of the data FIFO in words.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + enum: [ 128, 256 ]
> + default: 128
> +
> + cdns,fifo-width:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Bus width of the data FIFO in bytes.
> + default: 4
I assume there's some constraints on this?
With that,
Reviewed-by: Rob Herring <[email protected]>
> +
> + cdns,trigger-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + 32-bit indirect AHB trigger address.
> +
> + cdns,is-decoded-cs:
> + type: boolean
> + description:
> + Flag to indicate whether decoder is used to select different chip select
> + for different memory regions.
> +
> + cdns,rclk-en:
> + type: boolean
> + description:
> + Flag to indicate that QSPI return clock is used to latch the read
> + data rather than the QSPI clock. Make sure that QSPI return clock
> + is populated on the board before using this property.
> +
> + resets:
> + maxItems: 2
> +
> + reset-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + enum: [ qspi, qspi-ocp ]
> +
> +# subnode's properties
> +patternProperties:
> + "@[0-9a-f]+$":
> + type: object
> + description:
> + Flash device uses the below defined properties in the subnode.
> +
> + properties:
> + cdns,read-delay:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Delay for read capture logic, in clock cycles.
> +
> + cdns,tshsl-ns:
> + description:
> + Delay in nanoseconds for the length that the master mode chip select
> + outputs are de-asserted between transactions.
> +
> + cdns,tsd2d-ns:
> + description:
> + Delay in nanoseconds between one chip select being de-activated
> + and the activation of another.
> +
> + cdns,tchsh-ns:
> + description:
> + Delay in nanoseconds between last bit of current transaction and
> + deasserting the device chip select (qspi_n_ss_out).
> +
> + cdns,tslch-ns:
> + description:
> + Delay in nanoseconds between setting qspi_n_ss_out low and
> + first bit transfer.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - cdns,fifo-depth
> + - cdns,fifo-width
> + - cdns,trigger-address
> + - '#address-cells'
> + - '#size-cells'
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + qspi: spi@ff705000 {
> + compatible = "cdns,qspi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xff705000 0x1000>,
> + <0xffa00000 0x1000>;
> + interrupts = <0 151 4>;
> + clocks = <&qspi_clk>;
> + cdns,fifo-depth = <128>;
> + cdns,fifo-width = <4>;
> + cdns,trigger-address = <0x00000000>;
> + resets = <&rst 0x1>, <&rst 0x2>;
> + reset-names = "qspi", "qspi-ocp";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0x0>;
> + };
> + };
> --
> 2.30.0
>
On 27/03/21 12:36PM, Rob Herring wrote:
> On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote:
> > From: Ramuthevar Vadivel Murugan <[email protected]>
> >
> > There is no way as of now to have a parent or bus defining properties
> > for child nodes. For now, avoid it in the example to silence warnings on
> > dt_schema_check. We can figure out how to deal with actual dts files
> > later.
> >
> > Signed-off-by: Ramuthevar Vadivel Murugan <[email protected]>
> > Signed-off-by: Pratyush Yadav <[email protected]>
> > [[email protected]: Fix how compatible is defined, make reset optional, fix
> > minor typos, remove subnode properties in example, update commit
> > message.]
> > ---
> > .../bindings/spi/cadence-quadspi.txt | 68 ---------
> > .../bindings/spi/cdns,qspi-nor.yaml | 143 ++++++++++++++++++
> > 2 files changed, 143 insertions(+), 68 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> > create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
>
>
> > diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> > new file mode 100644
> > index 000000000000..0e7087cc8bf9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> > @@ -0,0 +1,143 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Cadence Quad SPI controller
> > +
> > +maintainers:
> > + - Pratyush Yadav <[email protected]>
> > +
> > +allOf:
> > + - $ref: spi-controller.yaml#
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - ti,k2g-qspi
> > + - ti,am654-ospi
> > + - intel,lgm-qspi
> > + - const: cdns,qspi-nor
> > + - const: cdns,qspi-nor
> > +
> > + reg:
> > + items:
> > + - description: the controller register set
> > + - description: the controller data area
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + cdns,fifo-depth:
> > + description:
> > + Size of the data FIFO in words.
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > + enum: [ 128, 256 ]
> > + default: 128
> > +
> > + cdns,fifo-width:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Bus width of the data FIFO in bytes.
> > + default: 4
>
> I assume there's some constraints on this?
IIUC this is a matter of how the peripheral is implemented and there are
no clear constraints. Different implementations can use different bus
widths for the SRAM bus but I don't see any mention of minimum or
maximum values. FWIW, all users in the kernel use a 4 byte bus.
>
> With that,
>
> Reviewed-by: Rob Herring <[email protected]>
Thanks.
>
> > +
> > + cdns,trigger-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + 32-bit indirect AHB trigger address.
> > +
> > + cdns,is-decoded-cs:
> > + type: boolean
> > + description:
> > + Flag to indicate whether decoder is used to select different chip select
> > + for different memory regions.
> > +
> > + cdns,rclk-en:
> > + type: boolean
> > + description:
> > + Flag to indicate that QSPI return clock is used to latch the read
> > + data rather than the QSPI clock. Make sure that QSPI return clock
> > + is populated on the board before using this property.
> > +
> > + resets:
> > + maxItems: 2
> > +
> > + reset-names:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + enum: [ qspi, qspi-ocp ]
> > +
> > +# subnode's properties
> > +patternProperties:
> > + "@[0-9a-f]+$":
> > + type: object
> > + description:
> > + Flash device uses the below defined properties in the subnode.
> > +
> > + properties:
> > + cdns,read-delay:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Delay for read capture logic, in clock cycles.
> > +
> > + cdns,tshsl-ns:
> > + description:
> > + Delay in nanoseconds for the length that the master mode chip select
> > + outputs are de-asserted between transactions.
> > +
> > + cdns,tsd2d-ns:
> > + description:
> > + Delay in nanoseconds between one chip select being de-activated
> > + and the activation of another.
> > +
> > + cdns,tchsh-ns:
> > + description:
> > + Delay in nanoseconds between last bit of current transaction and
> > + deasserting the device chip select (qspi_n_ss_out).
> > +
> > + cdns,tslch-ns:
> > + description:
> > + Delay in nanoseconds between setting qspi_n_ss_out low and
> > + first bit transfer.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - cdns,fifo-depth
> > + - cdns,fifo-width
> > + - cdns,trigger-address
> > + - '#address-cells'
> > + - '#size-cells'
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + qspi: spi@ff705000 {
> > + compatible = "cdns,qspi-nor";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0xff705000 0x1000>,
> > + <0xffa00000 0x1000>;
> > + interrupts = <0 151 4>;
> > + clocks = <&qspi_clk>;
> > + cdns,fifo-depth = <128>;
> > + cdns,fifo-width = <4>;
> > + cdns,trigger-address = <0x00000000>;
> > + resets = <&rst 0x1>, <&rst 0x2>;
> > + reset-names = "qspi", "qspi-ocp";
> > +
> > + flash@0 {
> > + compatible = "jedec,spi-nor";
> > + reg = <0x0>;
> > + };
> > + };
> > --
> > 2.30.0
> >
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote:
> From: Ramuthevar Vadivel Murugan <[email protected]>
>
> There is no way as of now to have a parent or bus defining properties
> for child nodes. For now, avoid it in the example to silence warnings on
> dt_schema_check. We can figure out how to deal with actual dts files
> later.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
On 31/03/21 08:11PM, Mark Brown wrote:
> On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote:
> > From: Ramuthevar Vadivel Murugan <[email protected]>
> >
> > There is no way as of now to have a parent or bus defining properties
> > for child nodes. For now, avoid it in the example to silence warnings on
> > dt_schema_check. We can figure out how to deal with actual dts files
> > later.
>
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.
I did take a look by running git log on
Documentation/devicetree/bindings/spi/ and there is no single style
being used. Using "dt-bindings: spi:" is a popular choice. Some other
commits just use "spi:". And then some use "spi: dt-bindings:". The last
commit to touch cadence-quadspi.txt (fcebca39938f) used the prefix
"dt-bindings: spi:".
So on the prefix front I think the subject is good enough. Of course, if
you have any other preference then it can be re-worded but let's first
be clear on what the expectation is. And then let's make sure to apply
it to all future patches uniformly. This way future contributors won't
have to take a guess on what the expected prefix is.
Apart from the prefix is there anything else to improve? IMHO the
subject is good enough but I'm open to suggestions.
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
>
> Signed-off-by: Pratyush Yadav <[email protected]>
> ---
Reviewed-by: Vignesh Raghavendra <[email protected]>
> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> index 6c44afae9187..d56e3475aee7 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> @@ -180,7 +180,7 @@ fss: fss@47000000 {
> ranges;
>
> ospi0: spi@47040000 {
> - compatible = "ti,am654-ospi";
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> reg = <0x0 0x47040000 0x0 0x100>,
> <0x5 0x00000000 0x1 0x0000000>;
> interrupts = <GIC_SPI 840 IRQ_TYPE_LEVEL_HIGH>;
> @@ -197,7 +197,7 @@ ospi0: spi@47040000 {
> };
>
> ospi1: spi@47050000 {
> - compatible = "ti,am654-ospi";
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> reg = <0x0 0x47050000 0x0 0x100>,
> <0x7 0x00000000 0x1 0x00000000>;
> interrupts = <GIC_SPI 841 IRQ_TYPE_LEVEL_HIGH>;
>
On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
>
> Signed-off-by: Pratyush Yadav <[email protected]>
> ---
Reviewed-by: Vignesh Raghavendra <[email protected]>
> arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> index 5408ec815d58..2ab5a7a15bd5 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> @@ -271,7 +271,7 @@ hbmc: hyperbus@47034000 {
> };
>
> ospi0: spi@47040000 {
> - compatible = "ti,am654-ospi";
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> reg = <0x0 0x47040000 0x0 0x100>,
> <0x5 0x00000000 0x1 0x0000000>;
> interrupts = <GIC_SPI 840 IRQ_TYPE_LEVEL_HIGH>;
>
On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
>
> Signed-off-by: Pratyush Yadav <[email protected]>
> ---
Reviewed-by: Vignesh Raghavendra <[email protected]>
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> index b997d13f9ec5..3cbdd33384a0 100644
> --- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -592,7 +592,7 @@ fss: bus@fc00000 {
> ranges;
>
> ospi0: spi@fc40000 {
> - compatible = "ti,am654-ospi";
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> reg = <0x00 0x0fc40000 0x00 0x100>,
> <0x05 0x00000000 0x01 0x00000000>;
> interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
>
On 3/29/21 11:52 PM, Pratyush Yadav wrote:
>>> + cdns,fifo-depth:
>>> + description:
>>> + Size of the data FIFO in words.
>>> + $ref: "/schemas/types.yaml#/definitions/uint32"
>>> + enum: [ 128, 256 ]
>>> + default: 128
>>> +
>>> + cdns,fifo-width:
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + description:
>>> + Bus width of the data FIFO in bytes.
>>> + default: 4
>> I assume there's some constraints on this?
> IIUC this is a matter of how the peripheral is implemented and there are
> no clear constraints. Different implementations can use different bus
> widths for the SRAM bus but I don't see any mention of minimum or
> maximum values. FWIW, all users in the kernel use a 4 byte bus.
>
IMO a safe constraint would be to set a range of 1 to 4 (8/16/24/32 bit
wide) given this represents SRAM bus width. Binding can always be
updated if there exists an implementation with higher SRAM bus
width/fifo-width (although that's highly unlikely given there are no
such examples today).
But leaving it open ended with range of 0 to UINT_MAX sounds incorrect
to me.
>> With that,
>>
>> Reviewed-by: Rob Herring <[email protected]>
> Thanks.
>
On 01/04/21 01:57PM, Vignesh Raghavendra wrote:
>
>
> On 3/29/21 11:52 PM, Pratyush Yadav wrote:
> >>> + cdns,fifo-depth:
> >>> + description:
> >>> + Size of the data FIFO in words.
> >>> + $ref: "/schemas/types.yaml#/definitions/uint32"
> >>> + enum: [ 128, 256 ]
> >>> + default: 128
> >>> +
> >>> + cdns,fifo-width:
> >>> + $ref: /schemas/types.yaml#/definitions/uint32
> >>> + description:
> >>> + Bus width of the data FIFO in bytes.
> >>> + default: 4
> >> I assume there's some constraints on this?
> > IIUC this is a matter of how the peripheral is implemented and there are
> > no clear constraints. Different implementations can use different bus
> > widths for the SRAM bus but I don't see any mention of minimum or
> > maximum values. FWIW, all users in the kernel use a 4 byte bus.
> >
>
> IMO a safe constraint would be to set a range of 1 to 4 (8/16/24/32 bit
> wide) given this represents SRAM bus width. Binding can always be
> updated if there exists an implementation with higher SRAM bus
> width/fifo-width (although that's highly unlikely given there are no
> such examples today).
>
> But leaving it open ended with range of 0 to UINT_MAX sounds incorrect
> to me.
Ok. Will respin.
>
> >> With that,
> >>
> >> Reviewed-by: Rob Herring <[email protected]>
> > Thanks.
> >
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
On Fri, 26 Mar 2021 18:30:30 +0530, Pratyush Yadav wrote:
> This series picks up Ramuthevar's effort on converting the Cadence QSPI
> bindings to yaml [0]. During the conversion process, I discovered that
> some TI device tree files were not using the compatible correctly. Those
> are fixed in patches 1-3.
>
> [0] https://patchwork.kernel.org/project/spi-devel-general/patch/20201116031003.19062-6-vadivel.muruganx.ramuthevar@linux.intel.com/
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[4/4] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
commit: e54338004c032b0bb556c7a56db8688454b6587e
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
On Thu, Apr 01, 2021 at 01:09:32AM +0530, Pratyush Yadav wrote:
> I did take a look by running git log on
> Documentation/devicetree/bindings/spi/ and there is no single style
> being used. Using "dt-bindings: spi:" is a popular choice. Some other
> commits just use "spi:". And then some use "spi: dt-bindings:". The last
> commit to touch cadence-quadspi.txt (fcebca39938f) used the prefix
> "dt-bindings: spi:".
Yes, lots of people pick unfortunate subject lines for DT patches - that
doesn't mean it's good. I'm looking to see spi: same as for all other
SPI patches.
> So on the prefix front I think the subject is good enough. Of course, if
> you have any other preference then it can be re-worded but let's first
> be clear on what the expectation is. And then let's make sure to apply
> it to all future patches uniformly. This way future contributors won't
> have to take a guess on what the expected prefix is.
I do edit some percentage of patches, but some do slip through for
various reasons. There's also some things that just get completely
missed, especially if there isn't also a code patch nearby.
> Apart from the prefix is there anything else to improve? IMHO the
> subject is good enough but I'm open to suggestions.
There was the thing with constraints.
On Fri, 26 Mar 2021 18:30:30 +0530, Pratyush Yadav wrote:
> This series picks up Ramuthevar's effort on converting the Cadence QSPI
> bindings to yaml [0]. During the conversion process, I discovered that
> some TI device tree files were not using the compatible correctly. Those
> are fixed in patches 1-3.
>
> [0] https://patchwork.kernel.org/project/spi-devel-general/patch/20201116031003.19062-6-vadivel.muruganx.ramuthevar@linux.intel.com/
>
> [...]
Hi Pratyush Yadav,
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/4] arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible
commit: f1b6f6e7f595ed66ba5f5d628df3d259218d584b
[2/4] arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible
commit: 0e941f496a8bdc47d34199c17f81b09b0dbe14ae
[3/4] arm64: dts: ti: k3-am64-main: Fix ospi compatible
commit: 112e5934ff3a7505e583365213a27f990922b76b
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 01/04/21 03:13PM, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 01:09:32AM +0530, Pratyush Yadav wrote:
>
> > I did take a look by running git log on
> > Documentation/devicetree/bindings/spi/ and there is no single style
> > being used. Using "dt-bindings: spi:" is a popular choice. Some other
> > commits just use "spi:". And then some use "spi: dt-bindings:". The last
> > commit to touch cadence-quadspi.txt (fcebca39938f) used the prefix
> > "dt-bindings: spi:".
>
> Yes, lots of people pick unfortunate subject lines for DT patches - that
> doesn't mean it's good. I'm looking to see spi: same as for all other
> SPI patches.
All right. "spi: dt-bindings:" it is from now on.
>
> > So on the prefix front I think the subject is good enough. Of course, if
> > you have any other preference then it can be re-worded but let's first
> > be clear on what the expectation is. And then let's make sure to apply
> > it to all future patches uniformly. This way future contributors won't
> > have to take a guess on what the expected prefix is.
>
> I do edit some percentage of patches, but some do slip through for
> various reasons. There's also some things that just get completely
> missed, especially if there isn't also a code patch nearby.
>
> > Apart from the prefix is there anything else to improve? IMHO the
> > subject is good enough but I'm open to suggestions.
>
> There was the thing with constraints.
Will send a follow up patch to add the constraints that Vignesh
suggested.
--
Regards,
Pratyush Yadav
Texas Instruments Inc.