| Message ID | 20220926225536.548139-1-marex@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] dt-bindings: memory-controller: st,stm32: Split off MC properties | expand |
On 27/09/2022 00:55, Marek Vasut wrote: > Split st,stm32-fmc2-ebi.yaml specific properties into st,stm32-fmc2-ebi-props.yaml , > split memory-controller bus peripheral properties into mc-peripheral-props.yaml , > reference the st,stm32-fmc2-ebi-props.yaml in mc-peripheral-props.yaml and > reference the mc-peripheral-props.yaml in micrel,ks8851.yaml . > > This way, the FMC2 controller properties in Micrel KSZ8851MLL ethernet > controller node can be properly validated. > > Fixes the following warning: > > " > arch/arm/boot/dts/stm32mp153c-dhcor-drc-compact.dtb: ethernet@1,0: Unevaluated properties are not allowed ('bank-width', 'st,fmc2-ebi-cs-mux-enable', 'st,fmc2-ebi-cs-transaction-type', 'st,fmc2-ebi-cs-buswidth', 'st,fmc2-ebi-cs-address-setup-ns', 'st,fmc2-ebi-cs-address-hold-ns', 'st,fmc2-ebi-cs-bus-turnaround-ns', 'st,fmc2-ebi-cs-data-setup-ns', 'st,fmc2-ebi-cs-data-hold-ns', 'st,fmc2-ebi-cs-write-address-setup-ns', 'st,fmc2-ebi-cs-write-address-hold-ns', 'st,fmc2-ebi-cs-write-bus-turnaround-ns', 'st,fmc2-ebi-cs-write-data-setup-ns', 'st,fmc2-ebi-cs-write-data-hold-ns' were unexpected) > " > > Reviewed-by: Rob Herring <robh@kernel.org> > Signed-off-by: Marek Vasut <marex@denx.de> > --- > Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> > Cc: Christophe Kerello <christophe.kerello@foss.st.com> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: devicetree@vger.kernel.org > Cc: linux-stm32@st-md-mailman.stormreply.com > To: linux-arm-kernel@lists.infradead.org > --- > V2: - Depends on bugfix [PATCH] dt-bindings: memory-controller: st,stm32: Fix st,fmc2_ebi-cs-write-address-setup-ns > - Replace MC controllers with Memory Controllers > - Add type uint32 and enum 1,2,4 to bank-width prop > - Add RB from Rob > --- > .../mc-peripheral-props.yaml | 38 +++++ > .../st,stm32-fmc2-ebi-props.yaml | 144 ++++++++++++++++++ > .../memory-controllers/st,stm32-fmc2-ebi.yaml | 137 ----------------- > .../bindings/net/micrel,ks8851.yaml | 1 + > 4 files changed, 183 insertions(+), 137 deletions(-) > create mode 100644 Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml > create mode 100644 Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml > > diff --git a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml > new file mode 100644 > index 0000000000000..53ae995462db7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml > @@ -0,0 +1,38 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/memory-controllers/mc-peripheral-props.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Peripheral-specific properties for a Memory Controller bus. > + > +description: > + Many Memory Controllers need to add properties to peripheral devices. > + They could be common properties like reg or they could be controller > + specific like delay in clock or data lines, etc. These properties need > + to be defined in the peripheral node because they are per-peripheral > + and there can be multiple peripherals attached to a controller. All > + those properties are listed here. The controller specific properties > + should go in their own separate schema that should be referenced > + from here. > + > +maintainers: > + - Marek Vasut <marex@denx.de> > + > +properties: > + reg: > + description: Bank number, base address and size of the device. > + > + bank-width: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: Bank width of the device, in bytes. > + enum: [1, 2, 4] > + > +required: > + - reg > + > +# The controller specific properties go here. > +allOf: > + - $ref: st,stm32-fmc2-ebi-props.yaml# > + > +additionalProperties: true > diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml > new file mode 100644 > index 0000000000000..475e4095068c2 > --- /dev/null > +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml > @@ -0,0 +1,144 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/memory-controllers/st,stm32-fmc2-ebi-props.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Peripheral properties for ST FMC2 Controller > + > +maintainers: > + - Christophe Kerello <christophe.kerello@foss.st.com> > + - Marek Vasut <marex@denx.de> > + > +properties: > + st,fmc2-ebi-cs-transaction-type: > + description: | > + Select one of the transactions type supported > + 0: Asynchronous mode 1 SRAM/FRAM. > + 1: Asynchronous mode 1 PSRAM. > + 2: Asynchronous mode A SRAM/FRAM. > + 3: Asynchronous mode A PSRAM. > + 4: Asynchronous mode 2 NOR. > + 5: Asynchronous mode B NOR. > + 6: Asynchronous mode C NOR. > + 7: Asynchronous mode D NOR. > + 8: Synchronous read synchronous write PSRAM. > + 9: Synchronous read asynchronous write PSRAM. > + 10: Synchronous read synchronous write NOR. > + 11: Synchronous read asynchronous write NOR. > + $ref: /schemas/types.yaml#/definitions/uint32 > + minimum: 0 > + maximum: 11 > + > + st,fmc2-ebi-cs-cclk-enable: > + description: Continuous clock enable (first bank must be configured > + in synchronous mode). The FMC_CLK is generated continuously > + during asynchronous and synchronous access. By default, the > + FMC_CLK is only generated during synchronous access. > + $ref: /schemas/types.yaml#/definitions/flag > + > + st,fmc2-ebi-cs-mux-enable: > + description: Address/Data multiplexed on databus (valid only with > + NOR and PSRAM transactions type). By default, Address/Data > + are not multiplexed. > + $ref: /schemas/types.yaml#/definitions/flag > + > + st,fmc2-ebi-cs-buswidth: > + description: Data bus width > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [ 8, 16 ] > + default: 16 > + > + st,fmc2-ebi-cs-waitpol-high: > + description: Wait signal polarity (NWAIT signal active high). > + By default, NWAIT is active low. > + $ref: /schemas/types.yaml#/definitions/flag > + > + st,fmc2-ebi-cs-waitcfg-enable: > + description: The NWAIT signal indicates wheither the data from the > + device are valid or if a wait state must be inserted when accessing > + the device in synchronous mode. By default, the NWAIT signal is > + active one data cycle before wait state. > + $ref: /schemas/types.yaml#/definitions/flag > + > + st,fmc2-ebi-cs-wait-enable: > + description: The NWAIT signal is enabled (its level is taken into > + account after the programmed latency period to insert wait states > + if asserted). By default, the NWAIT signal is disabled. > + $ref: /schemas/types.yaml#/definitions/flag > + > + st,fmc2-ebi-cs-asyncwait-enable: > + description: The NWAIT signal is taken into account during asynchronous > + transactions. By default, the NWAIT signal is not taken into account > + during asynchronous transactions. > + $ref: /schemas/types.yaml#/definitions/flag > + > + st,fmc2-ebi-cs-cpsize: > + description: CRAM page size. The controller splits the burst access > + when the memory page is reached. By default, no burst split when > + crossing page boundary. > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [ 0, 128, 256, 512, 1024 ] > + default: 0 > + > + st,fmc2-ebi-cs-byte-lane-setup-ns: > + description: This property configures the byte lane setup timing > + defined in nanoseconds from NBLx low to Chip Select NEx low. > + > + st,fmc2-ebi-cs-address-setup-ns: > + description: This property defines the duration of the address setup > + phase in nanoseconds used for asynchronous read/write transactions. > + > + st,fmc2-ebi-cs-address-hold-ns: > + description: This property defines the duration of the address hold > + phase in nanoseconds used for asynchronous multiplexed read/write > + transactions. > + > + st,fmc2-ebi-cs-data-setup-ns: > + description: This property defines the duration of the data setup phase > + in nanoseconds used for asynchronous read/write transactions. > + > + st,fmc2-ebi-cs-bus-turnaround-ns: > + description: This property defines the delay in nanoseconds between the > + end of current read/write transaction and the next transaction. > + > + st,fmc2-ebi-cs-data-hold-ns: > + description: This property defines the duration of the data hold phase > + in nanoseconds used for asynchronous read/write transactions. > + > + st,fmc2-ebi-cs-clk-period-ns: > + description: This property defines the FMC_CLK output signal period in > + nanoseconds. > + > + st,fmc2-ebi-cs-data-latency-ns: > + description: This property defines the data latency before reading or > + writing the first data in nanoseconds. > + > + st,fmc2-ebi-cs-write-address-setup-ns: > + description: This property defines the duration of the address setup > + phase in nanoseconds used for asynchronous write transactions. > + > + st,fmc2-ebi-cs-write-address-hold-ns: > + description: This property defines the duration of the address hold > + phase in nanoseconds used for asynchronous multiplexed write > + transactions. > + > + st,fmc2-ebi-cs-write-data-setup-ns: > + description: This property defines the duration of the data setup > + phase in nanoseconds used for asynchronous write transactions. > + > + st,fmc2-ebi-cs-write-bus-turnaround-ns: > + description: This property defines the delay between the end of current > + write transaction and the next transaction in nanoseconds. > + > + st,fmc2-ebi-cs-write-data-hold-ns: > + description: This property defines the duration of the data hold phase > + in nanoseconds used for asynchronous write transactions. > + > + st,fmc2-ebi-cs-max-low-pulse-ns: > + description: This property defines the maximum chip select low pulse > + duration in nanoseconds for synchronous transactions. When this timing > + reaches 0, the controller splits the current access, toggles NE to > + allow device refresh and restarts a new access. > + > +additionalProperties: true > diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml > index a1f535cececcc..49243f447eb90 100644 > --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml > +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml > @@ -49,143 +49,6 @@ patternProperties: > "^.*@[0-4],[a-f0-9]+$": > type: object > > - properties: > - reg: > - description: Bank number, base address and size of the device. > - To be equivalent (and similar to SPI peripherals and controllers) this should reference st,stm32-fmc2-ebi-props.yaml as well. After such reference, you can add here unevaluatedProperties:false (could be same or new patch as it is not related to actual split). Best regards, Krzysztof
On 9/28/22 09:10, Krzysztof Kozlowski wrote: Hi, [...] >> diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >> index a1f535cececcc..49243f447eb90 100644 >> --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >> +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >> @@ -49,143 +49,6 @@ patternProperties: >> "^.*@[0-4],[a-f0-9]+$": >> type: object >> >> - properties: >> - reg: >> - description: Bank number, base address and size of the device. >> - > > To be equivalent (and similar to SPI peripherals and controllers) this > should reference st,stm32-fmc2-ebi-props.yaml as well. > > After such reference, you can add here unevaluatedProperties:false > (could be same or new patch as it is not related to actual split). I don't think I understand. I don't see any ref from the controller node to its props in various SPI controllers (even if that would make sense): next$ git grep qspi-nor-peripheral-props.yaml Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml:$id: http://devicetree.org/schemas/spi/cdns,qspi-nor-peripheral-props.yaml# Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml: - $ref: cdns,qspi-nor-peripheral-props.yaml# No ref to cdns,qspi-nor-peripheral-props.yaml in Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml next$ git grep tegra210-quad-peripheral-props Documentation/devicetree/bindings/spi/nvidia,tegra210-quad-peripheral-props.yaml:$id: http://devicetree.org/schemas/spi/nvidia,tegra210-quad-peripheral-props.yaml# Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml: - $ref: nvidia,tegra210-quad-peripheral-props.yaml# No ref to nvidia,tegra210-quad-peripheral-props.yaml in Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml What am I missing here ?
On 28/09/2022 19:01, Marek Vasut wrote: > On 9/28/22 09:10, Krzysztof Kozlowski wrote: > > Hi, > > [...] > >>> diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>> index a1f535cececcc..49243f447eb90 100644 >>> --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>> +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>> @@ -49,143 +49,6 @@ patternProperties: >>> "^.*@[0-4],[a-f0-9]+$": >>> type: object >>> >>> - properties: >>> - reg: >>> - description: Bank number, base address and size of the device. >>> - >> >> To be equivalent (and similar to SPI peripherals and controllers) this >> should reference st,stm32-fmc2-ebi-props.yaml as well. >> >> After such reference, you can add here unevaluatedProperties:false >> (could be same or new patch as it is not related to actual split). > > I don't think I understand. I don't see any ref from the controller node > to its props in various SPI controllers (even if that would make sense): Because they reference spi peripheral props... > > next$ git grep qspi-nor-peripheral-props.yaml > Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml:$id: > http://devicetree.org/schemas/spi/cdns,qspi-nor-peripheral-props.yaml# > Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml: - > $ref: cdns,qspi-nor-peripheral-props.yaml# > > No ref to cdns,qspi-nor-peripheral-props.yaml in > Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml > > next$ git grep tegra210-quad-peripheral-props > Documentation/devicetree/bindings/spi/nvidia,tegra210-quad-peripheral-props.yaml:$id: > http://devicetree.org/schemas/spi/nvidia,tegra210-quad-peripheral-props.yaml# > Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml: - > $ref: nvidia,tegra210-quad-peripheral-props.yaml# > > No ref to nvidia,tegra210-quad-peripheral-props.yaml in > Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml All your examples do it - reference spi peripheral props. As I said, your change is now not equivalent. If any other device appears in st,stm32-fmc2-ebi, the schema won't be applied. Let me put it that way: you must have there additionalProperties:false or unevaluatedProperties:false. Once you add it, you start seeing errors leading to missing ref. Best regards, Krzysztof
On 9/28/22 19:24, Krzysztof Kozlowski wrote: > On 28/09/2022 19:01, Marek Vasut wrote: >> On 9/28/22 09:10, Krzysztof Kozlowski wrote: >> >> Hi, >> >> [...] >> >>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>>> index a1f535cececcc..49243f447eb90 100644 >>>> --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>>> +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>>> @@ -49,143 +49,6 @@ patternProperties: >>>> "^.*@[0-4],[a-f0-9]+$": >>>> type: object >>>> >>>> - properties: >>>> - reg: >>>> - description: Bank number, base address and size of the device. >>>> - >>> >>> To be equivalent (and similar to SPI peripherals and controllers) this >>> should reference st,stm32-fmc2-ebi-props.yaml as well. >>> >>> After such reference, you can add here unevaluatedProperties:false >>> (could be same or new patch as it is not related to actual split). >> >> I don't think I understand. I don't see any ref from the controller node >> to its props in various SPI controllers (even if that would make sense): > > Because they reference spi peripheral props... > >> >> next$ git grep qspi-nor-peripheral-props.yaml >> Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml:$id: >> http://devicetree.org/schemas/spi/cdns,qspi-nor-peripheral-props.yaml# >> Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml: - >> $ref: cdns,qspi-nor-peripheral-props.yaml# >> >> No ref to cdns,qspi-nor-peripheral-props.yaml in >> Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml >> >> next$ git grep tegra210-quad-peripheral-props >> Documentation/devicetree/bindings/spi/nvidia,tegra210-quad-peripheral-props.yaml:$id: >> http://devicetree.org/schemas/spi/nvidia,tegra210-quad-peripheral-props.yaml# >> Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml: - >> $ref: nvidia,tegra210-quad-peripheral-props.yaml# >> >> No ref to nvidia,tegra210-quad-peripheral-props.yaml in >> Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml > > All your examples do it - reference spi peripheral props. > > As I said, your change is now not equivalent. If any other device > appears in st,stm32-fmc2-ebi, the schema won't be applied. > > Let me put it that way: you must have there additionalProperties:false > or unevaluatedProperties:false. Once you add it, you start seeing errors > leading to missing ref. Is what you are trying to convey that Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml does ref spi-controller.yaml# and that one does patternProperties: ref: spi-peripheral-props.yaml ? So the fix for V3 should be the following ? diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml index 49243f447eb90..0448bd07f4310 100644 --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -48,6 +48,7 @@ properties: patternProperties: "^.*@[0-4],[a-f0-9]+$": type: object + $ref: st,stm32-fmc2-ebi-props.yaml required: - "#address-cells"
On 28/09/2022 19:44, Marek Vasut wrote: > On 9/28/22 19:24, Krzysztof Kozlowski wrote: >> On 28/09/2022 19:01, Marek Vasut wrote: >>> On 9/28/22 09:10, Krzysztof Kozlowski wrote: >>> >>> Hi, >>> >>> [...] >>> >>>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>>>> index a1f535cececcc..49243f447eb90 100644 >>>>> --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>>>> +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml >>>>> @@ -49,143 +49,6 @@ patternProperties: >>>>> "^.*@[0-4],[a-f0-9]+$": >>>>> type: object >>>>> >>>>> - properties: >>>>> - reg: >>>>> - description: Bank number, base address and size of the device. >>>>> - >>>> >>>> To be equivalent (and similar to SPI peripherals and controllers) this >>>> should reference st,stm32-fmc2-ebi-props.yaml as well. >>>> >>>> After such reference, you can add here unevaluatedProperties:false >>>> (could be same or new patch as it is not related to actual split). >>> >>> I don't think I understand. I don't see any ref from the controller node >>> to its props in various SPI controllers (even if that would make sense): >> >> Because they reference spi peripheral props... >> >>> >>> next$ git grep qspi-nor-peripheral-props.yaml >>> Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml:$id: >>> http://devicetree.org/schemas/spi/cdns,qspi-nor-peripheral-props.yaml# >>> Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml: - >>> $ref: cdns,qspi-nor-peripheral-props.yaml# >>> >>> No ref to cdns,qspi-nor-peripheral-props.yaml in >>> Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml >>> >>> next$ git grep tegra210-quad-peripheral-props >>> Documentation/devicetree/bindings/spi/nvidia,tegra210-quad-peripheral-props.yaml:$id: >>> http://devicetree.org/schemas/spi/nvidia,tegra210-quad-peripheral-props.yaml# >>> Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml: - >>> $ref: nvidia,tegra210-quad-peripheral-props.yaml# >>> >>> No ref to nvidia,tegra210-quad-peripheral-props.yaml in >>> Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml >> >> All your examples do it - reference spi peripheral props. >> >> As I said, your change is now not equivalent. If any other device >> appears in st,stm32-fmc2-ebi, the schema won't be applied. >> >> Let me put it that way: you must have there additionalProperties:false >> or unevaluatedProperties:false. Once you add it, you start seeing errors >> leading to missing ref. > > Is what you are trying to convey that > Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml does ref > spi-controller.yaml# and that one does patternProperties: ref: > spi-peripheral-props.yaml ? Yes. > > So the fix for V3 should be the following ? patternProperties: "^.*@[0-4],[a-f0-9]+$": type: object $ref: st,stm32-fmc2-ebi-props.yaml unevaluatedProperties: false Best regards, Krzysztof
On 28/09/2022 20:08, Krzysztof Kozlowski wrote: >> >> So the fix for V3 should be the following ? > > patternProperties: > "^.*@[0-4],[a-f0-9]+$": > type: object > $ref: st,stm32-fmc2-ebi-props.yaml > unevaluatedProperties: false As Marek pointed out on IRC, unevaluatedProperties:false won't work here. :) Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml new file mode 100644 index 0000000000000..53ae995462db7 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/mc-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral-specific properties for a Memory Controller bus. + +description: + Many Memory Controllers need to add properties to peripheral devices. + They could be common properties like reg or they could be controller + specific like delay in clock or data lines, etc. These properties need + to be defined in the peripheral node because they are per-peripheral + and there can be multiple peripherals attached to a controller. All + those properties are listed here. The controller specific properties + should go in their own separate schema that should be referenced + from here. + +maintainers: + - Marek Vasut <marex@denx.de> + +properties: + reg: + description: Bank number, base address and size of the device. + + bank-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Bank width of the device, in bytes. + enum: [1, 2, 4] + +required: + - reg + +# The controller specific properties go here. +allOf: + - $ref: st,stm32-fmc2-ebi-props.yaml# + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml new file mode 100644 index 0000000000000..475e4095068c2 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/st,stm32-fmc2-ebi-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral properties for ST FMC2 Controller + +maintainers: + - Christophe Kerello <christophe.kerello@foss.st.com> + - Marek Vasut <marex@denx.de> + +properties: + st,fmc2-ebi-cs-transaction-type: + description: | + Select one of the transactions type supported + 0: Asynchronous mode 1 SRAM/FRAM. + 1: Asynchronous mode 1 PSRAM. + 2: Asynchronous mode A SRAM/FRAM. + 3: Asynchronous mode A PSRAM. + 4: Asynchronous mode 2 NOR. + 5: Asynchronous mode B NOR. + 6: Asynchronous mode C NOR. + 7: Asynchronous mode D NOR. + 8: Synchronous read synchronous write PSRAM. + 9: Synchronous read asynchronous write PSRAM. + 10: Synchronous read synchronous write NOR. + 11: Synchronous read asynchronous write NOR. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 11 + + st,fmc2-ebi-cs-cclk-enable: + description: Continuous clock enable (first bank must be configured + in synchronous mode). The FMC_CLK is generated continuously + during asynchronous and synchronous access. By default, the + FMC_CLK is only generated during synchronous access. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-mux-enable: + description: Address/Data multiplexed on databus (valid only with + NOR and PSRAM transactions type). By default, Address/Data + are not multiplexed. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-buswidth: + description: Data bus width + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 8, 16 ] + default: 16 + + st,fmc2-ebi-cs-waitpol-high: + description: Wait signal polarity (NWAIT signal active high). + By default, NWAIT is active low. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-waitcfg-enable: + description: The NWAIT signal indicates wheither the data from the + device are valid or if a wait state must be inserted when accessing + the device in synchronous mode. By default, the NWAIT signal is + active one data cycle before wait state. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-wait-enable: + description: The NWAIT signal is enabled (its level is taken into + account after the programmed latency period to insert wait states + if asserted). By default, the NWAIT signal is disabled. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-asyncwait-enable: + description: The NWAIT signal is taken into account during asynchronous + transactions. By default, the NWAIT signal is not taken into account + during asynchronous transactions. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-cpsize: + description: CRAM page size. The controller splits the burst access + when the memory page is reached. By default, no burst split when + crossing page boundary. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 128, 256, 512, 1024 ] + default: 0 + + st,fmc2-ebi-cs-byte-lane-setup-ns: + description: This property configures the byte lane setup timing + defined in nanoseconds from NBLx low to Chip Select NEx low. + + st,fmc2-ebi-cs-address-setup-ns: + description: This property defines the duration of the address setup + phase in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-address-hold-ns: + description: This property defines the duration of the address hold + phase in nanoseconds used for asynchronous multiplexed read/write + transactions. + + st,fmc2-ebi-cs-data-setup-ns: + description: This property defines the duration of the data setup phase + in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-bus-turnaround-ns: + description: This property defines the delay in nanoseconds between the + end of current read/write transaction and the next transaction. + + st,fmc2-ebi-cs-data-hold-ns: + description: This property defines the duration of the data hold phase + in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-clk-period-ns: + description: This property defines the FMC_CLK output signal period in + nanoseconds. + + st,fmc2-ebi-cs-data-latency-ns: + description: This property defines the data latency before reading or + writing the first data in nanoseconds. + + st,fmc2-ebi-cs-write-address-setup-ns: + description: This property defines the duration of the address setup + phase in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-write-address-hold-ns: + description: This property defines the duration of the address hold + phase in nanoseconds used for asynchronous multiplexed write + transactions. + + st,fmc2-ebi-cs-write-data-setup-ns: + description: This property defines the duration of the data setup + phase in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-write-bus-turnaround-ns: + description: This property defines the delay between the end of current + write transaction and the next transaction in nanoseconds. + + st,fmc2-ebi-cs-write-data-hold-ns: + description: This property defines the duration of the data hold phase + in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-max-low-pulse-ns: + description: This property defines the maximum chip select low pulse + duration in nanoseconds for synchronous transactions. When this timing + reaches 0, the controller splits the current access, toggles NE to + allow device refresh and restarts a new access. + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml index a1f535cececcc..49243f447eb90 100644 --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -49,143 +49,6 @@ patternProperties: "^.*@[0-4],[a-f0-9]+$": type: object - properties: - reg: - description: Bank number, base address and size of the device. - - st,fmc2-ebi-cs-transaction-type: - description: | - Select one of the transactions type supported - 0: Asynchronous mode 1 SRAM/FRAM. - 1: Asynchronous mode 1 PSRAM. - 2: Asynchronous mode A SRAM/FRAM. - 3: Asynchronous mode A PSRAM. - 4: Asynchronous mode 2 NOR. - 5: Asynchronous mode B NOR. - 6: Asynchronous mode C NOR. - 7: Asynchronous mode D NOR. - 8: Synchronous read synchronous write PSRAM. - 9: Synchronous read asynchronous write PSRAM. - 10: Synchronous read synchronous write NOR. - 11: Synchronous read asynchronous write NOR. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 0 - maximum: 11 - - st,fmc2-ebi-cs-cclk-enable: - description: Continuous clock enable (first bank must be configured - in synchronous mode). The FMC_CLK is generated continuously - during asynchronous and synchronous access. By default, the - FMC_CLK is only generated during synchronous access. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-mux-enable: - description: Address/Data multiplexed on databus (valid only with - NOR and PSRAM transactions type). By default, Address/Data - are not multiplexed. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-buswidth: - description: Data bus width - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [ 8, 16 ] - default: 16 - - st,fmc2-ebi-cs-waitpol-high: - description: Wait signal polarity (NWAIT signal active high). - By default, NWAIT is active low. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-waitcfg-enable: - description: The NWAIT signal indicates wheither the data from the - device are valid or if a wait state must be inserted when accessing - the device in synchronous mode. By default, the NWAIT signal is - active one data cycle before wait state. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-wait-enable: - description: The NWAIT signal is enabled (its level is taken into - account after the programmed latency period to insert wait states - if asserted). By default, the NWAIT signal is disabled. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-asyncwait-enable: - description: The NWAIT signal is taken into account during asynchronous - transactions. By default, the NWAIT signal is not taken into account - during asynchronous transactions. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-cpsize: - description: CRAM page size. The controller splits the burst access - when the memory page is reached. By default, no burst split when - crossing page boundary. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [ 0, 128, 256, 512, 1024 ] - default: 0 - - st,fmc2-ebi-cs-byte-lane-setup-ns: - description: This property configures the byte lane setup timing - defined in nanoseconds from NBLx low to Chip Select NEx low. - - st,fmc2-ebi-cs-address-setup-ns: - description: This property defines the duration of the address setup - phase in nanoseconds used for asynchronous read/write transactions. - - st,fmc2-ebi-cs-address-hold-ns: - description: This property defines the duration of the address hold - phase in nanoseconds used for asynchronous multiplexed read/write - transactions. - - st,fmc2-ebi-cs-data-setup-ns: - description: This property defines the duration of the data setup phase - in nanoseconds used for asynchronous read/write transactions. - - st,fmc2-ebi-cs-bus-turnaround-ns: - description: This property defines the delay in nanoseconds between the - end of current read/write transaction and the next transaction. - - st,fmc2-ebi-cs-data-hold-ns: - description: This property defines the duration of the data hold phase - in nanoseconds used for asynchronous read/write transactions. - - st,fmc2-ebi-cs-clk-period-ns: - description: This property defines the FMC_CLK output signal period in - nanoseconds. - - st,fmc2-ebi-cs-data-latency-ns: - description: This property defines the data latency before reading or - writing the first data in nanoseconds. - - st,fmc2-ebi-cs-write-address-setup-ns: - description: This property defines the duration of the address setup - phase in nanoseconds used for asynchronous write transactions. - - st,fmc2-ebi-cs-write-address-hold-ns: - description: This property defines the duration of the address hold - phase in nanoseconds used for asynchronous multiplexed write - transactions. - - st,fmc2-ebi-cs-write-data-setup-ns: - description: This property defines the duration of the data setup - phase in nanoseconds used for asynchronous write transactions. - - st,fmc2-ebi-cs-write-bus-turnaround-ns: - description: This property defines the delay between the end of current - write transaction and the next transaction in nanoseconds. - - st,fmc2-ebi-cs-write-data-hold-ns: - description: This property defines the duration of the data hold phase - in nanoseconds used for asynchronous write transactions. - - st,fmc2-ebi-cs-max-low-pulse-ns: - description: This property defines the maximum chip select low pulse - duration in nanoseconds for synchronous transactions. When this timing - reaches 0, the controller splits the current access, toggles NE to - allow device refresh and restarts a new access. - - required: - - reg - required: - "#address-cells" - "#size-cells" diff --git a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml index 5aa7cf2eacb1a..b44d83554ef57 100644 --- a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml +++ b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml @@ -44,6 +44,7 @@ required: allOf: - $ref: ethernet-controller.yaml# + - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# - if: properties: compatible:
Split st,stm32-fmc2-ebi.yaml specific properties into st,stm32-fmc2-ebi-props.yaml , split memory-controller bus peripheral properties into mc-peripheral-props.yaml , reference the st,stm32-fmc2-ebi-props.yaml in mc-peripheral-props.yaml and reference the mc-peripheral-props.yaml in micrel,ks8851.yaml . This way, the FMC2 controller properties in Micrel KSZ8851MLL ethernet controller node can be properly validated. Fixes the following warning: " arch/arm/boot/dts/stm32mp153c-dhcor-drc-compact.dtb: ethernet@1,0: Unevaluated properties are not allowed ('bank-width', 'st,fmc2-ebi-cs-mux-enable', 'st,fmc2-ebi-cs-transaction-type', 'st,fmc2-ebi-cs-buswidth', 'st,fmc2-ebi-cs-address-setup-ns', 'st,fmc2-ebi-cs-address-hold-ns', 'st,fmc2-ebi-cs-bus-turnaround-ns', 'st,fmc2-ebi-cs-data-setup-ns', 'st,fmc2-ebi-cs-data-hold-ns', 'st,fmc2-ebi-cs-write-address-setup-ns', 'st,fmc2-ebi-cs-write-address-hold-ns', 'st,fmc2-ebi-cs-write-bus-turnaround-ns', 'st,fmc2-ebi-cs-write-data-setup-ns', 'st,fmc2-ebi-cs-write-data-hold-ns' were unexpected) " Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Marek Vasut <marex@denx.de> --- Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Christophe Kerello <christophe.kerello@foss.st.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org --- V2: - Depends on bugfix [PATCH] dt-bindings: memory-controller: st,stm32: Fix st,fmc2_ebi-cs-write-address-setup-ns - Replace MC controllers with Memory Controllers - Add type uint32 and enum 1,2,4 to bank-width prop - Add RB from Rob --- .../mc-peripheral-props.yaml | 38 +++++ .../st,stm32-fmc2-ebi-props.yaml | 144 ++++++++++++++++++ .../memory-controllers/st,stm32-fmc2-ebi.yaml | 137 ----------------- .../bindings/net/micrel,ks8851.yaml | 1 + 4 files changed, 183 insertions(+), 137 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml create mode 100644 Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml