From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE9A5C433EF for ; Sat, 16 Oct 2021 14:19:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 77D2D60EDF for ; Sat, 16 Oct 2021 14:19:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 77D2D60EDF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=37XX1etDnKebxxFpC99gLq+6NqNfhfoVCe7Uv/Vn4xk=; b=gLHjc2mg03vmte 4EtmRAG98tTJcR4hjPLKssq5nAcGCMks8m3QwhAgLb3JzDGw90nxllejWfibpBQVGGQgZZHrQpWSZ 4caUlGzMcVfjujh3aZzuJH0+rI01ux1QisooROLznDx5XtCYEbLGixSK6gs0vda+E3L2wAiKJDJZ7 I/wHjgAP+Zs3stlZFr5QEmWjpdq5j148f7omBD60bWyw26fOXqJtYn5VRcbH2i0+P0MpaNuJqH00G AwHTD8o/IzJsWdxhYMh4OiLGJw2Vjaw5zTEPUmNxx3OywCmWAvpAUZrnsMAtjj+1ulEo42fb/NN/x I/3oe88i9LN3HyFS3mkw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mbkWo-00AmJA-So; Sat, 16 Oct 2021 14:19:14 +0000 Received: from mail-oi1-f174.google.com ([209.85.167.174]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mbkWb-00AmGS-UK; Sat, 16 Oct 2021 14:19:04 +0000 Received: by mail-oi1-f174.google.com with SMTP id y207so17473323oia.11; Sat, 16 Oct 2021 07:19:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aOytoN8C+U3Rn90b6LRYZACEMLn+/RQ2njWL4ku1AlA=; b=y4XRlifqA/PNOyAi1YfC8sYXleLHbBQaDTe1LdyMBWpIDVEJT8+aSmmEbJanwEiqrU YK8tUaxQkNVuF6G9ejrhMvyqOnnxQ6JafyHWiO7pstzVog82KEkwkYDXcs50W1HhPK9l RHQiIBc9D6aP9btw8iFreJlNmGBeHKwgkryWHdeYbLnG2vZHJAy0h4Gq376amhRyfmPl uzCDFnODT+8pGdwPsa5eMLWRGvFsbYbukNE18TPzm12tzEjZ7aXToBGDQ2j0+XUYZOoe cdxNxhUhi2JyxIlCDq638eVcWRNuONsT7g428Fm3o2Fx5/a8rvAUDmUu5QY/lBeh28ss xdgQ== X-Gm-Message-State: AOAM530s6gDAaSnKSMC50UzK/p7/JvhHcB+TQkB8tnV6Rk1Bc8UM7Du8 Ven77HKjTPT2PwWBEHJSKg== X-Google-Smtp-Source: ABdhPJwH6z7wFjfPNxSwD8xSpolT6ZSFgxQdba+N0JtbkHE6D3GikZ06PyB//4Q7ixNJhIi/SWdbHA== X-Received: by 2002:a05:6808:301e:: with SMTP id ay30mr177018oib.75.1634393940896; Sat, 16 Oct 2021 07:19:00 -0700 (PDT) Received: from robh.at.kernel.org (66-90-148-213.dyn.grandenetworks.net. [66.90.148.213]) by smtp.gmail.com with ESMTPSA id 65sm1874803otd.81.2021.10.16.07.18.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Oct 2021 07:19:00 -0700 (PDT) Received: (nullmailer pid 3872759 invoked by uid 1000); Sat, 16 Oct 2021 14:18:58 -0000 Date: Sat, 16 Oct 2021 09:18:58 -0500 From: Rob Herring To: Moudy Ho Cc: Mauro Carvalho Chehab , Matthias Brugger , Hans Verkuil , Jernej Skrabec , Maoguang Meng , daoyuan huang , Ping-Hsun Wu , Geert Uytterhoeven , Rob Landley , Laurent Pinchart , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, tfiga@chromium.org, drinkcat@chromium.org, acourbot@chromium.org, pihsun@chromium.org, menghui.lin@mediatek.com, sj.huang@mediatek.com, allen-kh.cheng@mediatek.com, randy.wu@mediatek.com, srv_heupstream@mediatek.com, hsinyi@google.com Subject: Re: [PATCH v8 5/7] dt-binding: mt8183: add Mediatek MDP3 dt-bindings Message-ID: References: <20211015123832.17914-1-moudy.ho@mediatek.com> <20211015123832.17914-6-moudy.ho@mediatek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211015123832.17914-6-moudy.ho@mediatek.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211016_071902_021711_D322185F X-CRM114-Status: GOOD ( 33.02 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Fri, Oct 15, 2021 at 08:38:30PM +0800, Moudy Ho wrote: > This patch adds DT binding document for Media Data Path 3 (MDP3) > a unit in multimedia system used for scaling and color format convert. > > Signed-off-by: Moudy Ho > --- > .../bindings/arm/mediatek/mediatek,ccorr.yaml | 59 +++++ > .../bindings/arm/mediatek/mediatek,rdma.yaml | 211 ++++++++++++++++++ > .../bindings/arm/mediatek/mediatek,wdma.yaml | 70 ++++++ These belong in a functional directory, not 'arm'. > .../bindings/media/mediatek,mdp3-rsz.yaml | 68 ++++++ > .../bindings/media/mediatek,mdp3-wrot.yaml | 70 ++++++ > 5 files changed, 478 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,wdma.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml > > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > new file mode 100644 > index 000000000000..40ea7955efc6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > @@ -0,0 +1,59 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,ccorr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Mediatek color correction > + > +maintainers: > + - Matthias Brugger > + > +description: | > + Mediatek color correction with 3X3 matrix. > + > +properties: > + compatible: > + items: > + - enum: > + - mediatek,mt8183-mdp3-ccorr > + > + mediatek,mdp3-id: > + $ref: /schemas/types.yaml#/definitions/uint32 > + maxItems: 1 maxItems is for an array, but you said this is a uint32. > + description: | > + There may be multiple blocks with the same function but > + different addresses in MDP3. > + In order to distinguish the connection with other blocks, > + a unique ID is needed to dynamically use one or more identical > + blocks to implement multiple pipelines. They aren't identical if you need to distinguish them. We should describe the difference rather than make up device indices. Why is this needed? For connections between components, use the graph binding. > + > + reg: > + maxItems: 1 > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + The register of client driver can be configured by gce with 4 arguments > + defined in this property, such as phandle of gce, subsys id, > + register offset and size. > + Each GCE subsys id is mapping to a client defined in the header > + include/dt-bindings/gce/-gce.h. > + > + clocks: > + minItems: 1 > + > +additionalProperties: false > + > +examples: > + - | > + #include > + #include > + > + mdp3_ccorr: mdp3_ccorr@1401c000 { > + compatible = "mediatek,mt8183-mdp3-ccorr"; > + mediatek,mdp3-id = <0>; > + reg = <0x1401c000 0x1000>; > + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0xc000 0x1000>; > + clocks = <&mmsys CLK_MM_MDP_CCORR>; > + }; > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > new file mode 100644 > index 000000000000..ad0e56923494 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > @@ -0,0 +1,211 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,rdma.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Mediatek Read Direct Memory Access > + > +maintainers: > + - Matthias Brugger > + > +description: | > + Mediatek Read Direct Memory Access(RDMA) component used to do read DMA. > + It contains one line buffer to store the sufficient pixel data, and > + must be siblings to the central MMSYS_CONFIG node. > + For a description of the MMSYS_CONFIG binding, see > + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > + for details. > + The 1st RDMA is also used to be a controller node in Media Data Path 3(MDP3) > + that containing MMSYS, MUTEX, GCE and SCP settings. > + > +properties: > + compatible: > + oneOf: > + - items: > + - const: mediatek,mt8183-mdp3 This looks less specific than this: > + - const: mediatek,mt8183-mdp3-rdma Which is the wrong order. But why the 2 values to begin with? > + - items: > + - const: mediatek,mt8183-mdp3-rdma > + > + mediatek,scp: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 > + description: | > + The node of system control processor (SCP), using > + the remoteproc & rpmsg framework. > + $ref: /schemas/remoteproc/mtk,scp.yaml > + > + mediatek,mdp3-id: > + $ref: /schemas/types.yaml#/definitions/uint32 > + maxItems: 1 > + description: | > + There may be multiple blocks with the same function but > + different addresses in MDP3. > + In order to distinguish the connection with other blocks, > + a unique ID is needed to dynamically use one or more identical > + blocks to implement multiple pipelines. > + > + mdp3-comps: vendor prefix needed. > + $ref: /schemas/types.yaml#/definitions/string-array > + items: > + - enum: > + # MDP direct-link input path selection, create a > + # component for path connectedness of HW pipe control > + - mediatek,mt8183-mdp3-dl1 > + - enum: > + - mediatek,mt8183-mdp3-dl2 > + - enum: > + # MDP direct-link output path selection, create a > + # component for path connectedness of HW pipe control > + - mediatek,mt8183-mdp3-path1 > + - enum: > + - mediatek,mt8183-mdp3-path2 > + - enum: > + # Input DMA of ISP PASS2 (DIP) module for raw image input > + - mediatek,mt8183-mdp3-imgi > + - enum: > + # Output DMA of ISP PASS2 (DIP) module for YUV image output > + - mediatek,mt8183-mdp3-exto > + description: | > + MTK sub-system of direct-link or DIP > + > + mdp3-comp-ids: > + maxItems: 1 > + $ref: /schemas/types.yaml#/definitions/uint32-array An array of only 1 item is a 'uint32' > + description: | > + Pipeline ID of MDP sub-system. Needs a better description and possibly constraints. Any value 0-2^32 is valid? > + > + reg: > + minItems: 1 > + maxItems: 5 > + description: | > + 1st: basic HW address > + 2nd: mediatek,mt8183-mdp-dl1, mediatek,mt8183-mdp-dl2 > + 3rd: mediatek,mt8183-mdp-path1 > + 4th: mediatek,mt8183-mdp-path2 > + 5th: mediatek,mt8183-mdp3-imgi, mediatek,mt8183-mdp3-exto This is better expressed as: items: - description: ... - description: ... - description: ... - description: ... - description: ... > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + The register of client driver can be configured by gce with 4 arguments So 'maxItems: 4'? > + defined in this property, such as phandle of gce, subsys id, > + register offset and size. > + Each GCE subsys id is mapping to a client defined in the header > + include/dt-bindings/gce/-gce.h. > + > + power-domains: > + maxItems: 1 > + > + clocks: > + minItems: 1 > + maxItems: 6 > + description: | > + 1st: RDMA0 clock > + 2nd: RSZ1 clock > + 3rd: direck-link TX clock in MDP side > + 4th: direck-link RX clock in MDP side > + 5th: direck-link TX clock in ISP side > + 6th: direck-link RX clock in ISP side Again, use 'items'. > + > + iommus: > + maxItems: 1 > + > + mediatek,mmsys: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 Not an array. > + description: | Don't need '|' when there is no formatting to maintain. > + The node of mux(multiplexer) controller for HW connections. > + > + mediatek,mm-mutex: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 > + description: | > + The node of sof(start of frame) signal controller. > + > + mediatek,mailbox-gce: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: | > + The node of global command engine (GCE), used to read/write > + registers with critical time limitation. > + > + mboxes: > + $ref: /schemas/types.yaml#/definitions/phandle-array Already has a type. This is where you need to define how many and what each one is if more than 1. > + > + gce-subsys: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + sub-system id corresponding to the global command engine (GCE) > + register address. > + > +if: > + properties: > + compatible: > + contains: > + const: mediatek,mt8183-mdp3 > + > +then: > + required: > + - mediatek,scp > + - mediatek,mmsys > + - mediatek,mm-mutex > + - mediatek,mailbox-gce > + - mboxes > + - gce-subsys > + > +required: > + - compatible > + - mediatek,mdp3-id > + - reg > + - clocks > + - mediatek,gce-client-reg > + > +additionalProperties: false > + > +examples: > + - | > + #include > + #include > + #include > + #include > + > + mdp3_rdma0: mdp3_rdma0@14001000 { > + compatible = "mediatek,mt8183-mdp3", > + "mediatek,mt8183-mdp3-rdma"; > + mediatek,scp = <&scp>; > + mediatek,mdp3-id = <0>; > + mdp3-comps = "mediatek,mt8183-mdp3-dl1", "mediatek,mt8183-mdp3-dl2", > + "mediatek,mt8183-mdp3-path1", "mediatek,mt8183-mdp3-path2", > + "mediatek,mt8183-mdp3-imgi", "mediatek,mt8183-mdp3-exto"; > + mdp3-comp-ids = <0 1 0 1 0 1>; > + reg = <0x14001000 0x1000>, > + <0x14000000 0x1000>, > + <0x14005000 0x1000>, > + <0x14006000 0x1000>, > + <0x15020000 0x1000>; > + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>, > + <&gce SUBSYS_1400XXXX 0 0x1000>, > + <&gce SUBSYS_1400XXXX 0x5000 0x1000>, > + <&gce SUBSYS_1400XXXX 0x6000 0x1000>, > + <&gce SUBSYS_1502XXXX 0 0x1000>; > + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; > + clocks = <&mmsys CLK_MM_MDP_RDMA0>, > + <&mmsys CLK_MM_MDP_RSZ1>, > + <&mmsys CLK_MM_MDP_DL_TXCK>, > + <&mmsys CLK_MM_MDP_DL_RX>, > + <&mmsys CLK_MM_IPU_DL_TXCK>, > + <&mmsys CLK_MM_IPU_DL_RX>; > + iommus = <&iommu>; > + mediatek,mmsys = <&mmsys>; > + mediatek,mm-mutex = <&mutex>; > + mediatek,mailbox-gce = <&gce>; > + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 21 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 22 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 23 CMDQ_THR_PRIO_LOWEST 0>; > + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>, > + <&gce 0x14010000 SUBSYS_1401XXXX>, > + <&gce 0x14020000 SUBSYS_1402XXXX>, > + <&gce 0x15020000 SUBSYS_1502XXXX>; > + }; > \ No newline at end of file Fix this. Similar comments on the rest... Rob _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04F76C433EF for ; Sat, 16 Oct 2021 14:20:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BBEE160EDF for ; Sat, 16 Oct 2021 14:20:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BBEE160EDF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gb4zUlRA5kImO3fNKdNYcLgM7ercO4d/SLEn/0ep5V4=; b=Q2iWQR7TPZzoVW MdF+rBaT8ZiflsG3IdEPYucINblMOKm/AwoISJlAimQMxgn30UZkIGedkhhPqdKNU5LlAMhDuYOEP 3L9t7o1ATwFcl+GUa86OP03q8EbzHdmDnbe2Z0syEE2XTG0Dn+dUYeQB/+Zijl/NoG06sekrjvkyj QO/3ZjGx59qpSEWqRkUHEcRTOC/v/HQfrDBiCFaPCC9w+x5BiR8A/mBgdGiSPv00PB3gu1u2btRzR 5DRegHQOR7ODBO+V9q/tP/YSyQ9oXDFAwK3AdmoUpizPKKSBvVjIrpsoFFKitR28VhMsZ5uOyZJp/ FDdmR1eNnDYBZliwlY0g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mbkWg-00AmHG-S7; Sat, 16 Oct 2021 14:19:07 +0000 Received: from mail-oi1-f174.google.com ([209.85.167.174]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mbkWb-00AmGS-UK; Sat, 16 Oct 2021 14:19:04 +0000 Received: by mail-oi1-f174.google.com with SMTP id y207so17473323oia.11; Sat, 16 Oct 2021 07:19:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aOytoN8C+U3Rn90b6LRYZACEMLn+/RQ2njWL4ku1AlA=; b=y4XRlifqA/PNOyAi1YfC8sYXleLHbBQaDTe1LdyMBWpIDVEJT8+aSmmEbJanwEiqrU YK8tUaxQkNVuF6G9ejrhMvyqOnnxQ6JafyHWiO7pstzVog82KEkwkYDXcs50W1HhPK9l RHQiIBc9D6aP9btw8iFreJlNmGBeHKwgkryWHdeYbLnG2vZHJAy0h4Gq376amhRyfmPl uzCDFnODT+8pGdwPsa5eMLWRGvFsbYbukNE18TPzm12tzEjZ7aXToBGDQ2j0+XUYZOoe cdxNxhUhi2JyxIlCDq638eVcWRNuONsT7g428Fm3o2Fx5/a8rvAUDmUu5QY/lBeh28ss xdgQ== X-Gm-Message-State: AOAM530s6gDAaSnKSMC50UzK/p7/JvhHcB+TQkB8tnV6Rk1Bc8UM7Du8 Ven77HKjTPT2PwWBEHJSKg== X-Google-Smtp-Source: ABdhPJwH6z7wFjfPNxSwD8xSpolT6ZSFgxQdba+N0JtbkHE6D3GikZ06PyB//4Q7ixNJhIi/SWdbHA== X-Received: by 2002:a05:6808:301e:: with SMTP id ay30mr177018oib.75.1634393940896; Sat, 16 Oct 2021 07:19:00 -0700 (PDT) Received: from robh.at.kernel.org (66-90-148-213.dyn.grandenetworks.net. [66.90.148.213]) by smtp.gmail.com with ESMTPSA id 65sm1874803otd.81.2021.10.16.07.18.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Oct 2021 07:19:00 -0700 (PDT) Received: (nullmailer pid 3872759 invoked by uid 1000); Sat, 16 Oct 2021 14:18:58 -0000 Date: Sat, 16 Oct 2021 09:18:58 -0500 From: Rob Herring To: Moudy Ho Cc: Mauro Carvalho Chehab , Matthias Brugger , Hans Verkuil , Jernej Skrabec , Maoguang Meng , daoyuan huang , Ping-Hsun Wu , Geert Uytterhoeven , Rob Landley , Laurent Pinchart , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, tfiga@chromium.org, drinkcat@chromium.org, acourbot@chromium.org, pihsun@chromium.org, menghui.lin@mediatek.com, sj.huang@mediatek.com, allen-kh.cheng@mediatek.com, randy.wu@mediatek.com, srv_heupstream@mediatek.com, hsinyi@google.com Subject: Re: [PATCH v8 5/7] dt-binding: mt8183: add Mediatek MDP3 dt-bindings Message-ID: References: <20211015123832.17914-1-moudy.ho@mediatek.com> <20211015123832.17914-6-moudy.ho@mediatek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211015123832.17914-6-moudy.ho@mediatek.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211016_071902_021711_D322185F X-CRM114-Status: GOOD ( 33.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 15, 2021 at 08:38:30PM +0800, Moudy Ho wrote: > This patch adds DT binding document for Media Data Path 3 (MDP3) > a unit in multimedia system used for scaling and color format convert. > > Signed-off-by: Moudy Ho > --- > .../bindings/arm/mediatek/mediatek,ccorr.yaml | 59 +++++ > .../bindings/arm/mediatek/mediatek,rdma.yaml | 211 ++++++++++++++++++ > .../bindings/arm/mediatek/mediatek,wdma.yaml | 70 ++++++ These belong in a functional directory, not 'arm'. > .../bindings/media/mediatek,mdp3-rsz.yaml | 68 ++++++ > .../bindings/media/mediatek,mdp3-wrot.yaml | 70 ++++++ > 5 files changed, 478 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,wdma.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml > > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > new file mode 100644 > index 000000000000..40ea7955efc6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > @@ -0,0 +1,59 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,ccorr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Mediatek color correction > + > +maintainers: > + - Matthias Brugger > + > +description: | > + Mediatek color correction with 3X3 matrix. > + > +properties: > + compatible: > + items: > + - enum: > + - mediatek,mt8183-mdp3-ccorr > + > + mediatek,mdp3-id: > + $ref: /schemas/types.yaml#/definitions/uint32 > + maxItems: 1 maxItems is for an array, but you said this is a uint32. > + description: | > + There may be multiple blocks with the same function but > + different addresses in MDP3. > + In order to distinguish the connection with other blocks, > + a unique ID is needed to dynamically use one or more identical > + blocks to implement multiple pipelines. They aren't identical if you need to distinguish them. We should describe the difference rather than make up device indices. Why is this needed? For connections between components, use the graph binding. > + > + reg: > + maxItems: 1 > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + The register of client driver can be configured by gce with 4 arguments > + defined in this property, such as phandle of gce, subsys id, > + register offset and size. > + Each GCE subsys id is mapping to a client defined in the header > + include/dt-bindings/gce/-gce.h. > + > + clocks: > + minItems: 1 > + > +additionalProperties: false > + > +examples: > + - | > + #include > + #include > + > + mdp3_ccorr: mdp3_ccorr@1401c000 { > + compatible = "mediatek,mt8183-mdp3-ccorr"; > + mediatek,mdp3-id = <0>; > + reg = <0x1401c000 0x1000>; > + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0xc000 0x1000>; > + clocks = <&mmsys CLK_MM_MDP_CCORR>; > + }; > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > new file mode 100644 > index 000000000000..ad0e56923494 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > @@ -0,0 +1,211 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,rdma.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Mediatek Read Direct Memory Access > + > +maintainers: > + - Matthias Brugger > + > +description: | > + Mediatek Read Direct Memory Access(RDMA) component used to do read DMA. > + It contains one line buffer to store the sufficient pixel data, and > + must be siblings to the central MMSYS_CONFIG node. > + For a description of the MMSYS_CONFIG binding, see > + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > + for details. > + The 1st RDMA is also used to be a controller node in Media Data Path 3(MDP3) > + that containing MMSYS, MUTEX, GCE and SCP settings. > + > +properties: > + compatible: > + oneOf: > + - items: > + - const: mediatek,mt8183-mdp3 This looks less specific than this: > + - const: mediatek,mt8183-mdp3-rdma Which is the wrong order. But why the 2 values to begin with? > + - items: > + - const: mediatek,mt8183-mdp3-rdma > + > + mediatek,scp: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 > + description: | > + The node of system control processor (SCP), using > + the remoteproc & rpmsg framework. > + $ref: /schemas/remoteproc/mtk,scp.yaml > + > + mediatek,mdp3-id: > + $ref: /schemas/types.yaml#/definitions/uint32 > + maxItems: 1 > + description: | > + There may be multiple blocks with the same function but > + different addresses in MDP3. > + In order to distinguish the connection with other blocks, > + a unique ID is needed to dynamically use one or more identical > + blocks to implement multiple pipelines. > + > + mdp3-comps: vendor prefix needed. > + $ref: /schemas/types.yaml#/definitions/string-array > + items: > + - enum: > + # MDP direct-link input path selection, create a > + # component for path connectedness of HW pipe control > + - mediatek,mt8183-mdp3-dl1 > + - enum: > + - mediatek,mt8183-mdp3-dl2 > + - enum: > + # MDP direct-link output path selection, create a > + # component for path connectedness of HW pipe control > + - mediatek,mt8183-mdp3-path1 > + - enum: > + - mediatek,mt8183-mdp3-path2 > + - enum: > + # Input DMA of ISP PASS2 (DIP) module for raw image input > + - mediatek,mt8183-mdp3-imgi > + - enum: > + # Output DMA of ISP PASS2 (DIP) module for YUV image output > + - mediatek,mt8183-mdp3-exto > + description: | > + MTK sub-system of direct-link or DIP > + > + mdp3-comp-ids: > + maxItems: 1 > + $ref: /schemas/types.yaml#/definitions/uint32-array An array of only 1 item is a 'uint32' > + description: | > + Pipeline ID of MDP sub-system. Needs a better description and possibly constraints. Any value 0-2^32 is valid? > + > + reg: > + minItems: 1 > + maxItems: 5 > + description: | > + 1st: basic HW address > + 2nd: mediatek,mt8183-mdp-dl1, mediatek,mt8183-mdp-dl2 > + 3rd: mediatek,mt8183-mdp-path1 > + 4th: mediatek,mt8183-mdp-path2 > + 5th: mediatek,mt8183-mdp3-imgi, mediatek,mt8183-mdp3-exto This is better expressed as: items: - description: ... - description: ... - description: ... - description: ... - description: ... > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + The register of client driver can be configured by gce with 4 arguments So 'maxItems: 4'? > + defined in this property, such as phandle of gce, subsys id, > + register offset and size. > + Each GCE subsys id is mapping to a client defined in the header > + include/dt-bindings/gce/-gce.h. > + > + power-domains: > + maxItems: 1 > + > + clocks: > + minItems: 1 > + maxItems: 6 > + description: | > + 1st: RDMA0 clock > + 2nd: RSZ1 clock > + 3rd: direck-link TX clock in MDP side > + 4th: direck-link RX clock in MDP side > + 5th: direck-link TX clock in ISP side > + 6th: direck-link RX clock in ISP side Again, use 'items'. > + > + iommus: > + maxItems: 1 > + > + mediatek,mmsys: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 Not an array. > + description: | Don't need '|' when there is no formatting to maintain. > + The node of mux(multiplexer) controller for HW connections. > + > + mediatek,mm-mutex: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 > + description: | > + The node of sof(start of frame) signal controller. > + > + mediatek,mailbox-gce: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: | > + The node of global command engine (GCE), used to read/write > + registers with critical time limitation. > + > + mboxes: > + $ref: /schemas/types.yaml#/definitions/phandle-array Already has a type. This is where you need to define how many and what each one is if more than 1. > + > + gce-subsys: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + sub-system id corresponding to the global command engine (GCE) > + register address. > + > +if: > + properties: > + compatible: > + contains: > + const: mediatek,mt8183-mdp3 > + > +then: > + required: > + - mediatek,scp > + - mediatek,mmsys > + - mediatek,mm-mutex > + - mediatek,mailbox-gce > + - mboxes > + - gce-subsys > + > +required: > + - compatible > + - mediatek,mdp3-id > + - reg > + - clocks > + - mediatek,gce-client-reg > + > +additionalProperties: false > + > +examples: > + - | > + #include > + #include > + #include > + #include > + > + mdp3_rdma0: mdp3_rdma0@14001000 { > + compatible = "mediatek,mt8183-mdp3", > + "mediatek,mt8183-mdp3-rdma"; > + mediatek,scp = <&scp>; > + mediatek,mdp3-id = <0>; > + mdp3-comps = "mediatek,mt8183-mdp3-dl1", "mediatek,mt8183-mdp3-dl2", > + "mediatek,mt8183-mdp3-path1", "mediatek,mt8183-mdp3-path2", > + "mediatek,mt8183-mdp3-imgi", "mediatek,mt8183-mdp3-exto"; > + mdp3-comp-ids = <0 1 0 1 0 1>; > + reg = <0x14001000 0x1000>, > + <0x14000000 0x1000>, > + <0x14005000 0x1000>, > + <0x14006000 0x1000>, > + <0x15020000 0x1000>; > + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>, > + <&gce SUBSYS_1400XXXX 0 0x1000>, > + <&gce SUBSYS_1400XXXX 0x5000 0x1000>, > + <&gce SUBSYS_1400XXXX 0x6000 0x1000>, > + <&gce SUBSYS_1502XXXX 0 0x1000>; > + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; > + clocks = <&mmsys CLK_MM_MDP_RDMA0>, > + <&mmsys CLK_MM_MDP_RSZ1>, > + <&mmsys CLK_MM_MDP_DL_TXCK>, > + <&mmsys CLK_MM_MDP_DL_RX>, > + <&mmsys CLK_MM_IPU_DL_TXCK>, > + <&mmsys CLK_MM_IPU_DL_RX>; > + iommus = <&iommu>; > + mediatek,mmsys = <&mmsys>; > + mediatek,mm-mutex = <&mutex>; > + mediatek,mailbox-gce = <&gce>; > + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 21 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 22 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 23 CMDQ_THR_PRIO_LOWEST 0>; > + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>, > + <&gce 0x14010000 SUBSYS_1401XXXX>, > + <&gce 0x14020000 SUBSYS_1402XXXX>, > + <&gce 0x15020000 SUBSYS_1502XXXX>; > + }; > \ No newline at end of file Fix this. Similar comments on the rest... Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74387C433FE for ; Sat, 16 Oct 2021 14:19:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4484B61212 for ; Sat, 16 Oct 2021 14:19:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244355AbhJPOVQ (ORCPT ); Sat, 16 Oct 2021 10:21:16 -0400 Received: from mail-oi1-f175.google.com ([209.85.167.175]:37492 "EHLO mail-oi1-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244348AbhJPOVM (ORCPT ); Sat, 16 Oct 2021 10:21:12 -0400 Received: by mail-oi1-f175.google.com with SMTP id o83so17525332oif.4; Sat, 16 Oct 2021 07:19:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aOytoN8C+U3Rn90b6LRYZACEMLn+/RQ2njWL4ku1AlA=; b=4JfezNqalfqkCWJzPkN1jYu37+V6CCCoNrmC3rFH+O95/2dXpNkE1nHsfmKV1rzBnm dNxBcfIwrDrLv2vCV9bn0SbMMnow2kPReYKCfg9dV/bzja/3MbeJBQtnPfWAkHNnEu13 Ke0BgjH5Gdeddz/JQGCXLtgb1vFR4p8HpM2u+RUQcghLUAbwluOAT4/AbHJCwu3nfCM/ 6oDIWY1tzxv957yQfPlP55RFAaL7zWPdiqYNGJ1338LyQrmOYHSbh7bMHgsGYmgnoXlk 6kwf43AvSU5jCoSdBMIngPx9dbasyMpj7weQeDHi78QPCJVPDTf2eJ5T9i9pg9LAYfkz lxUA== X-Gm-Message-State: AOAM533ii0UaRF5j++Fe0QzTBFB5fkras5QJH2R6TGfT5C+CdFKACBPK aM/hMjoBWx+X51ltQDYnLQ== X-Google-Smtp-Source: ABdhPJwH6z7wFjfPNxSwD8xSpolT6ZSFgxQdba+N0JtbkHE6D3GikZ06PyB//4Q7ixNJhIi/SWdbHA== X-Received: by 2002:a05:6808:301e:: with SMTP id ay30mr177018oib.75.1634393940896; Sat, 16 Oct 2021 07:19:00 -0700 (PDT) Received: from robh.at.kernel.org (66-90-148-213.dyn.grandenetworks.net. [66.90.148.213]) by smtp.gmail.com with ESMTPSA id 65sm1874803otd.81.2021.10.16.07.18.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Oct 2021 07:19:00 -0700 (PDT) Received: (nullmailer pid 3872759 invoked by uid 1000); Sat, 16 Oct 2021 14:18:58 -0000 Date: Sat, 16 Oct 2021 09:18:58 -0500 From: Rob Herring To: Moudy Ho Cc: Mauro Carvalho Chehab , Matthias Brugger , Hans Verkuil , Jernej Skrabec , Maoguang Meng , daoyuan huang , Ping-Hsun Wu , Geert Uytterhoeven , Rob Landley , Laurent Pinchart , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, tfiga@chromium.org, drinkcat@chromium.org, acourbot@chromium.org, pihsun@chromium.org, menghui.lin@mediatek.com, sj.huang@mediatek.com, allen-kh.cheng@mediatek.com, randy.wu@mediatek.com, srv_heupstream@mediatek.com, hsinyi@google.com Subject: Re: [PATCH v8 5/7] dt-binding: mt8183: add Mediatek MDP3 dt-bindings Message-ID: References: <20211015123832.17914-1-moudy.ho@mediatek.com> <20211015123832.17914-6-moudy.ho@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211015123832.17914-6-moudy.ho@mediatek.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, Oct 15, 2021 at 08:38:30PM +0800, Moudy Ho wrote: > This patch adds DT binding document for Media Data Path 3 (MDP3) > a unit in multimedia system used for scaling and color format convert. > > Signed-off-by: Moudy Ho > --- > .../bindings/arm/mediatek/mediatek,ccorr.yaml | 59 +++++ > .../bindings/arm/mediatek/mediatek,rdma.yaml | 211 ++++++++++++++++++ > .../bindings/arm/mediatek/mediatek,wdma.yaml | 70 ++++++ These belong in a functional directory, not 'arm'. > .../bindings/media/mediatek,mdp3-rsz.yaml | 68 ++++++ > .../bindings/media/mediatek,mdp3-wrot.yaml | 70 ++++++ > 5 files changed, 478 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,wdma.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml > > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > new file mode 100644 > index 000000000000..40ea7955efc6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ccorr.yaml > @@ -0,0 +1,59 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,ccorr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Mediatek color correction > + > +maintainers: > + - Matthias Brugger > + > +description: | > + Mediatek color correction with 3X3 matrix. > + > +properties: > + compatible: > + items: > + - enum: > + - mediatek,mt8183-mdp3-ccorr > + > + mediatek,mdp3-id: > + $ref: /schemas/types.yaml#/definitions/uint32 > + maxItems: 1 maxItems is for an array, but you said this is a uint32. > + description: | > + There may be multiple blocks with the same function but > + different addresses in MDP3. > + In order to distinguish the connection with other blocks, > + a unique ID is needed to dynamically use one or more identical > + blocks to implement multiple pipelines. They aren't identical if you need to distinguish them. We should describe the difference rather than make up device indices. Why is this needed? For connections between components, use the graph binding. > + > + reg: > + maxItems: 1 > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + The register of client driver can be configured by gce with 4 arguments > + defined in this property, such as phandle of gce, subsys id, > + register offset and size. > + Each GCE subsys id is mapping to a client defined in the header > + include/dt-bindings/gce/-gce.h. > + > + clocks: > + minItems: 1 > + > +additionalProperties: false > + > +examples: > + - | > + #include > + #include > + > + mdp3_ccorr: mdp3_ccorr@1401c000 { > + compatible = "mediatek,mt8183-mdp3-ccorr"; > + mediatek,mdp3-id = <0>; > + reg = <0x1401c000 0x1000>; > + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0xc000 0x1000>; > + clocks = <&mmsys CLK_MM_MDP_CCORR>; > + }; > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > new file mode 100644 > index 000000000000..ad0e56923494 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,rdma.yaml > @@ -0,0 +1,211 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,rdma.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Mediatek Read Direct Memory Access > + > +maintainers: > + - Matthias Brugger > + > +description: | > + Mediatek Read Direct Memory Access(RDMA) component used to do read DMA. > + It contains one line buffer to store the sufficient pixel data, and > + must be siblings to the central MMSYS_CONFIG node. > + For a description of the MMSYS_CONFIG binding, see > + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > + for details. > + The 1st RDMA is also used to be a controller node in Media Data Path 3(MDP3) > + that containing MMSYS, MUTEX, GCE and SCP settings. > + > +properties: > + compatible: > + oneOf: > + - items: > + - const: mediatek,mt8183-mdp3 This looks less specific than this: > + - const: mediatek,mt8183-mdp3-rdma Which is the wrong order. But why the 2 values to begin with? > + - items: > + - const: mediatek,mt8183-mdp3-rdma > + > + mediatek,scp: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 > + description: | > + The node of system control processor (SCP), using > + the remoteproc & rpmsg framework. > + $ref: /schemas/remoteproc/mtk,scp.yaml > + > + mediatek,mdp3-id: > + $ref: /schemas/types.yaml#/definitions/uint32 > + maxItems: 1 > + description: | > + There may be multiple blocks with the same function but > + different addresses in MDP3. > + In order to distinguish the connection with other blocks, > + a unique ID is needed to dynamically use one or more identical > + blocks to implement multiple pipelines. > + > + mdp3-comps: vendor prefix needed. > + $ref: /schemas/types.yaml#/definitions/string-array > + items: > + - enum: > + # MDP direct-link input path selection, create a > + # component for path connectedness of HW pipe control > + - mediatek,mt8183-mdp3-dl1 > + - enum: > + - mediatek,mt8183-mdp3-dl2 > + - enum: > + # MDP direct-link output path selection, create a > + # component for path connectedness of HW pipe control > + - mediatek,mt8183-mdp3-path1 > + - enum: > + - mediatek,mt8183-mdp3-path2 > + - enum: > + # Input DMA of ISP PASS2 (DIP) module for raw image input > + - mediatek,mt8183-mdp3-imgi > + - enum: > + # Output DMA of ISP PASS2 (DIP) module for YUV image output > + - mediatek,mt8183-mdp3-exto > + description: | > + MTK sub-system of direct-link or DIP > + > + mdp3-comp-ids: > + maxItems: 1 > + $ref: /schemas/types.yaml#/definitions/uint32-array An array of only 1 item is a 'uint32' > + description: | > + Pipeline ID of MDP sub-system. Needs a better description and possibly constraints. Any value 0-2^32 is valid? > + > + reg: > + minItems: 1 > + maxItems: 5 > + description: | > + 1st: basic HW address > + 2nd: mediatek,mt8183-mdp-dl1, mediatek,mt8183-mdp-dl2 > + 3rd: mediatek,mt8183-mdp-path1 > + 4th: mediatek,mt8183-mdp-path2 > + 5th: mediatek,mt8183-mdp3-imgi, mediatek,mt8183-mdp3-exto This is better expressed as: items: - description: ... - description: ... - description: ... - description: ... - description: ... > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + The register of client driver can be configured by gce with 4 arguments So 'maxItems: 4'? > + defined in this property, such as phandle of gce, subsys id, > + register offset and size. > + Each GCE subsys id is mapping to a client defined in the header > + include/dt-bindings/gce/-gce.h. > + > + power-domains: > + maxItems: 1 > + > + clocks: > + minItems: 1 > + maxItems: 6 > + description: | > + 1st: RDMA0 clock > + 2nd: RSZ1 clock > + 3rd: direck-link TX clock in MDP side > + 4th: direck-link RX clock in MDP side > + 5th: direck-link TX clock in ISP side > + 6th: direck-link RX clock in ISP side Again, use 'items'. > + > + iommus: > + maxItems: 1 > + > + mediatek,mmsys: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 Not an array. > + description: | Don't need '|' when there is no formatting to maintain. > + The node of mux(multiplexer) controller for HW connections. > + > + mediatek,mm-mutex: > + $ref: /schemas/types.yaml#/definitions/phandle > + maxItems: 1 > + description: | > + The node of sof(start of frame) signal controller. > + > + mediatek,mailbox-gce: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: | > + The node of global command engine (GCE), used to read/write > + registers with critical time limitation. > + > + mboxes: > + $ref: /schemas/types.yaml#/definitions/phandle-array Already has a type. This is where you need to define how many and what each one is if more than 1. > + > + gce-subsys: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: | > + sub-system id corresponding to the global command engine (GCE) > + register address. > + > +if: > + properties: > + compatible: > + contains: > + const: mediatek,mt8183-mdp3 > + > +then: > + required: > + - mediatek,scp > + - mediatek,mmsys > + - mediatek,mm-mutex > + - mediatek,mailbox-gce > + - mboxes > + - gce-subsys > + > +required: > + - compatible > + - mediatek,mdp3-id > + - reg > + - clocks > + - mediatek,gce-client-reg > + > +additionalProperties: false > + > +examples: > + - | > + #include > + #include > + #include > + #include > + > + mdp3_rdma0: mdp3_rdma0@14001000 { > + compatible = "mediatek,mt8183-mdp3", > + "mediatek,mt8183-mdp3-rdma"; > + mediatek,scp = <&scp>; > + mediatek,mdp3-id = <0>; > + mdp3-comps = "mediatek,mt8183-mdp3-dl1", "mediatek,mt8183-mdp3-dl2", > + "mediatek,mt8183-mdp3-path1", "mediatek,mt8183-mdp3-path2", > + "mediatek,mt8183-mdp3-imgi", "mediatek,mt8183-mdp3-exto"; > + mdp3-comp-ids = <0 1 0 1 0 1>; > + reg = <0x14001000 0x1000>, > + <0x14000000 0x1000>, > + <0x14005000 0x1000>, > + <0x14006000 0x1000>, > + <0x15020000 0x1000>; > + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>, > + <&gce SUBSYS_1400XXXX 0 0x1000>, > + <&gce SUBSYS_1400XXXX 0x5000 0x1000>, > + <&gce SUBSYS_1400XXXX 0x6000 0x1000>, > + <&gce SUBSYS_1502XXXX 0 0x1000>; > + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; > + clocks = <&mmsys CLK_MM_MDP_RDMA0>, > + <&mmsys CLK_MM_MDP_RSZ1>, > + <&mmsys CLK_MM_MDP_DL_TXCK>, > + <&mmsys CLK_MM_MDP_DL_RX>, > + <&mmsys CLK_MM_IPU_DL_TXCK>, > + <&mmsys CLK_MM_IPU_DL_RX>; > + iommus = <&iommu>; > + mediatek,mmsys = <&mmsys>; > + mediatek,mm-mutex = <&mutex>; > + mediatek,mailbox-gce = <&gce>; > + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 21 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 22 CMDQ_THR_PRIO_LOWEST 0>, > + <&gce 23 CMDQ_THR_PRIO_LOWEST 0>; > + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>, > + <&gce 0x14010000 SUBSYS_1401XXXX>, > + <&gce 0x14020000 SUBSYS_1402XXXX>, > + <&gce 0x15020000 SUBSYS_1502XXXX>; > + }; > \ No newline at end of file Fix this. Similar comments on the rest... Rob