03.07.2019 16:22, Rob Herring пишет: > 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. Works like a charm! Thank you very much.
