| Message ID | 20210326130034.15231-1-p.yadav@ti.com |
|---|---|
| Headers | show |
| Series | Convert Cadence QSPI bindings to yaml | expand |
On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote: > From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> > > 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 <vadivel.muruganx.ramuthevar@linux.intel.com> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com> > [p.yadav@ti.com: 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 <p.yadav@ti.com> > + > +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 <robh@kernel.org> > + > + 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 <vadivel.muruganx.ramuthevar@linux.intel.com> > > > > 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 <vadivel.muruganx.ramuthevar@linux.intel.com> > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com> > > [p.yadav@ti.com: 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 <p.yadav@ti.com> > > + > > +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 <robh@kernel.org> 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 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 <vadivel.muruganx.ramuthevar@linux.intel.com> > > > > 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.
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 <p.yadav@ti.com> > --- Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> > 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 <p.yadav@ti.com> > --- Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> > 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 <robh@kernel.org> > Thanks. >
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
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 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.