On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote: > Convert the original Host1x bindings to YAML and add new bindings for > NVDEC, now in a more appropriate location. The old text bindings > for Host1x and engines are still kept at display/tegra/ since they > encompass a lot more engines that haven't been converted over yet. > > Signed-off-by: Mikko Perttunen <mperttunen@xxxxxxxxxx> > --- > v2: > * Fix issues pointed out in v1 > * Add T194 nvidia,instance property > --- > .../gpu/host1x/nvidia,tegra20-host1x.yaml | 131 ++++++++++++++++++ > .../gpu/host1x/nvidia,tegra210-nvdec.yaml | 109 +++++++++++++++ > MAINTAINERS | 1 + > 3 files changed, 241 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml > create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml Can we split off the NVDEC bindings addition into a separate patch? I've been working on converting the existing host1x bindings in full to json- schema and this partial conversion would conflict with that effort. I assume that NVDEC itself validates properly even if host1x hasn't been converted yet? > diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > new file mode 100644 > index 000000000000..fc535bb7aee0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > @@ -0,0 +1,109 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#"; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > + > +title: Device tree binding for NVIDIA Tegra NVDEC > + > +description: | > + NVDEC is the hardware video decoder present on NVIDIA Tegra210 > + and newer chips. It is located on the Host1x bus and typically > + programmed through Host1x channels. > + > +maintainers: > + - Thierry Reding <treding@xxxxxxxxx> > + - Mikko Perttunen <mperttunen@xxxxxxxxxx> > + > +properties: > + $nodename: > + pattern: "^nvdec@[0-9a-f]*$" > + > + compatible: > + enum: > + - nvidia,tegra210-nvdec > + - nvidia,tegra186-nvdec > + - nvidia,tegra194-nvdec > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + clock-names: > + items: > + - const: nvdec > + > + resets: > + maxItems: 1 > + > + reset-names: > + items: > + - const: nvdec > + > + power-domains: > + maxItems: 1 > + > + iommus: > + maxItems: 1 > + > + interconnects: > + items: > + - description: DMA read memory client > + - description: DMA read 2 memory client > + - description: DMA write memory client > + > + interconnect-names: > + items: > + - const: dma-mem > + - const: read2 The convention that we've used so far has been to start numbering these at 0 and use a dash, so this would be "read-1". > + - const: write > + > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - resets > + - reset-names > + - power-domains > + > +if: > + properties: > + compatible: > + contains: > + const: nvidia,tegra194-host1x > +then: > + properties: > + nvidia,instance: > + items: > + - description: 0 for NVDEC0, or 1 for NVDEC1 I know we had discussed this before, but looking at the driver patch, I don't actually see this being used now, so I wonder if we still need it. > +additionalProperties: true Maybe this should have a comment noting that this should really be unevaluatedProperties: false, but we can't use that because the tooling doesn't support it yet? Rob, what's the current best practice for that? I see that there are quite a few bindings that use unevaluatedProperties, so I wonder if we just ignore errors from that for now? Or do we have some development branch of the tooling somewhere that supports this now? I vaguely recall reading about work in progress patches for this, but I can't find the link now to see if there's been an update since I last looked. Thierry
Attachment:
signature.asc
Description: PGP signature
