| Message ID | 20210806123450.2970777-2-mperttunen@nvidia.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2,1/3] dt-bindings: Add YAML bindings for Host1x and NVDEC | expand |
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@nvidia.com> > --- > 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@gmail.com> > + - Mikko Perttunen <mperttunen@nvidia.com> > + > +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
On Tue, Aug 10, 2021 at 05:43:26PM +0200, Thierry Reding wrote: > On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote: [...] > > diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml [...] > > +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. Oh, nevermind, upon closer inspection, I do see it used in the driver. Thierry
On 10.8.2021 18.43, Thierry Reding wrote: > 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@nvidia.com> >> --- >> 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? Sure. I thought I had some problems with this before but can't see any now. > >> 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@gmail.com> >> + - Mikko Perttunen <mperttunen@nvidia.com> >> + >> +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". Will fix. > >> + - 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? I can add such a comment if desired. Honestly, I don't really know what 'unevaluatedProperties' means or does -- the explanation in example-schema.yaml doesn't seem like it's relevant here and I cannot find any other documentation. Thanks, Mikko > > 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 >
On Tue, Aug 10, 2021 at 06:50:26PM +0300, Mikko Perttunen wrote: > On 10.8.2021 18.43, Thierry Reding wrote: > > 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@nvidia.com> > > > --- > > > 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? > > Sure. I thought I had some problems with this before but can't see any now. > > > > > > 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@gmail.com> > > > + - Mikko Perttunen <mperttunen@nvidia.com> > > > + > > > +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". > > Will fix. > > > > > > + - 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? > > I can add such a comment if desired. Honestly, I don't really know what > 'unevaluatedProperties' means or does -- the explanation in > example-schema.yaml doesn't seem like it's relevant here and I cannot find > any other documentation. It's basically like additionalProperties, except that it applies to properties evaluated via if: blocks. So with additionalProperties: false, the presence of the nvidia,instance property in a Tegra194 DTS file would cause a validation failure because it's a property that was not defined in the properties: block. With unevaluatedProperties: false, on the other hand, the properties that are defined in the if: block above will become a evaluated properties and therefore a Tegra194 DTS with the nvidia,instance property present would succeed validation. Unless, of course, if it contained additional properties that are not defined in any of the properties: blocks (either unconditional or conditional ones). So in other words, the additionalProperties schema applies to all unconditionally defined properties, whereas unevaluatedProperties applies to all (conditionally and unconditionally) defined properties. Thierry
On Tue, Aug 10, 2021 at 06:10:43PM +0200, Thierry Reding wrote: > On Tue, Aug 10, 2021 at 06:50:26PM +0300, Mikko Perttunen wrote: > > On 10.8.2021 18.43, Thierry Reding wrote: > > > 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@nvidia.com> > > > > --- > > > > 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? > > > > Sure. I thought I had some problems with this before but can't see any now. > > > > > > > > > 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@gmail.com> > > > > + - Mikko Perttunen <mperttunen@nvidia.com> > > > > + > > > > +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". > > > > Will fix. > > > > > > > > > + - 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? Use 'unevaluatedProperties: false'. There's support in jsonschema pkg master now, so we should have support working soon. I've run it with the kernel tree as well. I was surprised there weren't many issues... 'additionalProperties: true' should only ever be used for incomplete collections of properties (i.e. common bindings). I haven't come up with a meta-schema to check this. We'd probably need to point to different meta-schemas. > > > > I can add such a comment if desired. Honestly, I don't really know what > > 'unevaluatedProperties' means or does -- the explanation in > > example-schema.yaml doesn't seem like it's relevant here and I cannot find > > any other documentation. > > It's basically like additionalProperties, except that it applies to > properties evaluated via if: blocks. > > So with additionalProperties: false, the presence of the nvidia,instance > property in a Tegra194 DTS file would cause a validation failure because > it's a property that was not defined in the properties: block. > > With unevaluatedProperties: false, on the other hand, the properties > that are defined in the if: block above will become a evaluated > properties and therefore a Tegra194 DTS with the nvidia,instance > property present would succeed validation. Unless, of course, if it > contained additional properties that are not defined in any of the > properties: blocks (either unconditional or conditional ones). > > So in other words, the additionalProperties schema applies to all > unconditionally defined properties, whereas unevaluatedProperties > applies to all (conditionally and unconditionally) defined properties. I generally discourage only defining the properties in an if/then. Partly because unevaluatedProperties wasn't implemented. I guess if a property is only allowed in the 'then' case, it makes sense. But if the property is just different constraints for then and else, then I'd define it in the main section. Rob
diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml new file mode 100644 index 000000000000..5344524c26d1 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra20-host1x.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Device tree binding for NVIDIA Host1x + +maintainers: + - Thierry Reding <treding@gmail.com> + - Mikko Perttunen <mperttunen@nvidia.com> + +properties: + $nodename: + pattern: "^host1x@[0-9a-f]*$" + + compatible: + oneOf: + - enum: + - nvidia,tegra20-host1x + - nvidia,tegra30-host1x + - nvidia,tegra114-host1x + - nvidia,tegra124-host1x + - nvidia,tegra210-host1x + - items: + - const: nvidia,tegra132-host1x + - const: nvidia,tegra124-host1x + + interrupts: + items: + - description: Syncpoint threshold interrupt + - description: General interrupt + + interrupt-names: + items: + - const: syncpt + - const: host1x + + clocks: + maxItems: 1 + + clock-names: + items: + - const: host1x + + resets: + maxItems: 1 + + reset-names: + items: + - const: host1x + + iommus: + maxItems: 1 + + interconnects: + maxItems: 1 + + interconnect-names: + items: + - const: dma-mem + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true + +required: + - compatible + - interrupts + - interrupt-names + - clocks + - clock-names + - resets + - reset-names + - '#address-cells' + - '#size-cells' + - ranges + +if: + properties: + compatible: + enum: + - nvidia,tegra186-host1x + - nvidia,tegra194-host1x +then: + properties: + reg: + items: + - description: Hypervisor-accessible register area + - description: VM-accessible register area + reg-names: + items: + - const: hypervisor + - const: vm + required: + - reg + - reg-names +else: + properties: + reg: + maxItems: 1 + required: + - reg + +additionalProperties: true + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + host1x@50000000 { + compatible = "nvidia,tegra20-host1x"; + reg = <0x50000000 0x00024000>; + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>, /* syncpt */ + <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; /* general */ + interrupt-names = "syncpt", "host1x"; + clocks = <&tegra_car TEGRA20_CLK_HOST1X>; + clock-names = "host1x"; + resets = <&tegra_car 28>; + reset-names = "host1x"; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + }; 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@gmail.com> + - Mikko Perttunen <mperttunen@nvidia.com> + +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 + - 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 + +additionalProperties: true + +examples: + - | + #include <dt-bindings/clock/tegra186-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra186-mc.h> + #include <dt-bindings/power/tegra186-powergate.h> + #include <dt-bindings/reset/tegra186-reset.h> + + nvdec@15480000 { + compatible = "nvidia,tegra186-nvdec"; + reg = <0x15480000 0x40000>; + clocks = <&bpmp TEGRA186_CLK_NVDEC>; + clock-names = "nvdec"; + resets = <&bpmp TEGRA186_RESET_NVDEC>; + reset-names = "nvdec"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_NVDEC>; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVDECSRD &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVDECSRD1 &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVDECSWR &emc>; + interconnect-names = "dma-mem", "read2", "write"; + iommus = <&smmu TEGRA186_SID_NVDEC>; + }; + + diff --git a/MAINTAINERS b/MAINTAINERS index 69932194e1ba..ce9e360639d5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6230,6 +6230,7 @@ L: linux-tegra@vger.kernel.org S: Supported T: git git://anongit.freedesktop.org/tegra/linux.git F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +F: Documentation/devicetree/bindings/gpu/host1x/ F: drivers/gpu/drm/tegra/ F: drivers/gpu/host1x/ F: include/linux/host1x.h
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@nvidia.com> --- 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