On Tue, Jul 2, 2019 at 6:48 PM Dmitry Osipenko <digetx@xxxxxxxxx> wrote: > > 01.07.2019 22:30, Dmitry Osipenko пишет: > > 01.07.2019 22:11, Rob Herring пишет: > >> On Sun, Jun 30, 2019 at 3:04 PM Dmitry Osipenko <digetx@xxxxxxxxx> wrote: > >>> > >> > >> "Convert" implies you delete the old binding doc. > > > > Yes, unfortunately the deletion got lost by accident after rebase and it was already > > too late when I noticed that. Will be fixed in the next revision. > > > >>> The Tegra30 binding will actually differ from the Tegra124 a tad, in > >>> particular the EMEM configuration description. Hence rename the binding > >>> to Tegra124 during of the conversion to YAML. > >>> > >>> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx> > >>> --- > >>> .../nvidia,tegra124-mc.yaml | 149 ++++++++++++++++++ > >>> 1 file changed, 149 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml > >>> > >>> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml > >>> new file mode 100644 > >>> index 000000000000..d18242510295 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml > >>> @@ -0,0 +1,149 @@ > >>> +# SPDX-License-Identifier: (GPL-2.0) > >>> +%YAML 1.2 > >>> +--- > >>> +$id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra124-mc.yaml# > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>> + > >>> +title: > >>> + NVIDIA Tegra124 SoC Memory Controller > >>> + > >>> +maintainers: > >>> + - Jon Hunter <jonathanh@xxxxxxxxxx> > >>> + - Thierry Reding <thierry.reding@xxxxxxxxx> > >>> + > >>> +description: | > >>> + Tegra124 SoC features a hybrid 2x32-bit / 1x64-bit memory controller. > >>> + These are interleaved to provide high performance with the load shared across > >>> + two memory channels. The Tegra124 Memory Controller handles memory requests > >>> + from internal clients and arbitrates among them to allocate memory bandwidth > >>> + for DDR3L and LPDDR3 SDRAMs. > >>> + > >>> +properties: > >>> + compatible: > >>> + const: nvidia,tegra124-mc > >>> + > >>> + reg: > >>> + maxItems: 1 > >>> + description: > >>> + Physical base address. > >>> + > >>> + clocks: > >>> + maxItems: 1 > >>> + description: > >>> + Memory Controller clock. > >>> + > >>> + clock-names: > >>> + items: > >>> + - const: mc > >>> + > >>> + interrupts: > >>> + maxItems: 1 > >>> + description: > >>> + Memory Controller interrupt. > >>> + > >>> + "#reset-cells": > >>> + const: 1 > >>> + > >>> + "#iommu-cells": > >>> + const: 1 > >>> + > >>> +patternProperties: > >>> + ".*": > >> > >> Please define a node name or pattern for node names. > > > > There was no pattern specified in the original binding. But I guess the existing > > upstream device-trees could be used as the source for the pattern. > > Actually it looks like the use of explicit pattern is not really a good idea because > device-tree could have node named in a way that it doesn't match the pattern and hence > dtbs_check silently skips the non-matching nodes. Is there any way to express that > non-matching nodes shall be rejected? additionalProperties: false It's not ideal because you have to list all properties and can't combine multiple schema, but that's getting addressed in json-schema draft8. That shouldn't matter for you in this case though. Rob
