From: Paul-pl Chen <paul-pl.chen@mediatek.com>
Add mediatek,exdma.yaml to support EXDMA for MT8196.
The MediaTek display overlap extended DMA engine, namely
OVL_EXDMA or EXDMA, primarily functions as a DMA engine
for reading data from DRAM with various DRAM footprints
and data formats.
Signed-off-by: Paul-pl Chen <paul-pl.chen@mediatek.com>
---
.../bindings/dma/mediatek,exdma.yaml | 68 +++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
diff --git a/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml b/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
new file mode 100644
index 000000000000..eabf0cfc839e
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/mediatek,exdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek display overlap extended DMA engine
+
+maintainers:
+ - Chun-Kuang Hu <chunkuang.hu@kernel.org>
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+description:
+ The MediaTek display overlap extended DMA engine, namely OVL_EXDMA or EXDMA,
+ primarily functions as a DMA engine for reading data from DRAM with various
+ DRAM footprints and data formats. For input sources in certain color formats
+ and color domains, OVL_EXDMA also includes a color transfer function
+ to process pixels into a consistent color domain.
+
+properties:
+ compatible:
+ const: mediatek,mt8196-exdma
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ A phandle to the local arbiters node in the current SoCs.
+ Refer to bindings/memory-controllers/mediatek,smi-larb.yaml.
+
+ iommus:
+ maxItems: 1
+
+ '#dma-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - power-domains
+ - mediatek,larb
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ exdma: dma-controller@32850000 {
+ compatible = "mediatek,mt8196-exdma";
+ reg = <0 0x32850000 0 0x1000>;
+ clocks = <&ovlsys_config_clk 13>;
+ power-domains = <&hfrpsys 12>;
+ iommus = <&mm_smmu 144>;
+ #dma-cells = <1>;
+ };
+ };
--
2.45.2Hi, Rob and Krzysztof:
On Thu, 2025-08-28 at 16:06 +0800, Paul Chen wrote:
> From: Paul-pl Chen <paul-pl.chen@mediatek.com>
>
> Add mediatek,exdma.yaml to support EXDMA for MT8196.
> The MediaTek display overlap extended DMA engine, namely
> OVL_EXDMA or EXDMA, primarily functions as a DMA engine
> for reading data from DRAM with various DRAM footprints
> and data formats.
>
> Signed-off-by: Paul-pl Chen <paul-pl.chen@mediatek.com>
> ---
> .../bindings/dma/mediatek,exdma.yaml | 68 +++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml b/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
> new file mode 100644
> index 000000000000..eabf0cfc839e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/dma/mediatek,exdma.yaml*__;Iw!!CTRNKA9wMg0ARbw!mjQH2qNKhXsl47d3xz2_Qmo7Wadq5-kD0GJaAVjh7XY8W3NgI_dDpBNinME7NVW1PKdO9IEUsObOTugjypqo5j8$
> +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!mjQH2qNKhXsl47d3xz2_Qmo7Wadq5-kD0GJaAVjh7XY8W3NgI_dDpBNinME7NVW1PKdO9IEUsObOTugj3hMMPhU$
> +
> +title: MediaTek display overlap extended DMA engine
> +
> +maintainers:
> + - Chun-Kuang Hu <chunkuang.hu@kernel.org>
> + - Philipp Zabel <p.zabel@pengutronix.de>
> +
> +description:
> + The MediaTek display overlap extended DMA engine, namely OVL_EXDMA or EXDMA,
> + primarily functions as a DMA engine for reading data from DRAM with various
> + DRAM footprints and data formats. For input sources in certain color formats
> + and color domains, OVL_EXDMA also includes a color transfer function
> + to process pixels into a consistent color domain.
> +
> +properties:
> + compatible:
> + const: mediatek,mt8196-exdma
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + mediatek,larb:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: |
> + A phandle to the local arbiters node in the current SoCs.
> + Refer to bindings/memory-controllers/mediatek,smi-larb.yaml.
In MT8196, the data path that EXDMA access DRAM data is shown below.
EXDMA (dma device) <-> LARB <-> SMMU (mmu device) <-> DRAM
In MT8195, the data path that OVL access DRAM data is shown below.
OVL (dma device) <-> LARB <-> IOMMU_VPP (mmu device) <-> DRAM
These two are similar, and LARB works like a bus.
In MT8195 device tree [1] (upstream), OVL has an iommus property pointing to IOMMU_VPP,
and IOMMU_VPP has a larbs property pointing to LARB
iommu_vpp: iommu@14018000 {
compatible = "mediatek,mt8195-iommu-vpp";
reg = <0 0x14018000 0 0x1000>;
mediatek,larbs = <&larb1 &larb3 &larb4 &larb6 &larb8
&larb12 &larb14 &larb16 &larb18
&larb20 &larb22 &larb23 &larb26
&larb27>;
interrupts = <GIC_SPI 594 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&vppsys0 CLK_VPP0_SMI_IOMMU>;
clock-names = "bclk";
#iommu-cells = <1>;
power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>;
};
display@14009000 {
compatible = "mediatek,mt8195-mdp3-ovl";
reg = <0 0x14009000 0 0x1000>;
interrupts = <GIC_SPI 586 IRQ_TYPE_LEVEL_HIGH 0>;
mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x9000 0x1000>;
clocks = <&vppsys0 CLK_VPP0_MDP_OVL>;
power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>;
iommus = <&iommu_vpp M4U_PORT_L4_MDP_OVL>;
};
In MT8196 [2] (this patch), EXDMA has an iommus property pointing to SMMU and a larbs property pointing to LARB.
mm_smmu: iommu@30800000 {
compatible = "mediatek,mt8196-mm-smmu", "arm,smmu-v3";
reg = <0 0x30800000 0 0x1e0000>;
interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING 0>;
interrupt-names = "combined";
#iommu-cells = <1>;
};
disp_ovl0_exdma2: dma-controller@32850000 {
compatible = "mediatek,mt8196-exdma";
reg = <0 0x32850000 0 0x1000>;
clocks = <&ovlsys_config_clk CLK_OVL_EXDMA2_DISP>;
power-domains = <&hfrpsys MT8196_POWER_DOMAIN_OVL0_DORMANT>;
mediatek,larb = <&smi_larb0>;
iommus = <&mm_smmu 144>;
#dma-cells = <1>;
};
Both hardware data path is similar, but LARB is pointed by IOMMU device in MT8195 and LARB is pointed by DMA device in MT8196.
Should LARB be pointed by the same device (DMA device or IOMMU device)?
Or another way to describe these three device?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/mediatek/mt8195.dtsi?h=next-20250626
[2] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/6253459/2/arch/arm64/boot/dts/mediatek/mt8196.dtsi#3127
Regards,
CK
> +
> + iommus:
> + maxItems: 1
> +
> + '#dma-cells':
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - power-domains
> + - mediatek,larb
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + exdma: dma-controller@32850000 {
> + compatible = "mediatek,mt8196-exdma";
> + reg = <0 0x32850000 0 0x1000>;
> + clocks = <&ovlsys_config_clk 13>;
> + power-domains = <&hfrpsys 12>;
> + iommus = <&mm_smmu 144>;
> + #dma-cells = <1>;
> + };
> + };
Il 18/09/25 09:01, CK Hu (胡俊光) ha scritto:
> Hi, Rob and Krzysztof:
>
> On Thu, 2025-08-28 at 16:06 +0800, Paul Chen wrote:
>> From: Paul-pl Chen <paul-pl.chen@mediatek.com>
>>
>> Add mediatek,exdma.yaml to support EXDMA for MT8196.
>> The MediaTek display overlap extended DMA engine, namely
>> OVL_EXDMA or EXDMA, primarily functions as a DMA engine
>> for reading data from DRAM with various DRAM footprints
>> and data formats.
>>
>> Signed-off-by: Paul-pl Chen <paul-pl.chen@mediatek.com>
>> ---
>> .../bindings/dma/mediatek,exdma.yaml | 68 +++++++++++++++++++
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml b/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
>> new file mode 100644
>> index 000000000000..eabf0cfc839e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/mediatek,exdma.yaml
>> @@ -0,0 +1,68 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/dma/mediatek,exdma.yaml*__;Iw!!CTRNKA9wMg0ARbw!mjQH2qNKhXsl47d3xz2_Qmo7Wadq5-kD0GJaAVjh7XY8W3NgI_dDpBNinME7NVW1PKdO9IEUsObOTugjypqo5j8$
>> +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!mjQH2qNKhXsl47d3xz2_Qmo7Wadq5-kD0GJaAVjh7XY8W3NgI_dDpBNinME7NVW1PKdO9IEUsObOTugj3hMMPhU$
>> +
>> +title: MediaTek display overlap extended DMA engine
>> +
>> +maintainers:
>> + - Chun-Kuang Hu <chunkuang.hu@kernel.org>
>> + - Philipp Zabel <p.zabel@pengutronix.de>
>> +
>> +description:
>> + The MediaTek display overlap extended DMA engine, namely OVL_EXDMA or EXDMA,
>> + primarily functions as a DMA engine for reading data from DRAM with various
>> + DRAM footprints and data formats. For input sources in certain color formats
>> + and color domains, OVL_EXDMA also includes a color transfer function
>> + to process pixels into a consistent color domain.
>> +
>> +properties:
>> + compatible:
>> + const: mediatek,mt8196-exdma
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + power-domains:
>> + maxItems: 1
>> +
>> + mediatek,larb:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description: |
>> + A phandle to the local arbiters node in the current SoCs.
>> + Refer to bindings/memory-controllers/mediatek,smi-larb.yaml.
>
> In MT8196, the data path that EXDMA access DRAM data is shown below.
>
> EXDMA (dma device) <-> LARB <-> SMMU (mmu device) <-> DRAM
>
> In MT8195, the data path that OVL access DRAM data is shown below.
>
> OVL (dma device) <-> LARB <-> IOMMU_VPP (mmu device) <-> DRAM
>
> These two are similar, and LARB works like a bus.
>
> In MT8195 device tree [1] (upstream), OVL has an iommus property pointing to IOMMU_VPP,
>
> and IOMMU_VPP has a larbs property pointing to LARB
>
> iommu_vpp: iommu@14018000 {
>
> compatible = "mediatek,mt8195-iommu-vpp";
>
> reg = <0 0x14018000 0 0x1000>;
>
> mediatek,larbs = <&larb1 &larb3 &larb4 &larb6 &larb8
>
> &larb12 &larb14 &larb16 &larb18
>
> &larb20 &larb22 &larb23 &larb26
>
> &larb27>;
>
> interrupts = <GIC_SPI 594 IRQ_TYPE_LEVEL_HIGH 0>;
>
> clocks = <&vppsys0 CLK_VPP0_SMI_IOMMU>;
>
> clock-names = "bclk";
>
> #iommu-cells = <1>;
>
> power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>;
>
> };
>
> display@14009000 {
>
> compatible = "mediatek,mt8195-mdp3-ovl";
>
> reg = <0 0x14009000 0 0x1000>;
>
> interrupts = <GIC_SPI 586 IRQ_TYPE_LEVEL_HIGH 0>;
>
> mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x9000 0x1000>;
>
> clocks = <&vppsys0 CLK_VPP0_MDP_OVL>;
>
> power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>;
>
> iommus = <&iommu_vpp M4U_PORT_L4_MDP_OVL>;
>
> };
>
> In MT8196 [2] (this patch), EXDMA has an iommus property pointing to SMMU and a larbs property pointing to LARB.
>
> mm_smmu: iommu@30800000 {
>
> compatible = "mediatek,mt8196-mm-smmu", "arm,smmu-v3";
>
> reg = <0 0x30800000 0 0x1e0000>;
>
> interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING 0>;
>
> interrupt-names = "combined";
>
> #iommu-cells = <1>;
>
> };
>
> disp_ovl0_exdma2: dma-controller@32850000 {
>
> compatible = "mediatek,mt8196-exdma";
>
> reg = <0 0x32850000 0 0x1000>;
>
> clocks = <&ovlsys_config_clk CLK_OVL_EXDMA2_DISP>;
>
> power-domains = <&hfrpsys MT8196_POWER_DOMAIN_OVL0_DORMANT>;
>
> mediatek,larb = <&smi_larb0>;
>
> iommus = <&mm_smmu 144>;
>
> #dma-cells = <1>;
>
> };
>
> Both hardware data path is similar, but LARB is pointed by IOMMU device in MT8195 and LARB is pointed by DMA device in MT8196.
>
> Should LARB be pointed by the same device (DMA device or IOMMU device)?
>
> Or another way to describe these three device?
>
Read dt-bindings/iommu/mediatek,iommu.yaml for a nice block diagram from Yong Wu:
as explained, the Local Arbiters are arbitering multimedia IP block memory access
between either IOMMU translation or EMI DMA.
This means that the LARBs need knowledge of both the INPUT device (EXDMA) and of
the possible diverting paths (SMI, or IOMMU).
What has been done in previous platforms is a borderline (but imo, acceptable for
multiple reasons) almost-hack, done to avoid having a vendor property on each of
the nodes and to avoid overcomplicating the actual code, as if the LARB is a child
of IOMMU, it can get knowledge of the translation tables (and since LARBs come from
SMI, those also have knowledge of SMI properties).
For this reason, I agree with CK and I would also suggest to still go with LARBs
assigned to IOMMU, as this eliminates all those vendor-specific properties from so
many devicetree nodes, makes code simpler, and also works with PM (larbs need smi
clocked/powered and iommu clocked/powered in order to work correctly), mimicking
the same devicetree structure as the previous SoCs.
Besides - as far as I know, hardware-wise the tree is very very similar anyway.
Cheers,
Angelo
>
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/mediatek/mt8195.dtsi?h=next-20250626
>
> [2] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/6253459/2/arch/arm64/boot/dts/mediatek/mt8196.dtsi#3127
>
>
>
> Regards,
>
> CK
>
>> +
>> + iommus:
>> + maxItems: 1
>> +
>> + '#dma-cells':
>> + const: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> + - power-domains
>> + - mediatek,larb
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + exdma: dma-controller@32850000 {
>> + compatible = "mediatek,mt8196-exdma";
>> + reg = <0 0x32850000 0 0x1000>;
>> + clocks = <&ovlsys_config_clk 13>;
>> + power-domains = <&hfrpsys 12>;
>> + iommus = <&mm_smmu 144>;
>> + #dma-cells = <1>;
>> + };
>> + };
>
On Thu, Aug 28, 2025 at 04:06:58PM +0800, Paul Chen wrote: > From: Paul-pl Chen <paul-pl.chen@mediatek.com> > > Add mediatek,exdma.yaml to support EXDMA for MT8196. > The MediaTek display overlap extended DMA engine, namely > OVL_EXDMA or EXDMA, primarily functions as a DMA engine > for reading data from DRAM with various DRAM footprints > and data formats. > > Signed-off-by: Paul-pl Chen <paul-pl.chen@mediatek.com> > --- > .../bindings/dma/mediatek,exdma.yaml | 68 +++++++++++++++++++ Your changelog says NOTHING changed here and this fails tests, so does it mean you received that warnings before but you keep sending same broken code? Last two weeks of contributions from mediatek are absolutely terrible. Very poor code, basic in-house reviews not done, basic testing not done. I talked about this at OSSE 25 with some friends and got reasons why your setup is broken. Well, it's on you. I was already raising this with Mediatek, but we are now back to square one. NAK, because this patch WAS NEVER tested. Best regards, Krzysztof
On Fri, Aug 29, 2025 at 08:35:23AM +0200, Krzysztof Kozlowski wrote: > On Thu, Aug 28, 2025 at 04:06:58PM +0800, Paul Chen wrote: > > From: Paul-pl Chen <paul-pl.chen@mediatek.com> > > > > Add mediatek,exdma.yaml to support EXDMA for MT8196. > > The MediaTek display overlap extended DMA engine, namely > > OVL_EXDMA or EXDMA, primarily functions as a DMA engine > > for reading data from DRAM with various DRAM footprints > > and data formats. > > > > Signed-off-by: Paul-pl Chen <paul-pl.chen@mediatek.com> > > --- > > .../bindings/dma/mediatek,exdma.yaml | 68 +++++++++++++++++++ > > > Your changelog says NOTHING changed here and this fails tests, so does it > mean you received that warnings before but you keep sending same broken > code? > > Last two weeks of contributions from mediatek are absolutely terrible. > Very poor code, basic in-house reviews not done, basic testing not done. > > I talked about this at OSSE 25 with some friends and got reasons why > your setup is broken. Well, it's on you. > > I was already raising this with Mediatek, but we are now back to square > one. > > NAK, because this patch WAS NEVER tested. And now I found you got EXACTLY the same error at v3, so you just never tested and ignored OUR test reports. This is unfortunately an example how you waste reviewers' time. Best regards, Krzysztof
On Fri, 2025-08-29 at 08:48 +0200, Krzysztof Kozlowski wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > > > On Fri, Aug 29, 2025 at 08:35:23AM +0200, Krzysztof Kozlowski wrote: > > On Thu, Aug 28, 2025 at 04:06:58PM +0800, Paul Chen wrote: > > > From: Paul-pl Chen <paul-pl.chen@mediatek.com> > > > > > > Add mediatek,exdma.yaml to support EXDMA for MT8196. > > > The MediaTek display overlap extended DMA engine, namely > > > OVL_EXDMA or EXDMA, primarily functions as a DMA engine > > > for reading data from DRAM with various DRAM footprints > > > and data formats. > > > > > > Signed-off-by: Paul-pl Chen <paul-pl.chen@mediatek.com> > > > --- > > > .../bindings/dma/mediatek,exdma.yaml | 68 > > > +++++++++++++++++++ > > > > > > Your changelog says NOTHING changed here and this fails tests, so > > does it > > mean you received that warnings before but you keep sending same > > broken > > code? > > > > Last two weeks of contributions from mediatek are absolutely > > terrible. > > Very poor code, basic in-house reviews not done, basic testing not > > done. > > > > I talked about this at OSSE 25 with some friends and got reasons > > why > > your setup is broken. Well, it's on you. > > > > I was already raising this with Mediatek, but we are now back to > > square > > one. > > > > NAK, because this patch WAS NEVER tested. > > > And now I found you got EXACTLY the same error at v3, so you just > never > tested and ignored OUR test reports. > > This is unfortunately an example how you waste reviewers' time. > > Best regards, > Krzysztof > Hi Krzysztof, I apologize for resubmitting an insufficiently tested patch and wasting reviewers’ time. The repeated failure and the inadequate changelog are entirely my responsibility—no excuses. I’m withdrawing this revision and will only resend after I’ve reproduced and fixed the failures, validated with comprehensive tests, completed internal review, and included a clear “Changes since vN.” Thank you for the direct feedback—I will do better. Best regards, Paul
On Thu, 28 Aug 2025 16:06:58 +0800, Paul Chen wrote: > From: Paul-pl Chen <paul-pl.chen@mediatek.com> > > Add mediatek,exdma.yaml to support EXDMA for MT8196. > The MediaTek display overlap extended DMA engine, namely > OVL_EXDMA or EXDMA, primarily functions as a DMA engine > for reading data from DRAM with various DRAM footprints > and data formats. > > Signed-off-by: Paul-pl Chen <paul-pl.chen@mediatek.com> > --- > .../bindings/dma/mediatek,exdma.yaml | 68 +++++++++++++++++++ > 1 file changed, 68 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/mediatek,exdma.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/dma/mediatek,exdma.example.dtb: dma-controller@32850000 (mediatek,mt8196-exdma): 'mediatek,larb' is a required property from schema $id: http://devicetree.org/schemas/dma/mediatek,exdma.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250828080855.3502514-4-paul-pl.chen@mediatek.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
© 2016 - 2025 Red Hat, Inc.