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?
