| Message ID | 20181005165848.3474-1-robh@kernel.org |
|---|---|
| Headers | show |
| Series | Devicetree schema | expand |
Hello, On 05/10/2018 11:58:31-0500, Rob Herring wrote: > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > new file mode 100644 > index 000000000000..f788315b94fa > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > @@ -0,0 +1,132 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/atmel-at91.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Atmel AT91 device tree bindings. > + > +maintainers: > + - Alexandre Belloni <alexandre.belloni@free-electrons.com> > + - Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Jean-Christophe has not been active for years, I'd mention Ludovic instead. > +description: | > + Boards with a SoC of the Atmel AT91 or SMART family shall have the following > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - items: > + - const: atmel,at91rm9200 > + - items: > + - enum: > + - olimex,sam9-l9260 > + - enum: > + - atmel,at91sam9260 > + - atmel,at91sam9261 > + - atmel,at91sam9263 > + - atmel,at91sam9g20 > + - atmel,at91sam9g45 > + - atmel,at91sam9n12 > + - atmel,at91sam9rl > + - atmel,at91sam9xe > + - const: atmel,at91sam9 > + > + - items: > + - enum: > + - atmel,at91sam9g15 > + - atmel,at91sam9g25 > + - atmel,at91sam9g35 > + - atmel,at91sam9x25 > + - atmel,at91sam9x35 > + - const: atmel,at91sam9x5 > + - const: atmel,at91sam9 > + > + - items: > + - const: atmel,sama5d27 > + - const: atmel,sama5d2 > + - const: atmel,sama5 > + > + - description: Nattis v2 board with Natte v2 power board > + items: > + - const: axentia,nattis-2 > + - const: axentia,natte-2 > + - const: axentia,linea Shouldn't we have the board specific compatibles in a separate file to avoid mixing everything with the SoC compatibles?
On Fri, Oct 5, 2018 at 1:07 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > Hello, > > On 05/10/2018 11:58:31-0500, Rob Herring wrote: > > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > > new file mode 100644 > > index 000000000000..f788315b94fa > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > > @@ -0,0 +1,132 @@ > > +# SPDX-License-Identifier: None > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/bindings/arm/atmel-at91.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Atmel AT91 device tree bindings. > > + > > +maintainers: > > + - Alexandre Belloni <alexandre.belloni@free-electrons.com> > > + - Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> > > Jean-Christophe has not been active for years, I'd mention Ludovic > instead. Will update. I generated these out of git log. I didn't use get_maintainers.pl because it seems lots of files don't have maintainers listed (other than Mark and me) and I didn't want to be it. > > > +description: | > > + Boards with a SoC of the Atmel AT91 or SMART family shall have the following > > + > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - items: > > + - const: atmel,at91rm9200 > > + - items: > > + - enum: > > + - olimex,sam9-l9260 > > + - enum: > > + - atmel,at91sam9260 > > + - atmel,at91sam9261 > > + - atmel,at91sam9263 > > + - atmel,at91sam9g20 > > + - atmel,at91sam9g45 > > + - atmel,at91sam9n12 > > + - atmel,at91sam9rl > > + - atmel,at91sam9xe > > + - const: atmel,at91sam9 > > + > > + - items: > > + - enum: > > + - atmel,at91sam9g15 > > + - atmel,at91sam9g25 > > + - atmel,at91sam9g35 > > + - atmel,at91sam9x25 > > + - atmel,at91sam9x35 > > + - const: atmel,at91sam9x5 > > + - const: atmel,at91sam9 > > + > > + - items: > > + - const: atmel,sama5d27 > > + - const: atmel,sama5d2 > > + - const: atmel,sama5 > > + > > + - description: Nattis v2 board with Natte v2 power board > > + items: > > + - const: axentia,nattis-2 > > + - const: axentia,natte-2 > > + - const: axentia,linea > > Shouldn't we have the board specific compatibles in a separate file to > avoid mixing everything with the SoC compatibles? You can't validate it that way. I have to say "must be compatible A, B, C and in that order" and you can't if A, B, and C are in different files. We could do board vendor files, but then we have to duplicate the SoC compatibles. I don't think there's any board vendor with enough boards to justify that. The only place I've found that the compatible lists get kind of messy is when platforms have a variable number of compatible strings. We generally have not split things this way for most platforms except i.MX which this series changes. Looks like I forgot to remove the axentia.txt for Atmel. Rob
Hi Rob On Fri, 2018-10-05 at 11:58 -0500, Rob Herring wrote: > Convert Tegra SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Thierry Reding <thierry.reding@gmail.com> > Cc: Jonathan Hunter <jonathanh@nvidia.com> > Cc: devicetree@vger.kernel.org > Cc: linux-tegra@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/tegra.txt | 60 ------------- > .../devicetree/bindings/arm/tegra.yaml | 88 > +++++++++++++++++++ > 2 files changed, 88 insertions(+), 60 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt > create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml > > diff --git a/Documentation/devicetree/bindings/arm/tegra.txt > b/Documentation/devicetree/bindings/arm/tegra.txt > deleted file mode 100644 > index 32f62bb7006d..000000000000 > --- a/Documentation/devicetree/bindings/arm/tegra.txt > +++ /dev/null > @@ -1,60 +0,0 @@ > -NVIDIA Tegra device tree bindings > -------------------------------------------- > - > -SoCs > -------------------------------------------- > - > -Each device tree must specify which Tegra SoC it uses, using one of > the > -following compatible values: > - > - nvidia,tegra20 > - nvidia,tegra30 > - nvidia,tegra114 > - nvidia,tegra124 > - nvidia,tegra132 > - nvidia,tegra210 > - nvidia,tegra186 > - nvidia,tegra194 > - > -Boards > -------------------------------------------- > - > -Each device tree must specify which one or more of the following > -board-specific compatible values: > - > - ad,medcom-wide > - ad,plutux > - ad,tamonten > - ad,tec > - compal,paz00 > - compulab,trimslice > - nvidia,beaver > - nvidia,cardhu > - nvidia,cardhu-a02 > - nvidia,cardhu-a04 > - nvidia,dalmore > - nvidia,harmony > - nvidia,jetson-tk1 > - nvidia,norrin > - nvidia,p2371-0000 > - nvidia,p2371-2180 > - nvidia,p2571 > - nvidia,p2771-0000 > - nvidia,p2972-0000 > - nvidia,roth > - nvidia,seaboard > - nvidia,tn7 > - nvidia,ventana > - toradex,apalis_t30 > - toradex,apalis_t30-eval > - toradex,apalis-tk1 > - toradex,apalis-tk1-eval > - toradex,colibri_t20-512 > - toradex,colibri_t30 > - toradex,colibri_t30-eval-v3 > - toradex,iris Are you aware that -next already features a few updating commits thereof from around the beginning of September one of which even bears your reviewed-by. > - > -Trusted Foundations > -------------------------------------------- > -Tegra supports the Trusted Foundation secure monitor. See the > -"tlm,trusted-foundations" binding's documentation for more details. > diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml > b/Documentation/devicetree/bindings/arm/tegra.yaml > new file mode 100644 > index 000000000000..9cebcfaaad1e > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/tegra.yaml > @@ -0,0 +1,88 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/tegra.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: NVIDIA Tegra device tree bindings > + > +maintainers: > + - Marcel Ziswiler <marcel.ziswiler@toradex.com> Wow, seems I got promoted to maintainer now. I guess that may make sense at least for the Toradex based boards. > + - Peter De Schrijver <pdeschrijver@nvidia.com> > + > +properties: > + compatible: > + oneOf: > + - items: > + - enum: > + - compal,paz00 > + - compulab,trimslice > + - nvidia,harmony > + - nvidia,seaboard > + - nvidia,ventana > + - const: nvidia,tegra20 > + - items: > + - enum: > + - ad,medcom-wide > + - ad,plutux > + - ad,tec > + - const: ad,tamonten > + - const: nvidia,tegra20 > + - items: > + - const: toradex,iris > + - const: toradex,colibri_t20-512 > + - const: nvidia,tegra20 > + - items: > + - enum: > + - nvidia,beaver > + - const: nvidia,tegra30 > + - items: > + - enum: > + - nvidia,cardhu-a02 > + - nvidia,cardhu-a04 > + - const: nvidia,cardhu > + - const: nvidia,tegra30 > + - items: > + - enum: > + - toradex,apalis_t30-eval > + - const: toradex,apalis_t30 > + - const: nvidia,tegra30 > + - items: > + - enum: > + - toradex,colibri_t30-eval-v3 > + - const: toradex,colibri_t30 > + - const: nvidia,tegra30 > + - items: > + - enum: > + - nvidia,dalmore > + - nvidia,roth > + - nvidia,tn7 > + - const: nvidia,tegra114 > + - items: > + - enum: > + - nvidia,jetson-tk1 > + - nvidia,venice2 > + - const: nvidia,tegra124 > + - items: > + - const: toradex,apalis-tk1-eval > + - const: toradex,apalis-tk1 > + - const: nvidia,tegra124 > + - items: > + - enum: > + - nvidia,norrin > + - const: nvidia,tegra132 > + - const: nvidia,tegra124 > + - items: > + - enum: > + - nvidia,p2371-0000 > + - nvidia,p2371-2180 > + - nvidia,p2571 > + - const: nvidia,tegra210 > + - items: > + - enum: > + - nvidia,p2771-0000 > + - const: nvidia,tegra186 > + - items: > + - enum: > + - nvidia,p2972-0000 > + - const: nvidia,tegra194 Other than that I'm all in to move towards more structured bindings documentation. Cheers Marcel
On Fri, Oct 5, 2018 at 5:20 PM Marcel Ziswiler <marcel.ziswiler@toradex.com> wrote: > > Hi Rob > > On Fri, 2018-10-05 at 11:58 -0500, Rob Herring wrote: > > Convert Tegra SoC bindings to DT schema format using json-schema. > > [...] > Are you aware that -next already features a few updating commits > thereof from around the beginning of September one of which even bears > your reviewed-by. I'm not targeting 4.20, but rather early in the 4.21 cycle. So I'll be rebasing on rc1 and will update with any changes. I've been doing that a couple of cycles already. Rob
On Fri, Oct 05, 2018 at 11:58:16AM -0500, Rob Herring wrote: > In preparation to convert board-level bindings to json-schema, move > various misc SoC bindings out to their own file. > > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Shawn Guo <shawnguo@kernel.org>
On Fri, Oct 05, 2018 at 11:58:18AM -0500, Rob Herring wrote: > In preparation to convert board-level bindings to json-schema, move > various misc SoC bindings out to their own file. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Jun Nie <jun.nie@linaro.org> > Cc: Baoyou Xie <baoyou.xie@linaro.org> > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/zte-sysctrl.txt | 30 +++++++++++++++++++ zte,sysctrl.txt to be consistent with other files like fsl,layerscape-dcfg.txt? I'm fine with either way, but just want to see more consistent naming convention? Other than that, Acked-by: Shawn Guo <shawnguo@kernel.org>
On Fri, Oct 05, 2018 at 11:58:34AM -0500, Rob Herring wrote: > Convert Freescale SoC bindings to DT schema format using json-schema. > > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/armadeus.txt | 6 - > Documentation/devicetree/bindings/arm/bhf.txt | 6 - > .../bindings/arm/compulab-boards.txt | 25 --- > Documentation/devicetree/bindings/arm/fsl.txt | 185 ------------------ > .../devicetree/bindings/arm/fsl.yaml | 166 ++++++++++++++++ > .../devicetree/bindings/arm/i2se.txt | 22 --- > .../devicetree/bindings/arm/olimex.txt | 10 - > .../devicetree/bindings/arm/technologic.txt | 23 --- > 8 files changed, 166 insertions(+), 277 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/armadeus.txt > delete mode 100644 Documentation/devicetree/bindings/arm/bhf.txt > delete mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt > delete mode 100644 Documentation/devicetree/bindings/arm/fsl.txt > create mode 100644 Documentation/devicetree/bindings/arm/fsl.yaml > delete mode 100644 Documentation/devicetree/bindings/arm/i2se.txt > delete mode 100644 Documentation/devicetree/bindings/arm/olimex.txt > delete mode 100644 Documentation/devicetree/bindings/arm/technologic.txt > > diff --git a/Documentation/devicetree/bindings/arm/armadeus.txt b/Documentation/devicetree/bindings/arm/armadeus.txt > deleted file mode 100644 > index 9821283ff516..000000000000 > --- a/Documentation/devicetree/bindings/arm/armadeus.txt > +++ /dev/null > @@ -1,6 +0,0 @@ > -Armadeus i.MX Platforms Device Tree Bindings > ------------------------------------------------ > - > -APF51: i.MX51 based module. > -Required root node properties: > - - compatible = "armadeus,imx51-apf51", "fsl,imx51"; > diff --git a/Documentation/devicetree/bindings/arm/bhf.txt b/Documentation/devicetree/bindings/arm/bhf.txt > deleted file mode 100644 > index 886b503caf9c..000000000000 > --- a/Documentation/devicetree/bindings/arm/bhf.txt > +++ /dev/null > @@ -1,6 +0,0 @@ > -Beckhoff Automation Platforms Device Tree Bindings > --------------------------------------------------- > - > -CX9020 Embedded PC > -Required root node properties: > - - compatible = "bhf,cx9020", "fsl,imx53"; > diff --git a/Documentation/devicetree/bindings/arm/compulab-boards.txt b/Documentation/devicetree/bindings/arm/compulab-boards.txt > deleted file mode 100644 > index 42a10285af9c..000000000000 > --- a/Documentation/devicetree/bindings/arm/compulab-boards.txt > +++ /dev/null > @@ -1,25 +0,0 @@ > -CompuLab SB-SOM is a multi-module baseboard capable of carrying: > - - CM-T43 > - - CM-T54 > - - CM-QS600 > - - CL-SOM-AM57x > - - CL-SOM-iMX7 > -modules with minor modifications to the SB-SOM assembly. > - > -Required root node properties: > - - compatible = should be "compulab,sb-som" > - > -Compulab CL-SOM-iMX7 is a miniature System-on-Module (SoM) based on > -Freescale i.MX7 ARM Cortex-A7 System-on-Chip. > - > -Required root node properties: > - - compatible = "compulab,cl-som-imx7", "fsl,imx7d"; > - > -Compulab SBC-iMX7 is a single board computer based on the > -Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with > -the CL-SOM-iMX7 System-on-Module providing most of the functions, > -and SB-SOM-iMX7 carrier board providing additional peripheral > -functions and connectors. > - > -Required root node properties: > - - compatible = "compulab,sbc-imx7", "compulab,cl-som-imx7", "fsl,imx7d"; > diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt > deleted file mode 100644 > index 1e775aaa5c5b..000000000000 > --- a/Documentation/devicetree/bindings/arm/fsl.txt > +++ /dev/null > @@ -1,185 +0,0 @@ > -Freescale i.MX Platforms Device Tree Bindings > ------------------------------------------------ > - > -i.MX23 Evaluation Kit > -Required root node properties: > - - compatible = "fsl,imx23-evk", "fsl,imx23"; > - > -i.MX25 Product Development Kit > -Required root node properties: > - - compatible = "fsl,imx25-pdk", "fsl,imx25"; > - > -i.MX27 Product Development Kit > -Required root node properties: > - - compatible = "fsl,imx27-pdk", "fsl,imx27"; > - > -i.MX28 Evaluation Kit > -Required root node properties: > - - compatible = "fsl,imx28-evk", "fsl,imx28"; > - > -i.MX51 Babbage Board > -Required root node properties: > - - compatible = "fsl,imx51-babbage", "fsl,imx51"; > - > -i.MX53 Automotive Reference Design Board > -Required root node properties: > - - compatible = "fsl,imx53-ard", "fsl,imx53"; > - > -i.MX53 Evaluation Kit > -Required root node properties: > - - compatible = "fsl,imx53-evk", "fsl,imx53"; > - > -i.MX53 Quick Start Board > -Required root node properties: > - - compatible = "fsl,imx53-qsb", "fsl,imx53"; > - > -i.MX53 Smart Mobile Reference Design Board > -Required root node properties: > - - compatible = "fsl,imx53-smd", "fsl,imx53"; > - > -i.MX6 Quad Armadillo2 Board > -Required root node properties: > - - compatible = "fsl,imx6q-arm2", "fsl,imx6q"; > - > -i.MX6 Quad SABRE Lite Board > -Required root node properties: > - - compatible = "fsl,imx6q-sabrelite", "fsl,imx6q"; > - > -i.MX6 Quad SABRE Smart Device Board > -Required root node properties: > - - compatible = "fsl,imx6q-sabresd", "fsl,imx6q"; > - > -i.MX6 Quad SABRE Automotive Board > -Required root node properties: > - - compatible = "fsl,imx6q-sabreauto", "fsl,imx6q"; > - > -i.MX6SLL EVK board > -Required root node properties: > - - compatible = "fsl,imx6sll-evk", "fsl,imx6sll"; > - > -Generic i.MX boards > -------------------- > - > -No iomux setup is done for these boards, so this must have been configured > -by the bootloader for boards to work with the generic bindings. > - > -i.MX27 generic board > -Required root node properties: > - - compatible = "fsl,imx27"; > - > -i.MX51 generic board > -Required root node properties: > - - compatible = "fsl,imx51"; > - > -i.MX53 generic board > -Required root node properties: > - - compatible = "fsl,imx53"; > - > -i.MX6q generic board > -Required root node properties: > - - compatible = "fsl,imx6q"; > - > -Freescale Vybrid Platform Device Tree Bindings > ----------------------------------------------- > - > -For the Vybrid SoC familiy all variants with DDR controller are supported, > -which is the VF5xx and VF6xx series. Out of historical reasons, in most > -places the kernel uses vf610 to refer to the whole familiy. > -The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4 > -core support. > - > -Required root node compatible property (one of them): > - - compatible = "fsl,vf500"; > - - compatible = "fsl,vf510"; > - - compatible = "fsl,vf600"; > - - compatible = "fsl,vf610"; > - - compatible = "fsl,vf610m4"; > - > -Freescale LS1021A Platform Device Tree Bindings > ------------------------------------------------- > - > -Required root node compatible properties: > - - compatible = "fsl,ls1021a"; > - > -Freescale ARMv8 based Layerscape SoC family Device Tree Bindings > ----------------------------------------------------------------- > - > -LS1012A SoC > -Required root node properties: > - - compatible = "fsl,ls1012a"; > - > -LS1012A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls1012a-rdb", "fsl,ls1012a"; > - > -LS1012A ARMv8 based FRDM Board > -Required root node properties: > - - compatible = "fsl,ls1012a-frdm", "fsl,ls1012a"; > - > -LS1012A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls1012a-qds", "fsl,ls1012a"; > - > -LS1043A SoC > -Required root node properties: > - - compatible = "fsl,ls1043a"; > - > -LS1043A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls1043a-rdb", "fsl,ls1043a"; > - > -LS1043A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls1043a-qds", "fsl,ls1043a"; > - > -LS1046A SoC > -Required root node properties: > - - compatible = "fsl,ls1046a"; > - > -LS1046A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls1046a-qds", "fsl,ls1046a"; > - > -LS1046A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls1046a-rdb", "fsl,ls1046a"; > - > -LS1088A SoC > -Required root node properties: > - - compatible = "fsl,ls1088a"; > - > -LS1088A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls1088a-qds", "fsl,ls1088a"; > - > -LS1088A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls1088a-rdb", "fsl,ls1088a"; > - > -LS2080A SoC > -Required root node properties: > - - compatible = "fsl,ls2080a"; > - > -LS2080A ARMv8 based Simulator model > -Required root node properties: > - - compatible = "fsl,ls2080a-simu", "fsl,ls2080a"; > - > -LS2080A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls2080a-qds", "fsl,ls2080a"; > - > -LS2080A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls2080a-rdb", "fsl,ls2080a"; > - > -LS2088A SoC > -Required root node properties: > - - compatible = "fsl,ls2088a"; > - > -LS2088A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls2088a-qds", "fsl,ls2088a"; > - > -LS2088A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls2088a-rdb", "fsl,ls2088a"; > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml > new file mode 100644 > index 000000000000..5241fa92e3d1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > @@ -0,0 +1,166 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/fsl.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Freescale i.MX Platforms Device Tree Bindings > + > +maintainers: > + - Shawn Guo <shawn.guo@freescale.com> The email address has been unavailable for long time. Please use Shawn Guo <shawnguo@kernel.org>. > + - Shaohui Xie <Shaohui.Xie@nxp.com> Li Yang <leoyang.li@nxp.com> is the co-maintainer for Layerscape. > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - description: i.MX23 based Boards > + items: > + - enum: > + - fsl,imx23-evk > + - olimex,imx23-olinuxino > + - const: fsl,imx23 > + > + - description: i.MX25 Product Development Kit > + items: > + - enum: > + - fsl,imx25-pdk > + - const: fsl,imx25 > + > + - description: i.MX27 Product Development Kit > + items: > + - enum: > + - fsl,imx27-pdk > + - const: fsl,imx27 > + > + - description: i.MX28 based Boards > + items: > + - enum: > + - fsl,imx28-evk > + - i2se,duckbill > + - i2se,duckbill-2 > + - technologic,imx28-ts4600 > + - const: fsl,imx28 > + - items: The schema is new to me. This line looks unusual to me, so you may want to double check. > + - enum: > + - i2se,duckbill-2-485 > + - i2se,duckbill-2-enocean > + - i2se,duckbill-2-spi > + - const: i2se,duckbill-2 > + - const: fsl,imx28 > + > + - description: i.MX51 Babbage Board i.MX51 based Boards > + items: > + - enum: > + - armadeus,imx51-apf51 > + - fsl,imx51-babbage > + - technologic,imx51-ts4800 > + - const: fsl,imx51 > + > + - description: i.MX53 Boards i.MX53 based Boards Shawn > + items: > + - enum: > + - bhf,cx9020 > + - fsl,imx53-ard > + - fsl,imx53-evk > + - fsl,imx53-qsb > + - fsl,imx53-smd > + - const: fsl,imx53 > + > + - description: i.MX6Q based Boards > + items: > + - enum: > + - fsl,imx6q-arm2 > + - fsl,imx6q-sabrelite > + - fsl,imx6q-sabresd > + - fsl,imx6q-sabreauto > + - technologic,imx6q-ts4900 > + - technologic,imx6q-ts7970 > + - const: fsl,imx6q > + > + - description: i.MX6DL based Boards > + items: > + - enum: > + - technologic,imx6dl-ts4900 > + - technologic,imx6dl-ts7970 > + - const: fsl,imx6dl > + > + - description: i.MX6SLL based Boards > + items: > + - enum: > + - fsl,imx6sll-evk > + - const: fsl,imx6sll > + > + - description: > + Compulab SBC-iMX7 is a single board computer based on the > + Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with > + the CL-SOM-iMX7 System-on-Module providing most of the functions, > + and SB-SOM-iMX7 carrier board providing additional peripheral > + functions and connectors. > + items: > + - const: compulab,sbc-imx7 > + - const: compulab,cl-som-imx7 > + - const: fsl,imx7d > + > + - description: > + Freescale Vybrid Platform Device Tree Bindings > + > + For the Vybrid SoC familiy all variants with DDR controller are supported, > + which is the VF5xx and VF6xx series. Out of historical reasons, in most > + places the kernel uses vf610 to refer to the whole familiy. > + The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4 > + core support. > + items: > + - enum: > + - fsl,vf500 > + - fsl,vf510 > + - fsl,vf600 > + - fsl,vf610 > + - fsl,vf610m4 > + > + - description: LS1021A based Boards > + items: > + - enum: > + - fsl,ls1012a-rdb > + - fsl,ls1012a-frdm > + - fsl,ls1012a-qds > + - const: fsl,ls1021a > + > + - description: LS1043A based Boards > + items: > + - enum: > + - fsl,ls1043a-rdb > + - fsl,ls1043a-qds > + - const: fsl,ls1043a > + > + - description: LS1046A based Boards > + items: > + - enum: > + - fsl,ls1046a-qds > + - fsl,ls1046a-rdb > + - const: fsl,ls1046a > + > + - description: LS1088A based Boards > + items: > + - enum: > + - fsl,ls1088a-qds > + - fsl,ls1088a-rdb > + - const: fsl,ls1088a > + > + - description: LS2080A based Boards > + items: > + - enum: > + - fsl,ls2080a-simu > + - fsl,ls2080a-qds > + - fsl,ls2080a-rdb > + - const: fsl,ls2080a > + > + - description: LS2088A based Boards > + items: > + - enum: > + - fsl,ls2088a-qds > + - fsl,ls2088a-rdb > + - const: fsl,ls2088a > + > +... > diff --git a/Documentation/devicetree/bindings/arm/i2se.txt b/Documentation/devicetree/bindings/arm/i2se.txt > deleted file mode 100644 > index dbd54a3aa07d..000000000000 > --- a/Documentation/devicetree/bindings/arm/i2se.txt > +++ /dev/null > @@ -1,22 +0,0 @@ > -I2SE Device Tree Bindings > -------------------------- > - > -Duckbill Board > -Required root node properties: > - - compatible = "i2se,duckbill", "fsl,imx28"; > - > -Duckbill 2 Board > -Required root node properties: > - - compatible = "i2se,duckbill-2", "fsl,imx28"; > - > -Duckbill 2 485 Board > -Required root node properties: > - - compatible = "i2se,duckbill-2-485", "i2se,duckbill-2", "fsl,imx28"; > - > -Duckbill 2 EnOcean Board > -Required root node properties: > - - compatible = "i2se,duckbill-2-enocean", "i2se,duckbill-2", "fsl,imx28"; > - > -Duckbill 2 SPI Board > -Required root node properties: > - - compatible = "i2se,duckbill-2-spi", "i2se,duckbill-2", "fsl,imx28"; > diff --git a/Documentation/devicetree/bindings/arm/olimex.txt b/Documentation/devicetree/bindings/arm/olimex.txt > deleted file mode 100644 > index d726aeca56be..000000000000 > --- a/Documentation/devicetree/bindings/arm/olimex.txt > +++ /dev/null > @@ -1,10 +0,0 @@ > -Olimex Device Tree Bindings > ---------------------------- > - > -SAM9-L9260 Board > -Required root node properties: > - - compatible = "olimex,sam9-l9260", "atmel,at91sam9260"; > - > -i.MX23 Olinuxino Low Cost Board > -Required root node properties: > - - compatible = "olimex,imx23-olinuxino", "fsl,imx23"; > diff --git a/Documentation/devicetree/bindings/arm/technologic.txt b/Documentation/devicetree/bindings/arm/technologic.txt > deleted file mode 100644 > index f1cedc00dcab..000000000000 > --- a/Documentation/devicetree/bindings/arm/technologic.txt > +++ /dev/null > @@ -1,23 +0,0 @@ > -Technologic Systems Platforms Device Tree Bindings > --------------------------------------------------- > - > -TS-4600 is a System-on-Module based on the Freescale i.MX28 System-on-Chip. > -It can be mounted on a carrier board providing additional peripheral connectors. > -Required root node properties: > - - compatible = "technologic,imx28-ts4600", "fsl,imx28" > - > -TS-4800 board > -Required root node properties: > - - compatible = "technologic,imx51-ts4800", "fsl,imx51"; > - > -TS-4900 is a System-on-Module based on the Freescale i.MX6 System-on-Chip. > -It can be mounted on a carrier board providing additional peripheral connectors. > -Required root node properties: > - - compatible = "technologic,imx6dl-ts4900", "fsl,imx6dl" > - - compatible = "technologic,imx6q-ts4900", "fsl,imx6q" > - > -TS-7970 is a System-on-Module based on the Freescale i.MX6 System-on-Chip. > -It can be mounted on a carrier board providing additional peripheral connectors. > -Required root node properties: > - - compatible = "technologic,imx6dl-ts7970", "fsl,imx6dl" > - - compatible = "technologic,imx6q-ts7970", "fsl,imx6q" > -- > 2.17.1 >
Hi Rob, On Fri, Oct 5, 2018 at 6:58 PM Rob Herring <robh@kernel.org> wrote: > In preparation to convert board-level bindings to json-schema, move > various misc SoC bindings out to their own file. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Simon Horman <horms@verge.net.au> > Cc: Magnus Damm <magnus.damm@gmail.com> > Cc: devicetree@vger.kernel.org > Cc: linux-renesas-soc@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Looks good to me, but needs a rebase, as the PRR section has been extended in -next. Gr{oetje,eeting}s, Geert
On Fri, Oct 05, 2018 at 11:58:48AM -0500, Rob Herring wrote: > Convert ZTE SoC bindings to DT schema format using json-schema. > > Cc: Jun Nie <jun.nie@linaro.org> > Cc: Baoyou Xie <baoyou.xie@linaro.org> > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-arm-kernel@lists.infradead.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Shawn Guo <shawnguo@kernel.org>
Hi Rob, On Fri, Oct 5, 2018 at 6:59 PM Rob Herring <robh@kernel.org> wrote: > Convert Renesas SoC bindings to DT schema format using json-schema. > > Cc: Simon Horman <horms@verge.net.au> > Cc: Magnus Damm <magnus.damm@gmail.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-renesas-soc@vger.kernel.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Thanks for your patch! Note that this will need a rebase, as more SoCs/boards have been added in -next. > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > @@ -0,0 +1,205 @@ > +# SPDX-License-Identifier: None The old file didn't have an SPDX header, so it was GPL-2.0, implicitly? > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/shmobile.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > + > +maintainers: > + - Geert Uytterhoeven <geert+renesas@glider.be> Simon Horman <horms@verge.net.au> (supporter:ARM/SHMOBILE ARM ARCHITECTURE) Magnus Damm <magnus.damm@gmail.com> (supporter:ARM/SHMOBILE ARM ARCHITECTURE) You had it right in the CC list, though... > + - description: RZ/G1M (R8A77430) > + items: > + - enum: > + # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) > + - iwave,g20d > + - const: iwave,g20m > + - const: renesas,r8a7743 > + > + - items: > + - enum: > + # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) > + - iwave,g20m > + - const: renesas,r8a7743 > + > + - description: RZ/G1N (R8A77440) > + items: > + - enum: > + - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE) This board belongs under the RZ/G1M section above (see also the 7743 in the part number). > + - const: renesas,r8a7744 > + - description: Kingfisher (SBEV-RCAR-KF-M03) > + items: > + - const: shimafuji,kingfisher > + - enum: > + - renesas,h3ulcb > + - renesas,m3ulcb > + - enum: > + - renesas,r8a7795 > + - renesas,r8a7796 This looks a bit funny: all other entries have the "const" last, and use it for the SoC number. May be correct, though. To clarify, this is an extension board that can fit both the [HM]3ULCB boards (actually also the new M3NULCB, I think). Gr{oetje,eeting}s, Geert
On Fri, Oct 05, 2018 at 11:58:41AM -0500, Rob Herring wrote: > Convert Renesas SoC bindings to DT schema format using json-schema. > > Cc: Simon Horman <horms@verge.net.au> > Cc: Magnus Damm <magnus.damm@gmail.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-renesas-soc@vger.kernel.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> This seems fine to me other than that it does not seem to apply cleanly to next. shmobile.txt sees a couple of updates per release cycle so from my point of view it would ideal if this change could hit -rc1 to allow patches for v4.21 to be accepted smoothly (already one from Sergei will need rebasing). > --- > .../devicetree/bindings/arm/shmobile.txt | 143 ------------ > .../devicetree/bindings/arm/shmobile.yaml | 205 ++++++++++++++++++ > 2 files changed, 205 insertions(+), 143 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt > create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml > > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt > deleted file mode 100644 > index 619b765e5bee..000000000000 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ /dev/null > @@ -1,143 +0,0 @@ > -Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > --------------------------------------------------------------------- > - > -SoCs: > - > - - Emma Mobile EV2 > - compatible = "renesas,emev2" > - - RZ/A1H (R7S72100) > - compatible = "renesas,r7s72100" > - - SH-Mobile AG5 (R8A73A00/SH73A0) > - compatible = "renesas,sh73a0" > - - R-Mobile APE6 (R8A73A40) > - compatible = "renesas,r8a73a4" > - - R-Mobile A1 (R8A77400) > - compatible = "renesas,r8a7740" > - - RZ/G1H (R8A77420) > - compatible = "renesas,r8a7742" > - - RZ/G1M (R8A77430) > - compatible = "renesas,r8a7743" > - - RZ/G1N (R8A77440) > - compatible = "renesas,r8a7744" > - - RZ/G1E (R8A77450) > - compatible = "renesas,r8a7745" > - - RZ/G1C (R8A77470) > - compatible = "renesas,r8a77470" > - - R-Car M1A (R8A77781) > - compatible = "renesas,r8a7778" > - - R-Car H1 (R8A77790) > - compatible = "renesas,r8a7779" > - - R-Car H2 (R8A77900) > - compatible = "renesas,r8a7790" > - - R-Car M2-W (R8A77910) > - compatible = "renesas,r8a7791" > - - R-Car V2H (R8A77920) > - compatible = "renesas,r8a7792" > - - R-Car M2-N (R8A77930) > - compatible = "renesas,r8a7793" > - - R-Car E2 (R8A77940) > - compatible = "renesas,r8a7794" > - - R-Car H3 (R8A77950) > - compatible = "renesas,r8a7795" > - - R-Car M3-W (R8A77960) > - compatible = "renesas,r8a7796" > - - R-Car M3-N (R8A77965) > - compatible = "renesas,r8a77965" > - - R-Car V3M (R8A77970) > - compatible = "renesas,r8a77970" > - - R-Car V3H (R8A77980) > - compatible = "renesas,r8a77980" > - - R-Car E3 (R8A77990) > - compatible = "renesas,r8a77990" > - - R-Car D3 (R8A77995) > - compatible = "renesas,r8a77995" > - - RZ/N1D (R9A06G032) > - compatible = "renesas,r9a06g032" > - > -Boards: > - > - - Alt (RTP0RC7794SEB00010S) > - compatible = "renesas,alt", "renesas,r8a7794" > - - APE6-EVM > - compatible = "renesas,ape6evm", "renesas,r8a73a4" > - - Atmark Techno Armadillo-800 EVA > - compatible = "renesas,armadillo800eva", "renesas,r8a7740" > - - Blanche (RTP0RC7792SEB00010S) > - compatible = "renesas,blanche", "renesas,r8a7792" > - - BOCK-W > - compatible = "renesas,bockw", "renesas,r8a7778" > - - Condor (RTP0RC77980SEB0010SS/RTP0RC77980SEB0010SA01) > - compatible = "renesas,condor", "renesas,r8a77980" > - - Draak (RTP0RC77995SEB0010S) > - compatible = "renesas,draak", "renesas,r8a77995" > - - Eagle (RTP0RC77970SEB0010S) > - compatible = "renesas,eagle", "renesas,r8a77970" > - - Ebisu (RTP0RC77990SEB0010S) > - compatible = "renesas,ebisu", "renesas,r8a77990" > - - Genmai (RTK772100BC00000BR) > - compatible = "renesas,genmai", "renesas,r7s72100" > - - GR-Peach (X28A-M01-E/F) > - compatible = "renesas,gr-peach", "renesas,r7s72100" > - - Gose (RTP0RC7793SEB00010S) > - compatible = "renesas,gose", "renesas,r8a7793" > - - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) > - H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) > - compatible = "renesas,h3ulcb", "renesas,r8a7795" > - - Henninger > - compatible = "renesas,henninger", "renesas,r8a7791" > - - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > - compatible = "iwave,g23s", "renesas,r8a77470" > - - iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D) > - compatible = "iwave,g22d", "iwave,g22m", "renesas,r8a7745" > - - iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM) > - compatible = "iwave,g22m", "renesas,r8a7745" > - - iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) > - compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743" > - - iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) > - compatible = "iwave,g20m", "renesas,r8a7743" > - - Kingfisher (SBEV-RCAR-KF-M03) > - compatible = "shimafuji,kingfisher" > - - Koelsch (RTP0RC7791SEB00010S) > - compatible = "renesas,koelsch", "renesas,r8a7791" > - - Kyoto Microcomputer Co. KZM-A9-Dual > - compatible = "renesas,kzm9d", "renesas,emev2" > - - Kyoto Microcomputer Co. KZM-A9-GT > - compatible = "renesas,kzm9g", "renesas,sh73a0" > - - Lager (RTP0RC7790SEB00010S) > - compatible = "renesas,lager", "renesas,r8a7790" > - - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > - compatible = "renesas,m3ulcb", "renesas,r8a7796" > - - Marzen (R0P7779A00010S) > - compatible = "renesas,marzen", "renesas,r8a7779" > - - Porter (M2-LCDP) > - compatible = "renesas,porter", "renesas,r8a7791" > - - RSKRZA1 (YR0K77210C000BE) > - compatible = "renesas,rskrza1", "renesas,r7s72100" > - - RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) > - compatible = "renesas,rzn1d400-db", "renesas,r9a06g032" > - - Salvator-X (RTP0RC7795SIPB0010S) > - compatible = "renesas,salvator-x", "renesas,r8a7795" > - - Salvator-X (RTP0RC7796SIPB0011S) > - compatible = "renesas,salvator-x", "renesas,r8a7796" > - - Salvator-X (RTP0RC7796SIPB0011S (M3-N)) > - compatible = "renesas,salvator-x", "renesas,r8a77965" > - - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S) > - compatible = "renesas,salvator-xs", "renesas,r8a7795" > - - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S) > - compatible = "renesas,salvator-xs", "renesas,r8a7796" > - - Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S) > - compatible = "renesas,salvator-xs", "renesas,r8a77965" > - - SILK (RTP0RC7794LCB00011S) > - compatible = "renesas,silk", "renesas,r8a7794" > - - SK-RZG1E (YR8A77450S000BE) > - compatible = "renesas,sk-rzg1e", "renesas,r8a7745" > - - SK-RZG1M (YR8A77430S000BE) > - compatible = "renesas,sk-rzg1m", "renesas,r8a7743" > - - Stout (ADAS Starterkit, Y-R-CAR-ADAS-SKH2-BOARD) > - compatible = "renesas,stout", "renesas,r8a7790" > - - V3HSK (Y-ASK-RCAR-V3H-WS10) > - compatible = "renesas,v3hsk", "renesas,r8a77980" > - - V3MSK (Y-ASK-RCAR-V3M-WS10) > - compatible = "renesas,v3msk", "renesas,r8a77970" > - - Wheat (RTP0RC7792ASKB0000JE) > - compatible = "renesas,wheat", "renesas,r8a7792" > diff --git a/Documentation/devicetree/bindings/arm/shmobile.yaml b/Documentation/devicetree/bindings/arm/shmobile.yaml > new file mode 100644 > index 000000000000..31009e7fb0ea > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > @@ -0,0 +1,205 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/shmobile.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > + > +maintainers: > + - Geert Uytterhoeven <geert+renesas@glider.be> > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - description: Emma Mobile EV2 > + items: > + - enum: > + - renesas,kzm9d # Kyoto Microcomputer Co. KZM-A9-Dual > + - const: renesas,emev2 > + > + - description: RZ/A1H (R7S72100) > + items: > + - enum: > + - renesas,genmai # Genmai (RTK772100BC00000BR) > + - renesas,gr-peach # GR-Peach (X28A-M01-E/F) > + - renesas,rskrza1 # RSKRZA1 (YR0K77210C000BE) > + - const: renesas,r7s72100 > + > + - description: SH-Mobile AG5 (R8A73A00/SH73A0) > + items: > + - enum: > + - renesas,kzm9g # Kyoto Microcomputer Co. KZM-A9-GT > + - const: renesas,sh73a0 > + > + - description: R-Mobile APE6 (R8A73A40) > + items: > + - enum: > + - renesas,ape6evm > + - const: renesas,r8a73a4 > + > + - description: R-Mobile A1 (R8A77400) > + items: > + - enum: > + - renesas,armadillo800eva # Atmark Techno Armadillo-800 EVA > + - const: renesas,r8a7740 > + > + - description: RZ/G1H (R8A77420) > + items: > + - const: renesas,r8a7742 > + > + - description: RZ/G1M (R8A77430) > + items: > + - enum: > + # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) > + - iwave,g20d > + - const: iwave,g20m > + - const: renesas,r8a7743 > + > + - items: > + - enum: > + # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) > + - iwave,g20m > + - const: renesas,r8a7743 > + > + - description: RZ/G1N (R8A77440) > + items: > + - enum: > + - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE) > + - const: renesas,r8a7744 > + > + - description: RZ/G1E (R8A77450) > + items: > + - enum: > + - iwave,g22m # iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM) > + - renesas,sk-rzg1e # SK-RZG1E (YR8A77450S000BE) > + - const: renesas,r8a7745 > + - items: > + # iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D) > + - const: iwave,g22d > + - const: iwave,g22m > + - const: renesas,r8a7745 > + > + - description: RZ/G1C (R8A77470) > + items: > + - enum: > + - iwave,g23s #iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > + - const: renesas,r8a77470 > + > + - description: R-Car M1A (R8A77781) > + items: > + - enum: > + - renesas,bockw > + - const: renesas,r8a7778 > + > + - description: R-Car H1 (R8A77790) > + items: > + - enum: > + - renesas,marzen # Marzen (R0P7779A00010S) > + - renesas,stout # Stout (ADAS Starterkit, Y-R-CAR-ADAS-SKH2-BOARD) > + - const: renesas,r8a7779 > + > + - description: R-Car H2 (R8A77900) > + items: > + - enum: > + - renesas,lager # Lager (RTP0RC7790SEB00010S) > + - const: renesas,r8a7790 > + > + - description: R-Car M2-W (R8A77910) > + items: > + - enum: > + - renesas,henninger > + - renesas,koelsch # Koelsch (RTP0RC7791SEB00010S) > + - renesas,porter # Porter (M2-LCDP) > + - const: renesas,r8a7791 > + > + - description: R-Car V2H (R8A77920) > + items: > + - enum: > + - renesas,blanche # Blanche (RTP0RC7792SEB00010S) > + - renesas,wheat # Wheat (RTP0RC7792ASKB0000JE) > + - const: renesas,r8a7792 > + > + - description: R-Car M2-N (R8A77930) > + items: > + - enum: > + - renesas,gose # Gose (RTP0RC7793SEB00010S) > + - const: renesas,r8a7793 > + > + - description: R-Car E2 (R8A77940) > + items: > + - enum: > + - renesas,alt # Alt (RTP0RC7794SEB00010S) > + - renesas,silk # SILK (RTP0RC7794LCB00011S) > + - const: renesas,r8a7794 > + > + - description: R-Car H3 (R8A77950) > + items: > + - enum: > + # H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) > + # H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) > + - renesas,h3ulcb > + - renesas,salvator-x # Salvator-X (RTP0RC7795SIPB0010S) > + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S) > + - const: renesas,r8a7795 > + > + - description: R-Car M3-W (R8A77960) > + items: > + - enum: > + - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > + - renesas,salvator-x # Salvator-X (RTP0RC7796SIPB0011S) > + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S) > + - const: renesas,r8a7796 > + > + - description: Kingfisher (SBEV-RCAR-KF-M03) > + items: > + - const: shimafuji,kingfisher > + - enum: > + - renesas,h3ulcb > + - renesas,m3ulcb > + - enum: > + - renesas,r8a7795 > + - renesas,r8a7796 > + > + - description: R-Car M3-N (R8A77965) > + items: > + - enum: > + - renesas,salvator-x # Salvator-X (RTP0RC7796SIPB0011S (M3-N)) > + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S) > + - const: renesas,r8a77965 > + > + - description: R-Car V3M (R8A77970) > + items: > + - enum: > + - renesas,eagle # Eagle (RTP0RC77970SEB0010S) > + - renesas,v3msk # V3MSK (Y-ASK-RCAR-V3M-WS10) > + - const: renesas,r8a77970 > + > + - description: R-Car V3H (R8A77980) > + items: > + - enum: > + - renesas,condor # Condor (RTP0RC77980SEB0010SS/RTP0RC77980SEB0010SA01) > + - renesas,v3hsk # V3HSK (Y-ASK-RCAR-V3H-WS10) > + - const: renesas,r8a77980 > + > + - description: R-Car E3 (R8A77990) > + items: > + - enum: > + - renesas,ebisu # Ebisu (RTP0RC77990SEB0010S) > + - const: renesas,r8a77990 > + > + - description: R-Car D3 (R8A77995) > + items: > + - enum: > + - renesas,draak # Draak (RTP0RC77995SEB0010S) > + - const: renesas,r8a77995 > + > + - description: RZ/N1D (R9A06G032) > + items: > + - enum: > + - renesas,rzn1d400-db # RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) > + - const: renesas,r9a06g032 > + > +... > -- > 2.17.1 >
Hi Rob, either I'm misunderstanding that, or something did go a bit wrong during the conversion, as pointed out below: Am Freitag, 5. Oktober 2018, 18:58:40 CEST schrieb Rob Herring: > Convert Rockchip SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Heiko Stuebner <heiko@sntech.de> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-rockchip@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/rockchip.txt | 220 ---------------- > .../devicetree/bindings/arm/rockchip.yaml | 242 ++++++++++++++++++ > 2 files changed, 242 insertions(+), 220 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/rockchip.txt > create mode 100644 Documentation/devicetree/bindings/arm/rockchip.yaml > > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - items: > + - enum: > + - amarula,vyasa-rk3288 > + - asus,rk3288-tinker > + - radxa,rock2-square > + - chipspark,popmetal-rk3288 > + - netxeon,r89 > + - firefly,firefly-rk3288 > + - firefly,firefly-rk3288-beta > + - firefly,firefly-rk3288-reload > + - mqmaker,miqi > + - rockchip,rk3288-fennec > + - const: rockchip,rk3288 These are very much distinct boards, so shouldn't they also get individual entries including their existing description like the phytec or google boards below? Similarly why is it an enum for those, while the Google boards get a const for each compatible string? Most non-google boards below also lost their description and where lumped together into combined entries. Was that intentional? Thanks Heiko > + > + - description: Phytec phyCORE-RK3288 Rapid Development Kit > + items: > + - const: phytec,rk3288-pcm-947 > + - const: phytec,rk3288-phycore-som > + - const: rockchip,rk3288 > + > + - description: Google Mickey (Asus Chromebit CS10) > + items: > + - const: google,veyron-mickey-rev8 > + - const: google,veyron-mickey-rev7 > + - const: google,veyron-mickey-rev6 > + - const: google,veyron-mickey-rev5 > + - const: google,veyron-mickey-rev4 > + - const: google,veyron-mickey-rev3 > + - const: google,veyron-mickey-rev2 > + - const: google,veyron-mickey-rev1 > + - const: google,veyron-mickey-rev0 > + - const: google,veyron-mickey > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Minnie (Asus Chromebook Flip C100P) > + items: > + - const: google,veyron-minnie-rev4 > + - const: google,veyron-minnie-rev3 > + - const: google,veyron-minnie-rev2 > + - const: google,veyron-minnie-rev1 > + - const: google,veyron-minnie-rev0 > + - const: google,veyron-minnie > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Pinky (dev-board) > + items: > + - const: google,veyron-pinky-rev2 > + - const: google,veyron-pinky > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Speedy (Asus C201 Chromebook) > + items: > + - const: google,veyron-speedy-rev9 > + - const: google,veyron-speedy-rev8 > + - const: google,veyron-speedy-rev7 > + - const: google,veyron-speedy-rev6 > + - const: google,veyron-speedy-rev5 > + - const: google,veyron-speedy-rev4 > + - const: google,veyron-speedy-rev3 > + - const: google,veyron-speedy-rev2 > + - const: google,veyron-speedy > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Jaq (Haier Chromebook 11 and more) > + items: > + - const: google,veyron-jaq-rev5 > + - const: google,veyron-jaq-rev4 > + - const: google,veyron-jaq-rev3 > + - const: google,veyron-jaq-rev2 > + - const: google,veyron-jaq-rev1 > + - const: google,veyron-jaq > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Jerry (Hisense Chromebook C11 and more) > + items: > + - const: google,veyron-jerry-rev7 > + - const: google,veyron-jerry-rev6 > + - const: google,veyron-jerry-rev5 > + - const: google,veyron-jerry-rev4 > + - const: google,veyron-jerry-rev3 > + - const: google,veyron-jerry > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Brain (dev-board) > + items: > + - const: google,veyron-brain-rev0 > + - const: google,veyron-brain > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - items: > + - enum: > + - rockchip,kylin-rk3036 > + - const: rockchip,rk3036 > + > + - items: > + - enum: > + - haoyu,marsboard-rk3066 > + - mundoreader,bq-curie2 > + - chipspark,rayeager-px2 > + - rikomagic,mk80 > + - const: rockchip,rk3066a > + > + - items: > + - enum: > + - radxa,rock > + - const: rockchip,rk3188 > + > + - items: > + - const: rockchip,px3-evb > + - const: rockchip,px3 > + - const: rockchip,rk3188 > + > + - items: > + - enum: > + - firefly,roc-rk3328-cc > + - pine64,rock64 > + - rockchip,rk3328-evb > + - const: rockchip,rk3328 > + > + - items: > + - enum: > + - geekbuying,geekbox > + - rockchip,rk3368-evb-act8846 > + - rockchip,r88 > + - tsd,rk3368-uq7-haikou > + - tronsmart,orion-r68-meta > + - const: rockchip,rk3368 > + > + - items: > + - enum: > + - geekbuying,geekbox > + - rockchip,rk3368-evb-act8846 > + - rockchip,r88 > + - tsd,rk3368-uq7-haikou > + - tronsmart,orion-r68-meta > + - const: rockchip,rk3368 > + > + - items: > + - const: rockchip,px5-evb > + - const: rockchip,px5 > + - const: rockchip,rk3368 > + > + - items: > + - enum: > + - firefly,firefly-rk3399 > + - rockchip,rk3399-evb > + - rockchip,rk3399-sapphire > + - rockchip,rk3399-sapphire-excavator > + - tsd,rk3399-q7-haikou > + - vamrs,ficus > + - const: rockchip,rk3399 > + > + - description: Google Bob (Asus Chromebook Flip C101PA) > + items: > + - const: google,bob-rev13 > + - const: google,bob-rev12 > + - const: google,bob-rev11 > + - const: google,bob-rev10 > + - const: google,bob-rev9 > + - const: google,bob-rev8 > + - const: google,bob-rev7 > + - const: google,bob-rev6 > + - const: google,bob-rev5 > + - const: google,bob-rev4 > + - const: google,bob > + - const: google,gru > + - const: rockchip,rk3399 > + > + - description: Google Gru (dev-board) > + items: > + - const: google,gru-rev15 > + - const: google,gru-rev14 > + - const: google,gru-rev13 > + - const: google,gru-rev12 > + - const: google,gru-rev11 > + - const: google,gru-rev10 > + - const: google,gru-rev9 > + - const: google,gru-rev8 > + - const: google,gru-rev7 > + - const: google,gru-rev6 > + - const: google,gru-rev5 > + - const: google,gru-rev4 > + - const: google,gru-rev3 > + - const: google,gru-rev2 > + - const: google,gru > + - const: rockchip,rk3399 > + > + - description: Google Kevin (Samsung Chromebook Plus) > + items: > + - const: google,kevin-rev15 > + - const: google,kevin-rev14 > + - const: google,kevin-rev13 > + - const: google,kevin-rev12 > + - const: google,kevin-rev11 > + - const: google,kevin-rev10 > + - const: google,kevin-rev9 > + - const: google,kevin-rev8 > + - const: google,kevin-rev7 > + - const: google,kevin-rev6 > + - const: google,kevin > + - const: google,gru > + - const: rockchip,rk3399 > + > + - items: > + - enum: > + - rockchip,rv1108-evb > + - const: rockchip,rv1108 > + > + - items: > + - enum: > + - rockchip,rk3228-evb > + - const: rockchip,rk3228 > + > + - items: > + - enum: > + - rockchip,rk3229-evb > + - const: rockchip,rk3229 > +... >
On Mon, Oct 8, 2018 at 2:02 AM Shawn Guo <shawnguo@kernel.org> wrote: > > On Fri, Oct 05, 2018 at 11:58:34AM -0500, Rob Herring wrote: > > Convert Freescale SoC bindings to DT schema format using json-schema. > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - description: i.MX23 based Boards > > + items: > > + - enum: > > + - fsl,imx23-evk > > + - olimex,imx23-olinuxino > > + - const: fsl,imx23 > > + > > + - description: i.MX25 Product Development Kit > > + items: > > + - enum: > > + - fsl,imx25-pdk > > + - const: fsl,imx25 > > + > > + - description: i.MX27 Product Development Kit > > + items: > > + - enum: > > + - fsl,imx27-pdk > > + - const: fsl,imx27 > > + > > + - description: i.MX28 based Boards > > + items: > > + - enum: > > + - fsl,imx28-evk > > + - i2se,duckbill > > + - i2se,duckbill-2 > > + - technologic,imx28-ts4600 > > + - const: fsl,imx28 > > + - items: > > The schema is new to me. This line looks unusual to me, so you may want > to double check. It's fine. There's just no description schema on this one as it's a continuation of the previous one (logically, but not from a schema perspective). Perhaps add "i.MX28 I2SE Duckbill 2 based boards". > > + - enum: > > + - i2se,duckbill-2-485 > > + - i2se,duckbill-2-enocean > > + - i2se,duckbill-2-spi > > + - const: i2se,duckbill-2 > > + - const: fsl,imx28 > > + > > + - description: i.MX51 Babbage Board
On Mon, Oct 8, 2018 at 4:45 AM Heiko Stuebner <heiko@sntech.de> wrote: > > Hi Rob, > > either I'm misunderstanding that, or something did go a bit wrong during > the conversion, as pointed out below: > > Am Freitag, 5. Oktober 2018, 18:58:40 CEST schrieb Rob Herring: > > Convert Rockchip SoC bindings to DT schema format using json-schema. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Heiko Stuebner <heiko@sntech.de> > > Cc: devicetree@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-rockchip@lists.infradead.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/arm/rockchip.txt | 220 ---------------- > > .../devicetree/bindings/arm/rockchip.yaml | 242 ++++++++++++++++++ > > 2 files changed, 242 insertions(+), 220 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/rockchip.txt > > create mode 100644 Documentation/devicetree/bindings/arm/rockchip.yaml > > > > > > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - items: > > + - enum: > > + - amarula,vyasa-rk3288 > > + - asus,rk3288-tinker > > + - radxa,rock2-square > > + - chipspark,popmetal-rk3288 > > + - netxeon,r89 > > + - firefly,firefly-rk3288 > > + - firefly,firefly-rk3288-beta > > + - firefly,firefly-rk3288-reload > > + - mqmaker,miqi > > + - rockchip,rk3288-fennec > > + - const: rockchip,rk3288 > > These are very much distinct boards, so shouldn't they also get > individual entries including their existing description like the phytec > or google boards below? It is grouped by SoC compatible and # of compatible strings. So this one is all the cases that have 2 compatible strings. It is simply saying the 1st compatible string must be one of the enums and the 2nd compatible string must be "rockchip,rk3288". > > Similarly why is it an enum for those, while the Google boards get a > const for each compatible string? Because each Google board is a fixed list of strings. > Most non-google boards below also lost their description and where lumped > together into combined entries. Was that intentional? If the description was just repeating the compatible string with spaces and capitalization, then yes it was intentional. If your description matches what you have for 'model', then I'd prefer to see model added as a property schema. Rob
On Mon, Oct 8, 2018 at 3:02 AM Simon Horman <horms@verge.net.au> wrote: > > On Fri, Oct 05, 2018 at 11:58:41AM -0500, Rob Herring wrote: > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > > Cc: Simon Horman <horms@verge.net.au> > > Cc: Magnus Damm <magnus.damm@gmail.com> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-renesas-soc@vger.kernel.org > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > This seems fine to me other than that it does not seem > to apply cleanly to next. > > shmobile.txt sees a couple of updates per release cycle so from my point of > view it would ideal if this change could hit -rc1 to allow patches for > v4.21 to be accepted smoothly (already one from Sergei will need rebasing). When we get to the point of merging (which isn't going to be 4.20), you and other maintainers can probably take all these patches. Other than the few restructuring patches, the only dependency is the build support which isn't a dependency to apply it, but build it. I plan to build any patches as part of reviewing at least early on. OTOH, the build support is small enough and self contained that maybe it can just be applied for 4.20. Rob
On Mon, Oct 8, 2018 at 2:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Rob, > > On Fri, Oct 5, 2018 at 6:59 PM Rob Herring <robh@kernel.org> wrote: > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > > Cc: Simon Horman <horms@verge.net.au> > > Cc: Magnus Damm <magnus.damm@gmail.com> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-renesas-soc@vger.kernel.org > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > Thanks for your patch! > > Note that this will need a rebase, as more SoCs/boards have been added > in -next. > > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > > @@ -0,0 +1,205 @@ > > +# SPDX-License-Identifier: None > > The old file didn't have an SPDX header, so it was GPL-2.0, implicitly? Right. I meant to update this with something. I'd prefer it be dual licensed as these aren't just kernel files, but I don't really want to try to gather permissions from all the copyright holders. And who is the copyright holder when it is implicit? Everyone listed by git blame? > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/bindings/arm/shmobile.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > > + > > +maintainers: > > + - Geert Uytterhoeven <geert+renesas@glider.be> > > Simon Horman <horms@verge.net.au> (supporter:ARM/SHMOBILE ARM ARCHITECTURE) > Magnus Damm <magnus.damm@gmail.com> (supporter:ARM/SHMOBILE ARM ARCHITECTURE) > > You had it right in the CC list, though... I generated it here from git log rather get_maintainers.pl because get_maintainers.pl just lists me for a bunch of them. > > + - description: RZ/G1M (R8A77430) > > + items: > > + - enum: > > + # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) > > + - iwave,g20d > > + - const: iwave,g20m > > + - const: renesas,r8a7743 > > + > > + - items: > > + - enum: > > + # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) > > + - iwave,g20m > > + - const: renesas,r8a7743 > > + > > + - description: RZ/G1N (R8A77440) > > + items: > > + - enum: > > + - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE) > > This board belongs under the RZ/G1M section above > (see also the 7743 in the part number). Indeed. Not sure how I screwed that one up. > > + - const: renesas,r8a7744 > > > + - description: Kingfisher (SBEV-RCAR-KF-M03) > > + items: > > + - const: shimafuji,kingfisher > > + - enum: > > + - renesas,h3ulcb > > + - renesas,m3ulcb > > + - enum: > > + - renesas,r8a7795 > > + - renesas,r8a7796 > > This looks a bit funny: all other entries have the "const" last, and > use it for the > SoC number. May be correct, though. > To clarify, this is an extension board that can fit both the [HM]3ULCB > boards (actually also the new M3NULCB, I think). This being Kingfisher? I wrote this based on dts files in the tree. There's 2 combinations that I see: "shimafuji,kingfisher", "renesas,h3ulcb", "renesas,r8a7795" "shimafuji,kingfisher", "renesas,m3ulcb", "renesas,r8a7796" The schema allows 4 combinations (1 * 2 * 2). I have no idea if the other combinations are possible. If not, then we could rewrite this as 2 entries with 3 const values each. Rob
On Mon, Oct 8, 2018 at 2:05 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Rob, > > On Fri, Oct 5, 2018 at 6:58 PM Rob Herring <robh@kernel.org> wrote: > > In preparation to convert board-level bindings to json-schema, move > > various misc SoC bindings out to their own file. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Simon Horman <horms@verge.net.au> > > Cc: Magnus Damm <magnus.damm@gmail.com> > > Cc: devicetree@vger.kernel.org > > Cc: linux-renesas-soc@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > Looks good to me, but needs a rebase, as the PRR section has been extended > in -next. Is this something you all can apply still for 4.20? Rob
Hi Rob, On Mon, Oct 8, 2018 at 4:57 PM Rob Herring <robh@kernel.org> wrote: > On Mon, Oct 8, 2018 at 2:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Fri, Oct 5, 2018 at 6:59 PM Rob Herring <robh@kernel.org> wrote: > > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > > > @@ -0,0 +1,205 @@ > > > + - description: Kingfisher (SBEV-RCAR-KF-M03) > > > + items: > > > + - const: shimafuji,kingfisher > > > + - enum: > > > + - renesas,h3ulcb > > > + - renesas,m3ulcb > > > + - enum: > > > + - renesas,r8a7795 > > > + - renesas,r8a7796 > > > > This looks a bit funny: all other entries have the "const" last, and > > use it for the > > SoC number. May be correct, though. > > To clarify, this is an extension board that can fit both the [HM]3ULCB > > boards (actually also the new M3NULCB, I think). > > This being Kingfisher? Correct. > I wrote this based on dts files in the tree. There's 2 combinations that I see: > > "shimafuji,kingfisher", "renesas,h3ulcb", "renesas,r8a7795" > "shimafuji,kingfisher", "renesas,m3ulcb", "renesas,r8a7796" > > The schema allows 4 combinations (1 * 2 * 2). I have no idea if the > other combinations are possible. If not, then we could rewrite this as > 2 entries with 3 const values each. I expect there will soon be a third one: "shimafuji,kingfisher", "renesas,m3nulcb", "renesas,r8a77965" Technically, {h3,m3,m3n}ulcb are the same board (although there may be minor revision differences), with a different SiP mounted. But they are called/marketed depending on which SiP is mounted. And on top of that, you can plug in a Kingfisher daughterboard. Could be an overlay ;-) Gr{oetje,eeting}s, Geert
On Mon, Oct 8, 2018 at 10:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Rob, > > On Mon, Oct 8, 2018 at 4:57 PM Rob Herring <robh@kernel.org> wrote: > > On Mon, Oct 8, 2018 at 2:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Fri, Oct 5, 2018 at 6:59 PM Rob Herring <robh@kernel.org> wrote: > > > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > > > > @@ -0,0 +1,205 @@ > > > > > + - description: Kingfisher (SBEV-RCAR-KF-M03) > > > > + items: > > > > + - const: shimafuji,kingfisher > > > > + - enum: > > > > + - renesas,h3ulcb > > > > + - renesas,m3ulcb > > > > + - enum: > > > > + - renesas,r8a7795 > > > > + - renesas,r8a7796 > > > > > > This looks a bit funny: all other entries have the "const" last, and > > > use it for the > > > SoC number. May be correct, though. > > > To clarify, this is an extension board that can fit both the [HM]3ULCB > > > boards (actually also the new M3NULCB, I think). > > > > This being Kingfisher? > > Correct. > > > I wrote this based on dts files in the tree. There's 2 combinations that I see: > > > > "shimafuji,kingfisher", "renesas,h3ulcb", "renesas,r8a7795" > > "shimafuji,kingfisher", "renesas,m3ulcb", "renesas,r8a7796" > > > > The schema allows 4 combinations (1 * 2 * 2). I have no idea if the > > other combinations are possible. If not, then we could rewrite this as > > 2 entries with 3 const values each. > > I expect there will soon be a third one: > > "shimafuji,kingfisher", "renesas,m3nulcb", "renesas,r8a77965" > > Technically, {h3,m3,m3n}ulcb are the same board (although there may be > minor revision differences), with a different SiP mounted. > But they are called/marketed depending on which SiP is mounted. > > And on top of that, you can plug in a Kingfisher daughterboard. Could be an > overlay ;-) We probably shouldn't have put kingfisher as a top-level compatible then. But we did, so not really much point to discuss that now. As to whether there's a better way to express it in the schema, I'm not sure. I don't think there's a way with json-schema to express a list, but the 1st item is optional. Rob
Hi Rob, On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > Convert ARM PMU binding to DT schema format using json-schema. > > Cc: Will Deacon <will.deacon@arm.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-arm-kernel@lists.infradead.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > 2 files changed, 96 insertions(+), 70 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml [...] > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > - interrupt (PPI) then 1 interrupt should be specified. [...] > + interrupts: > + oneOf: > + - maxItems: 1 > + - minItems: 2 > + maxItems: 8 > + description: 1 interrupt per core. > + > + interrupts-extended: > + $ref: '#/properties/interrupts' This seems like a semantic different between the two representations, or am I missing something here? Specifically, both the introduction of interrupts-extended and also dropping any mention of using a single per-cpu interrupt (the single combined case is no longer support by Linux; not sure if you want to keep it in the binding). Will
On Friday 05 October 2018 10:28 PM, Rob Herring wrote: > Convert TI Davinci SoC bindings to DT schema format using json-schema. > > Cc: Sekhar Nori <nsekhar@ti.com> > Cc: Kevin Hilman <khilman@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/davinci.txt | 25 ------------------ > .../bindings/arm/ti/ti,davinci.yaml | 26 +++++++++++++++++++ > 2 files changed, 26 insertions(+), 25 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/davinci.txt > create mode 100644 Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml > > diff --git a/Documentation/devicetree/bindings/arm/davinci.txt b/Documentation/devicetree/bindings/arm/davinci.txt > deleted file mode 100644 > index 715622c36260..000000000000 > --- a/Documentation/devicetree/bindings/arm/davinci.txt > +++ /dev/null > @@ -1,25 +0,0 @@ > -Texas Instruments DaVinci Platforms Device Tree Bindings > --------------------------------------------------------- > - > -DA850/OMAP-L138/AM18x Evaluation Module (EVM) board > -Required root node properties: > - - compatible = "ti,da850-evm", "ti,da850"; > - > -DA850/OMAP-L138/AM18x L138/C6748 Development Kit (LCDK) board > -Required root node properties: > - - compatible = "ti,da850-lcdk", "ti,da850"; > - > -EnBW AM1808 based CMC board > -Required root node properties: > - - compatible = "enbw,cmc", "ti,da850; > - > -LEGO MINDSTORMS EV3 (AM1808 based) > -Required root node properties: > - - compatible = "lego,ev3", "ti,da850"; > - > -Generic DaVinci Boards > ----------------------- > - > -DA850/OMAP-L138/AM18x generic board > -Required root node properties: > - - compatible = "ti,da850"; > diff --git a/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml b/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml > new file mode 100644 > index 000000000000..2675cae91a60 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml > @@ -0,0 +1,26 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/davinci.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Texas Instruments DaVinci Platforms Device Tree Bindings > + > +maintainers: > + - Sekhar Nori <nsekhar@ti.com> > +description: | > + DA850/OMAP-L138/AM18x based boards > + > + > +properties: > + $nodename: > + const: '/' > + compatible: > + items: > + - enum: > + - ti,da850-evm > + - ti,da850-lcdk > + - enbw,cmc > + - lego,ev3 The boards had some reasonable human readable description earlier, which has been lost now. Is there a way to bring that back? Apart from that, looks good to me. Thanks, Sekhar > + - const: ti,da850 > +... > -- > 2.17.1 >
On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: > > Hi Rob, > > On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > > Convert ARM PMU binding to DT schema format using json-schema. > > > > Cc: Will Deacon <will.deacon@arm.com> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > > 2 files changed, 96 insertions(+), 70 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml > > [...] > > > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > > - interrupt (PPI) then 1 interrupt should be specified. > > [...] > > > + interrupts: > > + oneOf: > > + - maxItems: 1 > > + - minItems: 2 > > + maxItems: 8 > > + description: 1 interrupt per core. > > + > > + interrupts-extended: > > + $ref: '#/properties/interrupts' > > This seems like a semantic different between the two representations, or am > I missing something here? Specifically, both the introduction of > interrupts-extended and also dropping any mention of using a single per-cpu > interrupt (the single combined case is no longer support by Linux; not sure > if you want to keep it in the binding). 'interrupts-extended' was implied before as it is always supported and outside the scope of the binding. But now it is needed to validate bindings. There must be some use of it and that's why I added it. However, thinking some more about this, I think it may be better to have the tools add this in automatically whenever we have an interrupts property. I guess the single interrupt case is less obvious now with no description (it's the first list item of 'oneOf'). The schema If the single interrupt is not supported, then we can drop it here. Rob
Hi Rob On 10/05/2018 06:58 PM, Rob Herring wrote: > Convert ST STi SoC bindings to DT schema format using json-schema. > > Cc: Patrice Chotard <patrice.chotard@st.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > Documentation/devicetree/bindings/arm/sti.txt | 23 ------------------- > .../devicetree/bindings/arm/sti.yaml | 23 +++++++++++++++++++ > 2 files changed, 23 insertions(+), 23 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/sti.txt > create mode 100644 Documentation/devicetree/bindings/arm/sti.yaml > > diff --git a/Documentation/devicetree/bindings/arm/sti.txt b/Documentation/devicetree/bindings/arm/sti.txt > deleted file mode 100644 > index 8d27f6b084c7..000000000000 > --- a/Documentation/devicetree/bindings/arm/sti.txt > +++ /dev/null > @@ -1,23 +0,0 @@ > -ST STi Platforms Device Tree Bindings > ---------------------------------------- > - > -Boards with the ST STiH415 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih415"; > - > -Boards with the ST STiH416 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih416"; > - > -Boards with the ST STiH407 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih407"; > - > -Boards with the ST STiH410 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih410"; > - > -Boards with the ST STiH418 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih418"; > - > diff --git a/Documentation/devicetree/bindings/arm/sti.yaml b/Documentation/devicetree/bindings/arm/sti.yaml > new file mode 100644 > index 000000000000..10814334cfc9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/sti.yaml > @@ -0,0 +1,23 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/sti.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ST STi Platforms Device Tree Bindings > + > +maintainers: > + - Maxime Coquelin <maxime.coquelin@st.com> Maxime has left STMicroelectronics, you can replace its email by mine Patrice Chotard <patrice.chotard@st.com> Thanks Patrice > + > +properties: > + $nodename: > + const: '/' > + compatible: > + items: > + - enum: > + - st,stih415 > + - st,stih416 > + - st,stih407 > + - st,stih410 > + - st,stih418 > +... >
On Tue, Oct 09, 2018 at 01:14:02PM -0500, Rob Herring wrote: > On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: > > > > Hi Rob, > > > > On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > > > Convert ARM PMU binding to DT schema format using json-schema. > > > > > > Cc: Will Deacon <will.deacon@arm.com> > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: linux-arm-kernel@lists.infradead.org > > > Cc: devicetree@vger.kernel.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > > > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > > > 2 files changed, 96 insertions(+), 70 deletions(-) > > > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > > > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml > > > > [...] > > > > > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > > > - interrupt (PPI) then 1 interrupt should be specified. > > > > [...] > > > > > + interrupts: > > > + oneOf: > > > + - maxItems: 1 > > > + - minItems: 2 > > > + maxItems: 8 > > > + description: 1 interrupt per core. > > > + > > > + interrupts-extended: > > > + $ref: '#/properties/interrupts' > > > > This seems like a semantic different between the two representations, or am > > I missing something here? Specifically, both the introduction of > > interrupts-extended and also dropping any mention of using a single per-cpu > > interrupt (the single combined case is no longer support by Linux; not sure > > if you want to keep it in the binding). > > 'interrupts-extended' was implied before as it is always supported and > outside the scope of the binding. But now it is needed to validate > bindings. There must be some use of it and that's why I added it. > However, thinking some more about this, I think it may be better to > have the tools add this in automatically whenever we have an > interrupts property. To be honest, if you'd included that in the commit message I'd have been happy :) > I guess the single interrupt case is less obvious now with no > description (it's the first list item of 'oneOf'). The schema If the > single interrupt is not supported, then we can drop it here. Well the description says "1 interrupt per core" which is incorrect. I also don't understand why maxItems is 8. Will
On Wed, Oct 10, 2018 at 11:50 AM Will Deacon <will.deacon@arm.com> wrote: > > On Tue, Oct 09, 2018 at 01:14:02PM -0500, Rob Herring wrote: > > On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: > > > > > > Hi Rob, > > > > > > On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > > > > Convert ARM PMU binding to DT schema format using json-schema. > > > > > > > > Cc: Will Deacon <will.deacon@arm.com> > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > > Cc: linux-arm-kernel@lists.infradead.org > > > > Cc: devicetree@vger.kernel.org > > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > > --- > > > > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > > > > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > > > > 2 files changed, 96 insertions(+), 70 deletions(-) > > > > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > > > > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml > > > > > > [...] > > > > > > > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > > > > - interrupt (PPI) then 1 interrupt should be specified. > > > > > > [...] > > > > > > > + interrupts: > > > > + oneOf: > > > > + - maxItems: 1 > > > > + - minItems: 2 > > > > + maxItems: 8 > > > > + description: 1 interrupt per core. > > > > + > > > > + interrupts-extended: > > > > + $ref: '#/properties/interrupts' > > > > > > This seems like a semantic different between the two representations, or am > > > I missing something here? Specifically, both the introduction of > > > interrupts-extended and also dropping any mention of using a single per-cpu > > > interrupt (the single combined case is no longer support by Linux; not sure > > > if you want to keep it in the binding). > > > > 'interrupts-extended' was implied before as it is always supported and > > outside the scope of the binding. But now it is needed to validate > > bindings. There must be some use of it and that's why I added it. > > However, thinking some more about this, I think it may be better to > > have the tools add this in automatically whenever we have an > > interrupts property. > > To be honest, if you'd included that in the commit message I'd have been > happy :) > > > I guess the single interrupt case is less obvious now with no > > description (it's the first list item of 'oneOf'). The schema If the > > single interrupt is not supported, then we can drop it here. > > Well the description says "1 interrupt per core" which is incorrect. You are reading the schema wrong. There are 2 cases supported as defined by each '-'. The 2nd case is all the keywords until the indentation decreases. So 'description' is just description of the 2nd case. The first case is just "maxItems: 1". I probably didn't put a description because why write in free form text what the schema says (other than of course no one knows json-schema...). YAML combines the best of Makefiles and python. You can't have tabs and Indentation is significant. :) > I also > don't understand why maxItems is 8. Humm, I probably just made that up based on GICv2 limitations. What should it be? If there's not any inherit maximum, can we put something reasonable? There's not really any way to express that it should match the number of cores in the system. Rob
On Mon, Oct 08, 2018 at 09:05:58AM -0500, Rob Herring wrote: > On Mon, Oct 8, 2018 at 3:02 AM Simon Horman <horms@verge.net.au> wrote: > > > > On Fri, Oct 05, 2018 at 11:58:41AM -0500, Rob Herring wrote: > > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > > > > Cc: Simon Horman <horms@verge.net.au> > > > Cc: Magnus Damm <magnus.damm@gmail.com> > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: linux-renesas-soc@vger.kernel.org > > > Cc: devicetree@vger.kernel.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > > This seems fine to me other than that it does not seem > > to apply cleanly to next. > > > > shmobile.txt sees a couple of updates per release cycle so from my point of > > view it would ideal if this change could hit -rc1 to allow patches for > > v4.21 to be accepted smoothly (already one from Sergei will need rebasing). > > When we get to the point of merging (which isn't going to be 4.20), > you and other maintainers can probably take all these patches. Other > than the few restructuring patches, the only dependency is the build > support which isn't a dependency to apply it, but build it. I plan to > build any patches as part of reviewing at least early on. OTOH, the > build support is small enough and self contained that maybe it can > just be applied for 4.20. Thanks, understood. My preference would be to, as you suggest, take changes like this through the renesas tree.
On Mon, Oct 08, 2018 at 09:59:19AM -0500, Rob Herring wrote: > On Mon, Oct 8, 2018 at 2:05 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > Hi Rob, > > > > On Fri, Oct 5, 2018 at 6:58 PM Rob Herring <robh@kernel.org> wrote: > > > In preparation to convert board-level bindings to json-schema, move > > > various misc SoC bindings out to their own file. > > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: Simon Horman <horms@verge.net.au> > > > Cc: Magnus Damm <magnus.damm@gmail.com> > > > Cc: devicetree@vger.kernel.org > > > Cc: linux-renesas-soc@vger.kernel.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > > Looks good to me, but needs a rebase, as the PRR section has been extended > > in -next. > > Is this something you all can apply still for 4.20? Sorry, missing this until now. It was too late. Shall I take it for v4.21?
Hi Rob, On Wed, Oct 10, 2018 at 01:51:24PM -0500, Rob Herring wrote: > On Wed, Oct 10, 2018 at 11:50 AM Will Deacon <will.deacon@arm.com> wrote: > > On Tue, Oct 09, 2018 at 01:14:02PM -0500, Rob Herring wrote: > > > I guess the single interrupt case is less obvious now with no > > > description (it's the first list item of 'oneOf'). The schema If the > > > single interrupt is not supported, then we can drop it here. > > > > Well the description says "1 interrupt per core" which is incorrect. > > You are reading the schema wrong. There are 2 cases supported as > defined by each '-'. The 2nd case is all the keywords until the > indentation decreases. So 'description' is just description of the 2nd > case. The first case is just "maxItems: 1". I probably didn't put a > description because why write in free form text what the schema says > (other than of course no one knows json-schema...). Apologies, I've not read one of these things before and looks like I completely misread it. > YAML combines the best of Makefiles and python. You can't have tabs > and Indentation is significant. :) Oh wow, I'm in way over my head here! > > I also > > don't understand why maxItems is 8. > > Humm, I probably just made that up based on GICv2 limitations. What > should it be? If there's not any inherit maximum, can we put something > reasonable? There's not really any way to express that it should match > the number of cores in the system. What's the largest number you can think of? Will
On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: > > Hi Rob, > > On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > > Convert ARM PMU binding to DT schema format using json-schema. > > > > Cc: Will Deacon <will.deacon@arm.com> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > > 2 files changed, 96 insertions(+), 70 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml > > [...] > > > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > > - interrupt (PPI) then 1 interrupt should be specified. > > [...] > > > + interrupts: > > + oneOf: > > + - maxItems: 1 > > + - minItems: 2 > > + maxItems: 8 > > + description: 1 interrupt per core. > > + > > + interrupts-extended: > > + $ref: '#/properties/interrupts' > > This seems like a semantic different between the two representations, or am > I missing something here? Specifically, both the introduction of > interrupts-extended and also dropping any mention of using a single per-cpu > interrupt (the single combined case is no longer support by Linux; not sure > if you want to keep it in the binding). In regards to no support for the single combined interrupt, it looks like Marvell Armada SoCs at least (armada-375 is what I'm looking at) have only a single interrupt. Though the interrupt gets routed to MPIC which then has a GIC PPI. So it isn't supported or happens to work still since it is a PPI? Rob
Hi Rob, On 05. 10. 18 18:58, Rob Herring wrote: > Convert ARM CPU binding to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Matthias Brugger <matthias.bgg@gmail.com> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-mediatek@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/cpus.txt | 490 ----------------- > .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ > 2 files changed, 503 insertions(+), 490 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt > create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml > > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt > deleted file mode 100644 > index b0198a1cf403..000000000000 > --- a/Documentation/devicetree/bindings/arm/cpus.txt > +++ /dev/null > @@ -1,490 +0,0 @@ > -================= > -ARM CPUs bindings > -================= > - > -The device tree allows to describe the layout of CPUs in a system through > -the "cpus" node, which in turn contains a number of subnodes (ie "cpu") > -defining properties for every cpu. > - > -Bindings for CPU nodes follow the Devicetree Specification, available from: > - > -https://www.devicetree.org/specifications/ > - > -with updates for 32-bit and 64-bit ARM systems provided in this document. > - > -================================ > -Convention used in this document > -================================ > - > -This document follows the conventions described in the Devicetree > -Specification, with the addition: > - > -- square brackets define bitfields, eg reg[7:0] value of the bitfield in > - the reg property contained in bits 7 down to 0 > - > -===================================== > -cpus and cpu node bindings definition > -===================================== > - > -The ARM architecture, in accordance with the Devicetree Specification, > -requires the cpus and cpu nodes to be present and contain the properties > -described below. > - > -- cpus node > - > - Description: Container of cpu nodes > - > - The node name must be "cpus". > - > - A cpus node must define the following properties: > - > - - #address-cells > - Usage: required > - Value type: <u32> > - > - Definition depends on ARM architecture version and > - configuration: > - > - # On uniprocessor ARM architectures previous to v7 > - value must be 1, to enable a simple enumeration > - scheme for processors that do not have a HW CPU > - identification register. > - # On 32-bit ARM 11 MPcore, ARM v7 or later systems > - value must be 1, that corresponds to CPUID/MPIDR > - registers sizes. > - # On ARM v8 64-bit systems value should be set to 2, > - that corresponds to the MPIDR_EL1 register size. > - If MPIDR_EL1[63:32] value is equal to 0 on all CPUs > - in the system, #address-cells can be set to 1, since > - MPIDR_EL1[63:32] bits are not used for CPUs > - identification. > - - #size-cells > - Usage: required > - Value type: <u32> > - Definition: must be set to 0 > - > -- cpu node > - > - Description: Describes a CPU in an ARM based system > - > - PROPERTIES > - > - - device_type > - Usage: required > - Value type: <string> > - Definition: must be "cpu" > - - reg > - Usage and definition depend on ARM architecture version and > - configuration: > - > - # On uniprocessor ARM architectures previous to v7 > - this property is required and must be set to 0. > - > - # On ARM 11 MPcore based systems this property is > - required and matches the CPUID[11:0] register bits. > - > - Bits [11:0] in the reg cell must be set to > - bits [11:0] in CPU ID register. > - > - All other bits in the reg cell must be set to 0. > - > - # On 32-bit ARM v7 or later systems this property is > - required and matches the CPU MPIDR[23:0] register > - bits. > - > - Bits [23:0] in the reg cell must be set to > - bits [23:0] in MPIDR. > - > - All other bits in the reg cell must be set to 0. > - > - # On ARM v8 64-bit systems this property is required > - and matches the MPIDR_EL1 register affinity bits. > - > - * If cpus node's #address-cells property is set to 2 > - > - The first reg cell bits [7:0] must be set to > - bits [39:32] of MPIDR_EL1. > - > - The second reg cell bits [23:0] must be set to > - bits [23:0] of MPIDR_EL1. > - > - * If cpus node's #address-cells property is set to 1 > - > - The reg cell bits [23:0] must be set to bits [23:0] > - of MPIDR_EL1. > - > - All other bits in the reg cells must be set to 0. > - > - - compatible: > - Usage: required > - Value type: <string> > - Definition: should be one of: > - "arm,arm710t" > - "arm,arm720t" > - "arm,arm740t" > - "arm,arm7ej-s" > - "arm,arm7tdmi" > - "arm,arm7tdmi-s" > - "arm,arm9es" > - "arm,arm9ej-s" > - "arm,arm920t" > - "arm,arm922t" > - "arm,arm925" > - "arm,arm926e-s" > - "arm,arm926ej-s" > - "arm,arm940t" > - "arm,arm946e-s" > - "arm,arm966e-s" > - "arm,arm968e-s" > - "arm,arm9tdmi" > - "arm,arm1020e" > - "arm,arm1020t" > - "arm,arm1022e" > - "arm,arm1026ej-s" > - "arm,arm1136j-s" > - "arm,arm1136jf-s" > - "arm,arm1156t2-s" > - "arm,arm1156t2f-s" > - "arm,arm1176jzf" > - "arm,arm1176jz-s" > - "arm,arm1176jzf-s" > - "arm,arm11mpcore" > - "arm,cortex-a5" > - "arm,cortex-a7" > - "arm,cortex-a8" > - "arm,cortex-a9" > - "arm,cortex-a12" > - "arm,cortex-a15" > - "arm,cortex-a17" > - "arm,cortex-a53" > - "arm,cortex-a57" > - "arm,cortex-a72" > - "arm,cortex-a73" > - "arm,cortex-m0" > - "arm,cortex-m0+" > - "arm,cortex-m1" > - "arm,cortex-m3" > - "arm,cortex-m4" > - "arm,cortex-r4" > - "arm,cortex-r5" > - "arm,cortex-r7" > - "brcm,brahma-b15" > - "brcm,brahma-b53" > - "brcm,vulcan" > - "cavium,thunder" > - "cavium,thunder2" > - "faraday,fa526" > - "intel,sa110" > - "intel,sa1100" > - "marvell,feroceon" > - "marvell,mohawk" > - "marvell,pj4a" > - "marvell,pj4b" > - "marvell,sheeva-v5" > - "nvidia,tegra132-denver" > - "nvidia,tegra186-denver" > - "nvidia,tegra194-carmel" > - "qcom,krait" > - "qcom,kryo" > - "qcom,kryo385" > - "qcom,scorpion" > - - enable-method > - Value type: <stringlist> > - Usage and definition depend on ARM architecture version. > - # On ARM v8 64-bit this property is required and must > - be one of: > - "psci" > - "spin-table" > - # On ARM 32-bit systems this property is optional and > - can be one of: > - "actions,s500-smp" > - "allwinner,sun6i-a31" > - "allwinner,sun8i-a23" > - "allwinner,sun9i-a80-smp" > - "amlogic,meson8-smp" > - "amlogic,meson8b-smp" > - "arm,realview-smp" > - "brcm,bcm11351-cpu-method" > - "brcm,bcm23550" > - "brcm,bcm2836-smp" > - "brcm,bcm-nsp-smp" > - "brcm,brahma-b15" > - "marvell,armada-375-smp" > - "marvell,armada-380-smp" > - "marvell,armada-390-smp" > - "marvell,armada-xp-smp" > - "marvell,98dx3236-smp" > - "mediatek,mt6589-smp" > - "mediatek,mt81xx-tz-smp" > - "qcom,gcc-msm8660" > - "qcom,kpss-acc-v1" > - "qcom,kpss-acc-v2" > - "renesas,apmu" > - "renesas,r9a06g032-smp" > - "rockchip,rk3036-smp" > - "rockchip,rk3066-smp" > - "ste,dbx500-smp" > - > - - cpu-release-addr > - Usage: required for systems that have an "enable-method" > - property value of "spin-table". > - Value type: <prop-encoded-array> > - Definition: > - # On ARM v8 64-bit systems must be a two cell > - property identifying a 64-bit zero-initialised > - memory location. > - > - - qcom,saw > - Usage: required for systems that have an "enable-method" > - property value of "qcom,kpss-acc-v1" or > - "qcom,kpss-acc-v2" > - Value type: <phandle> > - Definition: Specifies the SAW[1] node associated with this CPU. > - > - - qcom,acc > - Usage: required for systems that have an "enable-method" > - property value of "qcom,kpss-acc-v1" or > - "qcom,kpss-acc-v2" > - Value type: <phandle> > - Definition: Specifies the ACC[2] node associated with this CPU. > - > - - cpu-idle-states > - Usage: Optional > - Value type: <prop-encoded-array> > - Definition: > - # List of phandles to idle state nodes supported > - by this cpu [3]. > - > - - capacity-dmips-mhz > - Usage: Optional > - Value type: <u32> > - Definition: > - # u32 value representing CPU capacity [4] in > - DMIPS/MHz, relative to highest capacity-dmips-mhz > - in the system. > - > - - rockchip,pmu > - Usage: optional for systems that have an "enable-method" > - property value of "rockchip,rk3066-smp" > - While optional, it is the preferred way to get access to > - the cpu-core power-domains. > - Value type: <phandle> > - Definition: Specifies the syscon node controlling the cpu core > - power domains. > - > - - dynamic-power-coefficient > - Usage: optional > - Value type: <prop-encoded-array> > - Definition: A u32 value that represents the running time dynamic > - power coefficient in units of uW/MHz/V^2. The > - coefficient can either be calculated from power > - measurements or derived by analysis. > - > - The dynamic power consumption of the CPU is > - proportional to the square of the Voltage (V) and > - the clock frequency (f). The coefficient is used to > - calculate the dynamic power as below - > - > - Pdyn = dynamic-power-coefficient * V^2 * f > - > - where voltage is in V, frequency is in MHz. > - > -Example 1 (dual-cluster big.LITTLE system 32-bit): > - > - cpus { > - #size-cells = <0>; > - #address-cells = <1>; > - > - cpu@0 { > - device_type = "cpu"; > - compatible = "arm,cortex-a15"; > - reg = <0x0>; > - }; > - > - cpu@1 { > - device_type = "cpu"; > - compatible = "arm,cortex-a15"; > - reg = <0x1>; > - }; > - > - cpu@100 { > - device_type = "cpu"; > - compatible = "arm,cortex-a7"; > - reg = <0x100>; > - }; > - > - cpu@101 { > - device_type = "cpu"; > - compatible = "arm,cortex-a7"; > - reg = <0x101>; > - }; > - }; > - > -Example 2 (Cortex-A8 uniprocessor 32-bit system): > - > - cpus { > - #size-cells = <0>; > - #address-cells = <1>; > - > - cpu@0 { > - device_type = "cpu"; > - compatible = "arm,cortex-a8"; > - reg = <0x0>; > - }; > - }; > - > -Example 3 (ARM 926EJ-S uniprocessor 32-bit system): > - > - cpus { > - #size-cells = <0>; > - #address-cells = <1>; > - > - cpu@0 { > - device_type = "cpu"; > - compatible = "arm,arm926ej-s"; > - reg = <0x0>; > - }; > - }; > - > -Example 4 (ARM Cortex-A57 64-bit system): > - > -cpus { > - #size-cells = <0>; > - #address-cells = <2>; > - > - cpu@0 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x0 0x0>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@1 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x0 0x1>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x0 0x100>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@101 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x0 0x101>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@10000 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x0 0x10000>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@10001 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x0 0x10001>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@10100 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x0 0x10100>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@10101 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x0 0x10101>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100000000 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x1 0x0>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100000001 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x1 0x1>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100000100 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x1 0x100>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100000101 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x1 0x101>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100010000 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x1 0x10000>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100010001 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x1 0x10001>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100010100 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x1 0x10100>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > - > - cpu@100010101 { > - device_type = "cpu"; > - compatible = "arm,cortex-a57"; > - reg = <0x1 0x10101>; > - enable-method = "spin-table"; > - cpu-release-addr = <0 0x20000000>; > - }; > -}; > - > --- > -[1] arm/msm/qcom,saw2.txt > -[2] arm/msm/qcom,kpss-acc.txt > -[3] ARM Linux kernel documentation - idle states bindings > - Documentation/devicetree/bindings/arm/idle-states.txt > -[4] ARM Linux kernel documentation - cpu capacity bindings > - Documentation/devicetree/bindings/arm/cpu-capacity.txt > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml > new file mode 100644 > index 000000000000..bb75914324a3 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml > @@ -0,0 +1,503 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/cpus.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ARM CPUs bindings > + > +maintainers: > + - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > + > +description: |+ > + The device tree allows to describe the layout of CPUs in a system through > + the "cpus" node, which in turn contains a number of subnodes (ie "cpu") > + defining properties for every cpu. > + > + Bindings for CPU nodes follow the Devicetree Specification, available from: > + > + https://www.devicetree.org/specifications/ > + > + with updates for 32-bit and 64-bit ARM systems provided in this document. > + > + ================================ > + Convention used in this document > + ================================ > + > + This document follows the conventions described in the Devicetree > + Specification, with the addition: > + > + - square brackets define bitfields, eg reg[7:0] value of the bitfield in > + the reg property contained in bits 7 down to 0 > + > + ===================================== > + cpus and cpu node bindings definition > + ===================================== > + > + The ARM architecture, in accordance with the Devicetree Specification, > + requires the cpus and cpu nodes to be present and contain the properties > + described below. > + > +properties: > + $nodename: > + const: cpus > + description: Container of cpu nodes > + > + '#address-cells': > + enum: [1, 2] > + description: | > + Definition depends on ARM architecture version and configuration: > + > + On uniprocessor ARM architectures previous to v7 > + value must be 1, to enable a simple enumeration > + scheme for processors that do not have a HW CPU > + identification register. > + On 32-bit ARM 11 MPcore, ARM v7 or later systems > + value must be 1, that corresponds to CPUID/MPIDR > + registers sizes. > + On ARM v8 64-bit systems value should be set to 2, > + that corresponds to the MPIDR_EL1 register size. > + If MPIDR_EL1[63:32] value is equal to 0 on all CPUs > + in the system, #address-cells can be set to 1, since > + MPIDR_EL1[63:32] bits are not used for CPUs > + identification. > + > + '#size-cells': > + const: 0 > + > +patternProperties: > + '^cpu@[0-9a-f]+$': > + properties: > + device_type: > + const: cpu > + > + reg: > + maxItems: 1 > + description: | > + Usage and definition depend on ARM architecture version and > + configuration: > + > + On uniprocessor ARM architectures previous to v7 > + this property is required and must be set to 0. > + > + On ARM 11 MPcore based systems this property is > + required and matches the CPUID[11:0] register bits. > + > + Bits [11:0] in the reg cell must be set to > + bits [11:0] in CPU ID register. > + > + All other bits in the reg cell must be set to 0. > + > + On 32-bit ARM v7 or later systems this property is > + required and matches the CPU MPIDR[23:0] register > + bits. > + > + Bits [23:0] in the reg cell must be set to > + bits [23:0] in MPIDR. > + > + All other bits in the reg cell must be set to 0. > + > + On ARM v8 64-bit systems this property is required > + and matches the MPIDR_EL1 register affinity bits. > + > + * If cpus node's #address-cells property is set to 2 > + > + The first reg cell bits [7:0] must be set to > + bits [39:32] of MPIDR_EL1. > + > + The second reg cell bits [23:0] must be set to > + bits [23:0] of MPIDR_EL1. > + > + * If cpus node's #address-cells property is set to 1 > + > + The reg cell bits [23:0] must be set to bits [23:0] > + of MPIDR_EL1. > + > + All other bits in the reg cells must be set to 0. > + > + compatible: > + items: > + - enum: > + - arm,arm710t > + - arm,arm720t > + - arm,arm740t > + - arm,arm7ej-s > + - arm,arm7tdmi > + - arm,arm7tdmi-s > + - arm,arm9es > + - arm,arm9ej-s > + - arm,arm920t > + - arm,arm922t > + - arm,arm925 > + - arm,arm926e-s > + - arm,arm926ej-s > + - arm,arm940t > + - arm,arm946e-s > + - arm,arm966e-s > + - arm,arm968e-s > + - arm,arm9tdmi > + - arm,arm1020e > + - arm,arm1020t > + - arm,arm1022e > + - arm,arm1026ej-s > + - arm,arm1136j-s > + - arm,arm1136jf-s > + - arm,arm1156t2-s > + - arm,arm1156t2f-s > + - arm,arm1176jzf > + - arm,arm1176jz-s > + - arm,arm1176jzf-s > + - arm,arm11mpcore > + - arm,cortex-a5 > + - arm,cortex-a7 > + - arm,cortex-a8 > + - arm,cortex-a9 > + - arm,cortex-a12 > + - arm,cortex-a15 > + - arm,cortex-a17 > + - arm,cortex-a53 > + - arm,cortex-a57 > + - arm,cortex-a72 > + - arm,cortex-a73 > + - arm,cortex-m0 > + - arm,cortex-m0+ > + - arm,cortex-m1 > + - arm,cortex-m3 > + - arm,cortex-m4 > + - arm,cortex-r4 > + - arm,cortex-r5 > + - arm,cortex-r7 > + - brcm,brahma-b15 > + - brcm,brahma-b53 > + - brcm,vulcan > + - cavium,thunder > + - cavium,thunder2 > + - faraday,fa526 > + - intel,sa110 > + - intel,sa1100 > + - marvell,feroceon > + - marvell,mohawk > + - marvell,pj4a > + - marvell,pj4b > + - marvell,sheeva-v5 > + - nvidia,tegra132-denver > + - nvidia,tegra186-denver > + - nvidia,tegra194-carmel > + - qcom,krait > + - qcom,kryo > + - qcom,kryo385 > + - qcom,scorpion > + > + enable-method: > + allOf: > + - $ref: '/schemas/types.yaml#/definitions/string' > + - oneOf: > + # On ARM v8 64-bit this property is required > + - enum: > + - psci > + - spin-table > + # On ARM 32-bit systems this property is optional > + - enum: > + - actions,s500-smp > + - allwinner,sun6i-a31 > + - allwinner,sun8i-a23 > + - allwinner,sun9i-a80-smp > + - allwinner,sun8i-a83t-smp > + - amlogic,meson8-smp > + - amlogic,meson8b-smp > + - arm,realview-smp > + - brcm,bcm11351-cpu-method > + - brcm,bcm23550 > + - brcm,bcm2836-smp > + - brcm,bcm63138 > + - brcm,bcm-nsp-smp > + - brcm,brahma-b15 > + - marvell,armada-375-smp > + - marvell,armada-380-smp > + - marvell,armada-390-smp > + - marvell,armada-xp-smp > + - marvell,98dx3236-smp > + - mediatek,mt6589-smp > + - mediatek,mt81xx-tz-smp > + - qcom,gcc-msm8660 > + - qcom,kpss-acc-v1 > + - qcom,kpss-acc-v2 > + - renesas,apmu > + - renesas,r9a06g032-smp > + - rockchip,rk3036-smp > + - rockchip,rk3066-smp > + - ste,dbx500-smp > + > + cpu-release-addr: > + $ref: '/schemas/types.yaml#/definitions/uint64' > + > + description: > + Required for systems that have an "enable-method" > + property value of "spin-table". > + On ARM v8 64-bit systems must be a two cell > + property identifying a 64-bit zero-initialised > + memory location. > + > + qcom,saw: > + $ref: '/schemas/types.yaml#/definitions/phandle' > + description: | > + Usage: required for systems that have an "enable-method" > + property value of "qcom,kpss-acc-v1" or > + "qcom,kpss-acc-v2" > + Definition: Specifies the SAW[1] node associated with this CPU. > + > + qcom,acc: > + $ref: '/schemas/types.yaml#/definitions/phandle' > + description: | > + Usage: required for systems that have an "enable-method" > + property value of "qcom,kpss-acc-v1" or > + "qcom,kpss-acc-v2" > + Definition: Specifies the ACC[2] node associated with this CPU. > + > + cpu-idle-states: > + $ref: '/schemas/types.yaml#/definitions/phandle-array' > + description: | > + Usage: Optional > + Value type: <prop-encoded-array> > + description: List of phandles to idle state nodes supported > + by this cpu [3]. > + > + capacity-dmips-mhz: > + $ref: '/schemas/types.yaml#/definitions/uint32' > + description: > + u32 value representing CPU capacity [4] in > + DMIPS/MHz, relative to highest capacity-dmips-mhz > + in the system. > + > + rockchip,pmu: > + description: | > + Optional for systems that have an "enable-method" > + property value of "rockchip,rk3066-smp" > + While optional, it is the preferred way to get access to > + the cpu-core power-domains. > + Value type: <phandle> > + Definition: Specifies the syscon node controlling the cpu core > + power domains. > + > + dynamic-power-coefficient: > + $ref: '/schemas/types.yaml#/definitions/uint32' > + description: > + A u32 value that represents the running time dynamic > + power coefficient in units of uW/MHz/V^2. The > + coefficient can either be calculated from power > + measurements or derived by analysis. > + > + The dynamic power consumption of the CPU is > + proportional to the square of the Voltage (V) and > + the clock frequency (f). The coefficient is used to > + calculate the dynamic power as below - > + > + Pdyn = dynamic-power-coefficient * V^2 * f > + > + where voltage is in V, frequency is in MHz. > + > + required: > + - device_type > + - reg > + - compatible > + > + dependencies: > + cpu-release-addr: [enable-method] > + rockchip,pmu: [enable-method] > + > +required: > + - '#address-cells' > + - '#size-cells' > + > +examples: > + - | > + cpus { > + #size-cells = <0>; > + #address-cells = <1>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a15"; > + reg = <0x0>; > + }; > + > + cpu@1 { > + device_type = "cpu"; > + compatible = "arm,cortex-a15"; > + reg = <0x1>; > + }; > + > + cpu@100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a7"; > + reg = <0x100>; > + }; > + > + cpu@101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a7"; > + reg = <0x101>; > + }; > + }; > + > + - | > + // Example 2 (Cortex-A8 uniprocessor 32-bit system): > + cpus { > + #size-cells = <0>; > + #address-cells = <1>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a8"; > + reg = <0x0>; > + }; > + }; > + > + - | > + // Example 3 (ARM 926EJ-S uniprocessor 32-bit system): > + cpus { > + #size-cells = <0>; > + #address-cells = <1>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,arm926ej-s"; > + reg = <0x0>; > + }; > + }; > + > + - | > + // Example 4 (ARM Cortex-A57 64-bit system): > + cpus { > + #size-cells = <0>; > + #address-cells = <2>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x0>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@1 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x1>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x100>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x101>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@10000 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x10000>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@10001 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x10001>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@10100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x10100>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@10101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x10101>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100000000 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x1 0x0>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100000001 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x1 0x1>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100000100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x1 0x100>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100000101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x1 0x101>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100010000 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x1 0x10000>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100010001 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x1 0x10001>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100010100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x1 0x10100>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + > + cpu@100010101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x1 0x10101>; > + enable-method = "spin-table"; > + cpu-release-addr = <0 0x20000000>; > + }; > + }; > +... > I have take a look at xilinx part of this and try to build it for arm64 platforms and I see errors coming from this cpu description. /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: cpu@0:compatible: ['arm,cortex-a53', 'arm,armv8'] is too long /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: cpu@0:compatible: Additional items are not allowed ('arm,armv8' was unexpected) Based on grep this is used in a lot of places compatible = "arm,cortex-a53", "arm,armv8"; Should this be moved to just simple? compatible = "arm,cortex-a53"; Thanks, Michal
On 05. 10. 18 18:58, Rob Herring wrote: > Convert Xilinx SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Michal Simek <michal.simek@xilinx.com> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/xilinx.txt | 83 ------------------- > .../devicetree/bindings/arm/xilinx.yaml | 81 ++++++++++++++++++ > 2 files changed, 81 insertions(+), 83 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/xilinx.txt > create mode 100644 Documentation/devicetree/bindings/arm/xilinx.yaml > > diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt > deleted file mode 100644 > index 26fe5ecc4332..000000000000 > --- a/Documentation/devicetree/bindings/arm/xilinx.txt > +++ /dev/null > @@ -1,83 +0,0 @@ > -Xilinx Zynq Platforms Device Tree Bindings > - > -Boards with Zynq-7000 SOC based on an ARM Cortex A9 processor > -shall have the following properties. > - > -Required root node properties: > - - compatible = "xlnx,zynq-7000"; > - > -Additional compatible strings: > - > -- Adapteva Parallella board > - "adapteva,parallella" > - > -- Avnet MicroZed board > - "avnet,zynq-microzed" > - "xlnx,zynq-microzed" > - > -- Avnet ZedBoard board > - "avnet,zynq-zed" > - "xlnx,zynq-zed" > - > -- Digilent Zybo board > - "digilent,zynq-zybo" > - > -- Digilent Zybo Z7 board > - "digilent,zynq-zybo-z7" > - > -- Xilinx CC108 internal board > - "xlnx,zynq-cc108" > - > -- Xilinx ZC702 internal board > - "xlnx,zynq-zc702" > - > -- Xilinx ZC706 internal board > - "xlnx,zynq-zc706" > - > -- Xilinx ZC770 internal board, with different FMC cards > - "xlnx,zynq-zc770-xm010" > - "xlnx,zynq-zc770-xm011" > - "xlnx,zynq-zc770-xm012" > - "xlnx,zynq-zc770-xm013" > - > ---------------------------------------------------------------- > - > -Xilinx Zynq UltraScale+ MPSoC Platforms Device Tree Bindings > - > -Boards with ZynqMP SOC based on an ARM Cortex A53 processor > -shall have the following properties. > - > -Required root node properties: > - - compatible = "xlnx,zynqmp"; > - > - > -Additional compatible strings: > - > -- Xilinx internal board zc1232 > - "xlnx,zynqmp-zc1232-revA", "xlnx,zynqmp-zc1232" > - > -- Xilinx internal board zc1254 > - "xlnx,zynqmp-zc1254-revA", "xlnx,zynqmp-zc1254" > - > -- Xilinx internal board zc1275 > - "xlnx,zynqmp-zc1275-revA", "xlnx,zynqmp-zc1275" > - > -- Xilinx internal board zc1751 > - "xlnx,zynqmp-zc1751" > - > -- Xilinx 96boards compatible board zcu100 > - "xlnx,zynqmp-zcu100-revC", "xlnx,zynqmp-zcu100" > - > -- Xilinx evaluation board zcu102 > - "xlnx,zynqmp-zcu102-revA", "xlnx,zynqmp-zcu102" > - "xlnx,zynqmp-zcu102-revB", "xlnx,zynqmp-zcu102" > - "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102" > - > -- Xilinx evaluation board zcu104 > - "xlnx,zynqmp-zcu104-revA", "xlnx,zynqmp-zcu104" > - > -- Xilinx evaluation board zcu106 > - "xlnx,zynqmp-zcu106-revA", "xlnx,zynqmp-zcu106" > - > -- Xilinx evaluation board zcu111 > - "xlnx,zynqmp-zcu111-revA", "xlnx,zynqmp-zcu111" > diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml b/Documentation/devicetree/bindings/arm/xilinx.yaml > new file mode 100644 > index 000000000000..dd227bccf015 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/xilinx.yaml > @@ -0,0 +1,81 @@ > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/arm/xilinx.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Xilinx Zynq Platforms Device Tree Bindings > + > +maintainers: > + - Michal Simek <michal.simek@xilinx.com> > + > +description: | > + Xilinx boards with Zynq-7000 SOC or Zynq UltraScale+ MPSoC > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - items: > + - enum: > + - adapteva,parallella > + - digilent,zynq-zybo > + - digilent,zynq-zybo-z7 > + - xlnx,zynq-cc108 > + - xlnx,zynq-zc702 > + - xlnx,zynq-zc706 > + - xlnx,zynq-zc770-xm010 > + - xlnx,zynq-zc770-xm011 > + - xlnx,zynq-zc770-xm012 > + - xlnx,zynq-zc770-xm013 > + - const: xlnx,zynq-7000 > + > + - items: > + - const: avnet,zynq-microzed > + - const: xlnx,zynq-microzed > + - const: xlnx,zynq-7000 > + > + - items: > + - const: avnet,zynq-zed > + - const: xlnx,zynq-zed > + - const: xlnx,zynq-7000 > + > + - items: > + - enum: > + - xlnx,zynqmp-zc1751 > + - const: xlnx,zynqmp > + > + - description: Xilinx internal board zc1232 > + items: > + - const: xlnx,zynqmp-zc1232-revA > + - const: xlnx,zynqmp-zc1232 > + - const: xlnx,zynqmp > + > + - description: Xilinx internal board zc1254 > + items: > + - const: xlnx,zynqmp-zc1254-revA > + - const: xlnx,zynqmp-zc1254 > + - const: xlnx,zynqmp > + > + - description: Xilinx internal board zc1275 > + items: > + - const: xlnx,zynqmp-zc1275-revA > + - const: xlnx,zynqmp-zc1275 > + - const: xlnx,zynqmp > + > + - description: Xilinx 96boards compatible board zcu100 > + items: > + - const: xlnx,zynqmp-zcu100-revC > + - const: xlnx,zynqmp-zcu100 > + - const: xlnx,zynqmp > + > + - description: Xilinx evaluation board zcu102 > + items: > + - enum: > + - xlnx,zynqmp-zcu102-revA > + - xlnx,zynqmp-zcu102-revB > + - xlnx,zynqmp-zcu102-rev1.0 > + - const: xlnx,zynqmp-zcu102 > + - const: xlnx,zynqmp > + > +... > Conversion looks good. I have also found that we are missing some boards when I was playing with your branch. But this can be added on the top of this patch. I have sent you separate patch for that. Also I have found that we are missing one property which can go to the tree directly and I am going to send a patch for it too. Acked-by: Michal Simek <michal.simek@xilinx.com> Thanks, Michal
On 01/11/2018 19:32, Rob Herring wrote: > On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: >> >> Hi Rob, >> >> On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: >>> Convert ARM PMU binding to DT schema format using json-schema. >>> >>> Cc: Will Deacon <will.deacon@arm.com> >>> Cc: Mark Rutland <mark.rutland@arm.com> >>> Cc: linux-arm-kernel@lists.infradead.org >>> Cc: devicetree@vger.kernel.org >>> Signed-off-by: Rob Herring <robh@kernel.org> >>> --- >>> Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- >>> .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ >>> 2 files changed, 96 insertions(+), 70 deletions(-) >>> delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt >>> create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml >> >> [...] >> >>> -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu >>> - interrupt (PPI) then 1 interrupt should be specified. >> >> [...] >> >>> + interrupts: >>> + oneOf: >>> + - maxItems: 1 >>> + - minItems: 2 >>> + maxItems: 8 >>> + description: 1 interrupt per core. >>> + >>> + interrupts-extended: >>> + $ref: '#/properties/interrupts' >> >> This seems like a semantic different between the two representations, or am >> I missing something here? Specifically, both the introduction of >> interrupts-extended and also dropping any mention of using a single per-cpu >> interrupt (the single combined case is no longer support by Linux; not sure >> if you want to keep it in the binding). > > In regards to no support for the single combined interrupt, it looks > like Marvell Armada SoCs at least (armada-375 is what I'm looking at) > have only a single interrupt. Though the interrupt gets routed to MPIC > which then has a GIC PPI. So it isn't supported or happens to work > still since it is a PPI? Well, the description of the MPIC in the Armada XP functional spec says: "Interrupt sources ID0–ID28 are private events per CPU. Thus, each processor has a different set of events map interrupts ID0–ID28." Odd grammar aside, that would seem to imply that <&mpic 3> is a per-cpu interrupt itself, thus AFAICS so long as it's cascaded to a GIC PPI and not an SPI then there's no issue there. Robin.
Hello, I'm jumping into the discussion, but I clearly don't have all the context of the discussion. On Thu, 8 Nov 2018 15:54:31 +0000, Robin Murphy wrote: > >> This seems like a semantic different between the two representations, or am > >> I missing something here? Specifically, both the introduction of > >> interrupts-extended and also dropping any mention of using a single per-cpu > >> interrupt (the single combined case is no longer support by Linux; not sure > >> if you want to keep it in the binding). > > > > In regards to no support for the single combined interrupt, it looks > > like Marvell Armada SoCs at least (armada-375 is what I'm looking at) > > have only a single interrupt. Though the interrupt gets routed to MPIC > > which then has a GIC PPI. So it isn't supported or happens to work > > still since it is a PPI? > > Well, the description of the MPIC in the Armada XP functional spec says: > > "Interrupt sources ID0–ID28 are private events per CPU. Thus, each > processor has a different set of events map interrupts ID0–ID28." > > Odd grammar aside, that would seem to imply that <&mpic 3> is a per-cpu > interrupt itself, thus AFAICS so long as it's cascaded to a GIC PPI and > not an SPI then there's no issue there. The Armada XP does not have a GIC at all, but only a MPIC as the primary interrupt controller. However the Armada 38x has both a GIC and a MPIC, and indeed the parent interrupts of the MPIC towards the GIC is: interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>; Best regards, Thomas
On 08/11/2018 15:59, Thomas Petazzoni wrote: > Hello, > > I'm jumping into the discussion, but I clearly don't have all the > context of the discussion. > > On Thu, 8 Nov 2018 15:54:31 +0000, Robin Murphy wrote: > >>>> This seems like a semantic different between the two representations, or am >>>> I missing something here? Specifically, both the introduction of >>>> interrupts-extended and also dropping any mention of using a single per-cpu >>>> interrupt (the single combined case is no longer support by Linux; not sure >>>> if you want to keep it in the binding). >>> >>> In regards to no support for the single combined interrupt, it looks >>> like Marvell Armada SoCs at least (armada-375 is what I'm looking at) >>> have only a single interrupt. Though the interrupt gets routed to MPIC >>> which then has a GIC PPI. So it isn't supported or happens to work >>> still since it is a PPI? >> >> Well, the description of the MPIC in the Armada XP functional spec says: >> >> "Interrupt sources ID0–ID28 are private events per CPU. Thus, each >> processor has a different set of events map interrupts ID0–ID28." >> >> Odd grammar aside, that would seem to imply that <&mpic 3> is a per-cpu >> interrupt itself, thus AFAICS so long as it's cascaded to a GIC PPI and >> not an SPI then there's no issue there. > > The Armada XP does not have a GIC at all, but only a MPIC as the > primary interrupt controller. > > However the Armada 38x has both a GIC and a MPIC, and indeed the parent > interrupts of the MPIC towards the GIC is: > > interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>; Yeah, perhaps I should have clarified that the XP manual was the only publicly-available one I could find, but I'm inferring from the binding and driver that the MPIC in 375/38x still behaves the same. Robin.
On Thu, Nov 8, 2018 at 2:49 AM Michal Simek <michal.simek@xilinx.com> wrote: > > Hi Rob, > > On 05. 10. 18 18:58, Rob Herring wrote: > > Convert ARM CPU binding to DT schema format using json-schema. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > Cc: devicetree@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-mediatek@lists.infradead.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/arm/cpus.txt | 490 ----------------- > > .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ > > 2 files changed, 503 insertions(+), 490 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt > > create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml [...] > I have take a look at xilinx part of this and try to build it for arm64 > platforms and I see errors coming from this cpu description. > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > cpu@0:compatible: ['arm,cortex-a53', 'arm,armv8'] is too long > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > cpu@0:compatible: Additional items are not allowed ('arm,armv8' was > unexpected) Thanks for actually giving this a spin! > Based on grep this is used in a lot of places > compatible = "arm,cortex-a53", "arm,armv8"; > > Should this be moved to just simple? > compatible = "arm,cortex-a53"; I'd normally go with the majority which would be to keep it. However, 'arm,armv8' is of questionable value, isn't actually documented, and doesn't exist for any other version of the architecture. So we should kill it IMO. Paging Mark Rutland and other arm folks... Rob
On Fri, Nov 30, 2018 at 12:00:05PM -0600, Rob Herring wrote: > On Thu, Nov 8, 2018 at 2:49 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > > Hi Rob, > > > > On 05. 10. 18 18:58, Rob Herring wrote: > > > Convert ARM CPU binding to DT schema format using json-schema. > > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > > Cc: devicetree@vger.kernel.org > > > Cc: linux-arm-kernel@lists.infradead.org > > > Cc: linux-mediatek@lists.infradead.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > > .../devicetree/bindings/arm/cpus.txt | 490 ----------------- > > > .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ > > > 2 files changed, 503 insertions(+), 490 deletions(-) > > > delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt > > > create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml > > [...] > > > I have take a look at xilinx part of this and try to build it for arm64 > > platforms and I see errors coming from this cpu description. > > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > > cpu@0:compatible: ['arm,cortex-a53', 'arm,armv8'] is too long > > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > > cpu@0:compatible: Additional items are not allowed ('arm,armv8' was > > unexpected) > > Thanks for actually giving this a spin! > > > Based on grep this is used in a lot of places > > compatible = "arm,cortex-a53", "arm,armv8"; > > > > Should this be moved to just simple? > > compatible = "arm,cortex-a53"; > > I'd normally go with the majority which would be to keep it. However, > 'arm,armv8' is of questionable value, isn't actually documented, and > doesn't exist for any other version of the architecture. So we should > kill it IMO. I'd prefer to keep it around, since that's what's used to describe the CPUs on the fastmodel iirc. Will
On Mon, Dec 3, 2018 at 6:40 AM Will Deacon <will.deacon@arm.com> wrote: > > On Fri, Nov 30, 2018 at 12:00:05PM -0600, Rob Herring wrote: > > On Thu, Nov 8, 2018 at 2:49 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > > > > Hi Rob, > > > > > > On 05. 10. 18 18:58, Rob Herring wrote: > > > > Convert ARM CPU binding to DT schema format using json-schema. > > > > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > > > Cc: devicetree@vger.kernel.org > > > > Cc: linux-arm-kernel@lists.infradead.org > > > > Cc: linux-mediatek@lists.infradead.org > > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > > --- > > > > .../devicetree/bindings/arm/cpus.txt | 490 ----------------- > > > > .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ > > > > 2 files changed, 503 insertions(+), 490 deletions(-) > > > > delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt > > > > create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml > > > > [...] > > > > > I have take a look at xilinx part of this and try to build it for arm64 > > > platforms and I see errors coming from this cpu description. > > > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > > > cpu@0:compatible: ['arm,cortex-a53', 'arm,armv8'] is too long > > > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > > > cpu@0:compatible: Additional items are not allowed ('arm,armv8' was > > > unexpected) > > > > Thanks for actually giving this a spin! > > > > > Based on grep this is used in a lot of places > > > compatible = "arm,cortex-a53", "arm,armv8"; > > > > > > Should this be moved to just simple? > > > compatible = "arm,cortex-a53"; > > > > I'd normally go with the majority which would be to keep it. However, > > 'arm,armv8' is of questionable value, isn't actually documented, and > > doesn't exist for any other version of the architecture. So we should > > kill it IMO. > > I'd prefer to keep it around, since that's what's used to describe the CPUs > on the fastmodel iirc. We can and should keep it for that purpose, but do we need it as a fallback? For real cores though, we have mixture of with and without and one of those need to be fixed. Rob
The current DT binding documentation is not ideal as it is just free form text with at most only a loose structure. This makes reviewing bindings a manual process. The bindings are often duplicating information that's already defined elsewhere and missing information one would need to validate a DTS file. The examples in binding documents are not built and a source of lots of typos sometimes found in review and sometimes not. Secondly, there's no verification that DTS files match what the documentation says. While dtc does do some checking (and has gained more recently), it can't do per binding checks as it would have to understand thousands of compatible strings to match on. There's been a number of proposals over the years to address validation. They've all suffered from inventing their own validation language and the effort it would take to fully define and flush out a validation language. Enter json-schema. The language has a defined specification, maps well to DT data, and there are numerous existing tools which can be leveraged. The actual DT schema doc files are stored as YAML using only a JSON compatible subset. YAML is considered more human readable allowing comments for example. This series adds the build support, some documentation, and converts some bindings (mostly ARM board/soc bindings). The tools, core schema, and meta-schema are in a separate repository[1]. This might eventually be integrated with dtc or added to the kernel, but for now I plan to keep it separate. Future plans/ideas: - Validate examples against the schema. Currently, they are just built with dtc. - Support single targets in addition to validating all enabled dtb targets. - Better control of which schemas to use for validation such as core only or specific lists of schemas. This will make for more easily testing new schema and filtering warnings. - Printing out nodes without any specific schema (i.e. missing schema). This series is dependent on the dt/next branch and is available here[2]. The branch also has a doc2yaml script which can help convert binding files. It's not perfect, but works pretty well considering the input is free form text. Rob [1] https://github.com/robherring/yaml-bindings [2] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git yaml-bindings Rob Herring (36): dt-bindings: arm: alpine: Move CPU control related binding to cpu-enable-method/al,alpine-smp dt-bindings: arm: amlogic: Move 'amlogic,meson-gx-ao-secure' binding to its own file dt-bindings: arm: atmel: Move various sys registers out of SoC binding doc dt-bindings: arm: fsl: Move DCFG and SCFG bindings to their own docs dt-bindings: arm: renesas: Move 'renesas,prr' binding to its own doc dt-bindings: arm: zte: Move sysctrl bindings to their own doc kbuild: Add support for DT binding schema checks dt-bindings: Add a writing DT schemas how-to and annotated example dt-bindings: Convert trivial-devices.txt to json-schema dt-bindings: altera: Convert clkmgr binding to json-schema dt-bindings: timer: Convert ARM timer bindings to json-schema dt-bindings: arm: Convert cpu binding to json-schema dt-bindings: arm: Convert PMU binding to json-schema dt-bindings: arm: Convert primecell binding to json-schema dt-bindings: arm: Convert Actions Semi bindings to jsonschema dt-bindings: arm: Convert Alpine board/soc bindings to json-schema dt-bindings: arm: Convert Altera board/soc bindings to json-schema dt-bindings: arm: Convert Amlogic board/soc bindings to json-schema dt-bindings: arm: Convert Atmel board/soc bindings to json-schema dt-bindings: arm: Convert Calxeda board/soc bindings to json-schema dt-bindings: arm: Convert TI davinci board/soc bindings to json-schema dt-bindings: arm: Convert FSL board/soc bindings to json-schema dt-bindings: arm: Convert MediaTek board/soc bindings to json-schema dt-bindings: arm: Convert TI nspire board/soc bindings to json-schema dt-bindings: arm: Convert Oxford Semi board/soc bindings to json-schema dt-bindings: arm: Convert QCom board/soc bindings to json-schema dt-bindings: arm: Convert Realtek board/soc bindings to json-schema dt-bindings: arm: Convert Rockchip board/soc bindings to json-schema dt-bindings: arm: Convert Renesas board/soc bindings to json-schema dt-bindings: arm: Convert CSR SiRF board/soc bindings to json-schema dt-bindings: arm: Convert SPEAr board/soc bindings to json-schema dt-bindings: arm: Convert ST STi board/soc bindings to json-schema dt-bindings: arm: Convert Tegra board/soc bindings to json-schema dt-bindings: arm: Convert VIA board/soc bindings to json-schema dt-bindings: arm: Convert Xilinx board/soc bindings to json-schema dt-bindings: arm: Convert ZTE board/soc bindings to json-schema .gitignore | 1 + Documentation/Makefile | 2 +- Documentation/devicetree/bindings/.gitignore | 2 + Documentation/devicetree/bindings/Makefile | 30 ++ .../devicetree/bindings/arm/actions.txt | 56 -- .../devicetree/bindings/arm/actions.yaml | 34 ++ .../devicetree/bindings/arm/al,alpine.txt | 88 --- .../devicetree/bindings/arm/al,alpine.yaml | 21 + .../devicetree/bindings/arm/altera.txt | 14 - .../devicetree/bindings/arm/altera.yaml | 20 + .../arm/altera/socfpga-clk-manager.txt | 11 - .../arm/altera/socfpga-clk-manager.yaml | 30 ++ .../devicetree/bindings/arm/amlogic.txt | 131 ----- .../devicetree/bindings/arm/amlogic.yaml | 104 ++++ .../amlogic/amlogic,meson-gx-ao-secure.txt | 28 + .../devicetree/bindings/arm/armadeus.txt | 6 - .../devicetree/bindings/arm/atmel-at91.yaml | 132 +++++ .../arm/{atmel-at91.txt => atmel-sysregs.txt} | 73 +-- Documentation/devicetree/bindings/arm/bhf.txt | 6 - .../devicetree/bindings/arm/calxeda.txt | 15 - .../devicetree/bindings/arm/calxeda.yaml | 22 + .../bindings/arm/compulab-boards.txt | 25 - .../arm/cpu-enable-method/al,alpine-smp | 34 +- .../devicetree/bindings/arm/cpus.txt | 490 ----------------- .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ .../devicetree/bindings/arm/davinci.txt | 25 - .../arm/freescale/fsl,layerscape-dcfg.txt | 19 + .../arm/freescale/fsl,layerscape-scfg.txt | 19 + Documentation/devicetree/bindings/arm/fsl.txt | 224 -------- .../devicetree/bindings/arm/fsl.yaml | 166 ++++++ .../devicetree/bindings/arm/i2se.txt | 22 - .../devicetree/bindings/arm/mediatek.txt | 79 --- .../devicetree/bindings/arm/mediatek.yaml | 85 +++ .../devicetree/bindings/arm/nspire.txt | 14 - .../devicetree/bindings/arm/olimex.txt | 10 - .../devicetree/bindings/arm/oxnas.txt | 14 - .../devicetree/bindings/arm/oxnas.yaml | 25 + Documentation/devicetree/bindings/arm/pmu.txt | 70 --- .../devicetree/bindings/arm/pmu.yaml | 96 ++++ .../devicetree/bindings/arm/primecell.txt | 46 -- .../devicetree/bindings/arm/primecell.yaml | 35 ++ .../devicetree/bindings/arm/qcom.txt | 57 -- .../devicetree/bindings/arm/qcom.yaml | 125 +++++ .../devicetree/bindings/arm/realtek.txt | 22 - .../devicetree/bindings/arm/realtek.yaml | 25 + .../devicetree/bindings/arm/renesas,prr.txt | 18 + .../devicetree/bindings/arm/rockchip.txt | 220 -------- .../devicetree/bindings/arm/rockchip.yaml | 242 +++++++++ .../devicetree/bindings/arm/shmobile.txt | 161 ------ .../devicetree/bindings/arm/shmobile.yaml | 205 +++++++ .../devicetree/bindings/arm/sirf.txt | 11 - .../devicetree/bindings/arm/sirf.yaml | 27 + .../devicetree/bindings/arm/spear.txt | 26 - .../devicetree/bindings/arm/spear.yaml | 25 + Documentation/devicetree/bindings/arm/sti.txt | 23 - .../devicetree/bindings/arm/sti.yaml | 23 + .../devicetree/bindings/arm/technologic.txt | 23 - .../devicetree/bindings/arm/tegra.txt | 60 --- .../devicetree/bindings/arm/tegra.yaml | 88 +++ .../devicetree/bindings/arm/ti/nspire.yaml | 24 + .../bindings/arm/ti/ti,davinci.yaml | 26 + .../devicetree/bindings/arm/vt8500.txt | 22 - .../devicetree/bindings/arm/vt8500.yaml | 23 + .../devicetree/bindings/arm/xilinx.txt | 83 --- .../devicetree/bindings/arm/xilinx.yaml | 81 +++ .../bindings/arm/{zte.txt => zte-sysctrl.txt} | 15 +- .../devicetree/bindings/arm/zte.yaml | 26 + .../devicetree/bindings/example-schema.yaml | 155 ++++++ .../bindings/timer/arm,arch_timer.txt | 112 ---- .../bindings/timer/arm,arch_timer.yaml | 103 ++++ .../bindings/timer/arm,arch_timer_mmio.yaml | 120 +++++ .../bindings/timer/arm,global_timer.txt | 27 - .../bindings/timer/arm,global_timer.yaml | 46 ++ .../devicetree/bindings/trivial-devices.txt | 201 ------- .../devicetree/bindings/trivial-devices.yaml | 414 ++++++++++++++ Documentation/devicetree/writing-schema.md | 111 ++++ Makefile | 8 +- scripts/Makefile.lib | 24 +- 78 files changed, 3344 insertions(+), 2485 deletions(-) create mode 100644 Documentation/devicetree/bindings/.gitignore create mode 100644 Documentation/devicetree/bindings/Makefile delete mode 100644 Documentation/devicetree/bindings/arm/actions.txt create mode 100644 Documentation/devicetree/bindings/arm/actions.yaml delete mode 100644 Documentation/devicetree/bindings/arm/al,alpine.txt create mode 100644 Documentation/devicetree/bindings/arm/al,alpine.yaml delete mode 100644 Documentation/devicetree/bindings/arm/altera.txt create mode 100644 Documentation/devicetree/bindings/arm/altera.yaml delete mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml delete mode 100644 Documentation/devicetree/bindings/arm/amlogic.txt create mode 100644 Documentation/devicetree/bindings/arm/amlogic.yaml create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt delete mode 100644 Documentation/devicetree/bindings/arm/armadeus.txt create mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.yaml rename Documentation/devicetree/bindings/arm/{atmel-at91.txt => atmel-sysregs.txt} (67%) delete mode 100644 Documentation/devicetree/bindings/arm/bhf.txt delete mode 100644 Documentation/devicetree/bindings/arm/calxeda.txt create mode 100644 Documentation/devicetree/bindings/arm/calxeda.yaml delete mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml delete mode 100644 Documentation/devicetree/bindings/arm/davinci.txt create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt delete mode 100644 Documentation/devicetree/bindings/arm/fsl.txt create mode 100644 Documentation/devicetree/bindings/arm/fsl.yaml delete mode 100644 Documentation/devicetree/bindings/arm/i2se.txt delete mode 100644 Documentation/devicetree/bindings/arm/mediatek.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek.yaml delete mode 100644 Documentation/devicetree/bindings/arm/nspire.txt delete mode 100644 Documentation/devicetree/bindings/arm/olimex.txt delete mode 100644 Documentation/devicetree/bindings/arm/oxnas.txt create mode 100644 Documentation/devicetree/bindings/arm/oxnas.yaml delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml delete mode 100644 Documentation/devicetree/bindings/arm/primecell.txt create mode 100644 Documentation/devicetree/bindings/arm/primecell.yaml delete mode 100644 Documentation/devicetree/bindings/arm/qcom.txt create mode 100644 Documentation/devicetree/bindings/arm/qcom.yaml delete mode 100644 Documentation/devicetree/bindings/arm/realtek.txt create mode 100644 Documentation/devicetree/bindings/arm/realtek.yaml create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.txt delete mode 100644 Documentation/devicetree/bindings/arm/rockchip.txt create mode 100644 Documentation/devicetree/bindings/arm/rockchip.yaml delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml delete mode 100644 Documentation/devicetree/bindings/arm/sirf.txt create mode 100644 Documentation/devicetree/bindings/arm/sirf.yaml delete mode 100644 Documentation/devicetree/bindings/arm/spear.txt create mode 100644 Documentation/devicetree/bindings/arm/spear.yaml delete mode 100644 Documentation/devicetree/bindings/arm/sti.txt create mode 100644 Documentation/devicetree/bindings/arm/sti.yaml delete mode 100644 Documentation/devicetree/bindings/arm/technologic.txt delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml create mode 100644 Documentation/devicetree/bindings/arm/ti/nspire.yaml create mode 100644 Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml delete mode 100644 Documentation/devicetree/bindings/arm/vt8500.txt create mode 100644 Documentation/devicetree/bindings/arm/vt8500.yaml delete mode 100644 Documentation/devicetree/bindings/arm/xilinx.txt create mode 100644 Documentation/devicetree/bindings/arm/xilinx.yaml rename Documentation/devicetree/bindings/arm/{zte.txt => zte-sysctrl.txt} (62%) create mode 100644 Documentation/devicetree/bindings/arm/zte.yaml create mode 100644 Documentation/devicetree/bindings/example-schema.yaml delete mode 100644 Documentation/devicetree/bindings/timer/arm,arch_timer.txt create mode 100644 Documentation/devicetree/bindings/timer/arm,arch_timer.yaml create mode 100644 Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml delete mode 100644 Documentation/devicetree/bindings/timer/arm,global_timer.txt create mode 100644 Documentation/devicetree/bindings/timer/arm,global_timer.yaml delete mode 100644 Documentation/devicetree/bindings/trivial-devices.txt create mode 100644 Documentation/devicetree/bindings/trivial-devices.yaml create mode 100644 Documentation/devicetree/writing-schema.md -- 2.17.1