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 X-Spam-Level: X-Spam-Status: No, score=-17.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8839C12002 for ; Wed, 21 Jul 2021 14:30:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A19F16120C for ; Wed, 21 Jul 2021 14:30:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238083AbhGUNuV (ORCPT ); Wed, 21 Jul 2021 09:50:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:48742 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238063AbhGUNuU (ORCPT ); Wed, 21 Jul 2021 09:50:20 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 221506120C; Wed, 21 Jul 2021 14:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626877857; bh=ItoMV2w0siUwl28cOzY8vDd1juPLnJDPTjp4OHicjsY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ClvtVxu6OzSCTr6zmptraNDY5OLNM624UREm7ezvDoU7BW5bC7r8V6ZGzAZy4bz+s sJmW+LWR+x+z38wxw+FmxcRcR3VpAili1h7VPCl3/irV2M+zsa6ltHGlpNRW3joXxb qiGO227LA3oUUwE+OoUR5Fu8ZX+U03rbDw2VN5xN/OfXGUj4oZJLRs7BhcNb9PHRHa lMOv2MfIHgkGFQInTs+9K/XPN8JjjdnzcYx83pg5Go6wg10Pw7FlgESAqmTDqVrVDX vXdI0cnQYmzHSoBs+o0R54zCBZ3MKEfh4VhiWFx5NPNp2fXiHaImlqF/qOEP0ti2ob j+9LQ+FyekYLw== Received: by mail-ej1-f43.google.com with SMTP id hd33so3544376ejc.9; Wed, 21 Jul 2021 07:30:57 -0700 (PDT) X-Gm-Message-State: AOAM531NnvOJ/dMT93jE55LZVgvyMiGgapWVbcbmfbXWSDvQ1QETH6KW BlLcsH8rfK+0x1WO69wrDd8/XQGfNzf+rHbUpA== X-Google-Smtp-Source: ABdhPJxRy4QTRGTzS/mvAFQhcw860lxwIiR+bbQYhncMtCZggceYaOOm1hj37+GvvSrLHiI7dlywoxUv3mfvXB62HXQ= X-Received: by 2002:a17:907:5096:: with SMTP id fv22mr37457462ejc.525.1626877855685; Wed, 21 Jul 2021 07:30:55 -0700 (PDT) MIME-Version: 1.0 References: <20210721140424.725744-1-maxime@cerno.tech> <20210721140424.725744-6-maxime@cerno.tech> In-Reply-To: <20210721140424.725744-6-maxime@cerno.tech> From: Rob Herring Date: Wed, 21 Jul 2021 08:30:43 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/54] dt-bindings: Convert Reserved Memory binding to a schema To: Maxime Ripard , Grant Likely Cc: Chen-Yu Tsai , Jernej Skrabec , devicetree@vger.kernel.org, Frank Rowand , linux-arm-kernel , linux-sunxi@googlegroups.com, Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, Jul 21, 2021 at 8:04 AM Maxime Ripard wrote: > > The Reserved Memory mechanism is supported by Linux thanks to its device > tree binding. > > Now that we have the DT validation in place, let's convert the device > tree bindings for that driver over to a YAML schema. Thanks for this! > > Cc: Mailing List > Signed-off-by: Maxime Ripard > --- > .../reserved-memory/reserved-memory.txt | 141 --------------- > .../reserved-memory/reserved-memory.yaml | 167 ++++++++++++++++++ > 2 files changed, 167 insertions(+), 141 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > new file mode 100644 > index 000000000000..b61527f11953 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > @@ -0,0 +1,167 @@ > +# SPDX-License-Identifier: GPL-2.0 I think this is okay to dual license. Grant (Linaro) is the original author and there's only a few lines from other authors. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: /reserved-memory Node > + > +maintainers: > + - Devicetree Specification Mailing List > + > +description: > > + Reserved memory is specified as a node under the /reserved-memory node. The > + operating system shall exclude reserved memory from normal usage one can > + create child nodes describing particular reserved (excluded from normal use) > + memory regions. Such memory regions are usually designed for the special > + usage by various device drivers. > + > +properties: > + $nodename: > + const: reserved-memory > + > + "#address-cells": true > + "#size-cells": true > + ranges: true > + > +patternProperties: > + "^(?!(ranges))[a-z,-]*(@[0-9]+)?$": Note that you could drop this and put under 'additionalProperties'. You would lose some node name checking, but there's really little standard on these nodes. > + type: object > + > + description: > > + Each child of the reserved-memory node specifies one or more regions of > + reserved memory. Each child node may either use a 'reg' property to > + specify a specific range of reserved memory, or a 'size' property with > + optional constraints to request a dynamically allocated block of memory. > + > + Following the generic-names recommended practice, node names should > + reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit > + address (@
) should be appended to the name if the node is a > + static allocation. > + > + properties: > + reg: true > + > + size: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Length based on parent's \#size-cells. Size in bytes of memory to > + reserve. > + > + alignment: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Length based on parent's \#size-cells. Address boundary for > + alignment of allocation. > + > + alloc-ranges: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Address and Length pairs. Specifies regions of memory that are > + acceptable to allocate from. > + > + compatible: > + oneOf: > + - const: shared-dma-pool > + description: > > + This indicates a region of memory meant to be used as a shared > + pool of DMA buffers for a set of devices. It can be used by an > + operating system to instantiate the necessary pool management > + subsystem if necessary. > + > + # Vendor-specific compatibles in the form ,[-] > + - const: mediatek,trustzone-bootinfo I think these should be separate schema files. At least, we're going to need to support separate files because I don't think we want ones adding custom properties here. This would fail unless we add every compatible here. We could also be a bit more exact as to which properties below apply (e.g. linux,.*-default is only valid for shared-dma-pool). > + > + no-map: > + type: boolean > + description: > > + Indicates the operating system must not create a virtual mapping of > + the region as part of its standard mapping of system memory, nor > + permit speculative access to it under any circumstances other than > + under the control of the device driver using the region. > + > + reusable: > + type: boolean > + description: > > + The operating system can use the memory in this region with the > + limitation that the device driver(s) owning the region need to be > + able to reclaim it back. Typically that means that the operating > + system can use that region to store volatile or cached data that > + can be otherwise regenerated or migrated elsewhere. > + > + linux,cma-default: > + type: boolean > + description: > > + If this property is present, then Linux will use the region for the > + default pool of the contiguous memory allocator. > + > + linux,dma-default: > + type: boolean > + description: > > + If this property is present, then Linux will use the region for the > + default pool of the consistent DMA allocator. > + > + allOf: > + - if: > + required: > + - no-map > + > + then: > + not: > + required: > + - reusable > + > + - if: > + required: > + - reusable > + > + then: > + not: > + required: > + - no-map > + > + oneOf: > + - required: > + - reg > + > + - required: > + - size > + > + additionalProperties: true > + > +additionalProperties: true This should be false, right? > + > +examples: > + - | > + / { > + #address-cells = <1>; > + #size-cells = <1>; > + model = "MediaTek MT2701 evaluation board"; > + compatible = "mediatek,mt2701-evb", "mediatek,mt2701"; > + > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + /* global autoconfigured region for contiguous allocations */ > + linux,cma { > + compatible = "shared-dma-pool"; > + reusable; > + size = <0x4000000>; > + alignment = <0x2000>; > + linux,cma-default; > + }; > + > + display_reserved: framebuffer@78000000 { > + reg = <0x78000000 0x800000>; > + }; > + > + trustzone-bootinfo@80002000 { > + compatible = "mediatek,trustzone-bootinfo"; > + reg = <0x80002000 0x1000>; > + }; > + }; > + }; > + > +... > -- > 2.31.1 > 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 X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9AF4C636C9 for ; Wed, 21 Jul 2021 15:14:21 +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 8607361221 for ; Wed, 21 Jul 2021 15:14:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8607361221 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=c6Qlnzc1zrPz1j3y5CyuS1TpSKHJwP1eea2OeIA+eY0=; b=BpAHP55Z11hJ5M 9HHAq2dHIitc0vQ9vrQL5tW1F/lm/hrdV/APfGWwKJRMzf4wSKqE2jighVOVRMkVFz6b7FKDuWkHb PqLZeZcrH+Mev0niBCGa0zjko0+c69hvfuQe5Ss7QxQDhnAvL3l1c9QBPaFIhyqQenkHQHuy1/CXf kcKyD5NnjNYiWEI1BCyCZUKmOD+jWlufuaQF3Iib2l0oCbI8nkbiYlS+D2VTOCO007fMccUevQv7r Eefe1GW+9KJP0+A8UZd9zIbRQ/y+tyRAHo0YsrYAJv/RQ/b429LDjFZJS6HGmH1AX9IPNYwX3wYkn vwYxc2B0zVeuW1+zPbYw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6DtK-00GDZt-01; Wed, 21 Jul 2021 15:12:10 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6DFR-00Fz6P-UE for linux-arm-kernel@lists.infradead.org; Wed, 21 Jul 2021 14:30:59 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2AAAE61245 for ; Wed, 21 Jul 2021 14:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626877857; bh=ItoMV2w0siUwl28cOzY8vDd1juPLnJDPTjp4OHicjsY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ClvtVxu6OzSCTr6zmptraNDY5OLNM624UREm7ezvDoU7BW5bC7r8V6ZGzAZy4bz+s sJmW+LWR+x+z38wxw+FmxcRcR3VpAili1h7VPCl3/irV2M+zsa6ltHGlpNRW3joXxb qiGO227LA3oUUwE+OoUR5Fu8ZX+U03rbDw2VN5xN/OfXGUj4oZJLRs7BhcNb9PHRHa lMOv2MfIHgkGFQInTs+9K/XPN8JjjdnzcYx83pg5Go6wg10Pw7FlgESAqmTDqVrVDX vXdI0cnQYmzHSoBs+o0R54zCBZ3MKEfh4VhiWFx5NPNp2fXiHaImlqF/qOEP0ti2ob j+9LQ+FyekYLw== Received: by mail-ej1-f44.google.com with SMTP id gb6so3577533ejc.5 for ; Wed, 21 Jul 2021 07:30:57 -0700 (PDT) X-Gm-Message-State: AOAM530sVB4qq6HTEWpCdZsLwBlDiTbyDN88GlBBQR1oIDeVeQoIgAPP WjmuPXUQfJSZw3/AljOeVR4WjYdT/Xjd789BqA== X-Google-Smtp-Source: ABdhPJxRy4QTRGTzS/mvAFQhcw860lxwIiR+bbQYhncMtCZggceYaOOm1hj37+GvvSrLHiI7dlywoxUv3mfvXB62HXQ= X-Received: by 2002:a17:907:5096:: with SMTP id fv22mr37457462ejc.525.1626877855685; Wed, 21 Jul 2021 07:30:55 -0700 (PDT) MIME-Version: 1.0 References: <20210721140424.725744-1-maxime@cerno.tech> <20210721140424.725744-6-maxime@cerno.tech> In-Reply-To: <20210721140424.725744-6-maxime@cerno.tech> From: Rob Herring Date: Wed, 21 Jul 2021 08:30:43 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/54] dt-bindings: Convert Reserved Memory binding to a schema To: Maxime Ripard , Grant Likely Cc: Chen-Yu Tsai , Jernej Skrabec , devicetree@vger.kernel.org, Frank Rowand , linux-arm-kernel , linux-sunxi@googlegroups.com, Mailing List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210721_073058_077439_A2FE6138 X-CRM114-Status: GOOD ( 41.95 ) 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 Wed, Jul 21, 2021 at 8:04 AM Maxime Ripard wrote: > > The Reserved Memory mechanism is supported by Linux thanks to its device > tree binding. > > Now that we have the DT validation in place, let's convert the device > tree bindings for that driver over to a YAML schema. Thanks for this! > > Cc: Mailing List > Signed-off-by: Maxime Ripard > --- > .../reserved-memory/reserved-memory.txt | 141 --------------- > .../reserved-memory/reserved-memory.yaml | 167 ++++++++++++++++++ > 2 files changed, 167 insertions(+), 141 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > new file mode 100644 > index 000000000000..b61527f11953 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > @@ -0,0 +1,167 @@ > +# SPDX-License-Identifier: GPL-2.0 I think this is okay to dual license. Grant (Linaro) is the original author and there's only a few lines from other authors. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: /reserved-memory Node > + > +maintainers: > + - Devicetree Specification Mailing List > + > +description: > > + Reserved memory is specified as a node under the /reserved-memory node. The > + operating system shall exclude reserved memory from normal usage one can > + create child nodes describing particular reserved (excluded from normal use) > + memory regions. Such memory regions are usually designed for the special > + usage by various device drivers. > + > +properties: > + $nodename: > + const: reserved-memory > + > + "#address-cells": true > + "#size-cells": true > + ranges: true > + > +patternProperties: > + "^(?!(ranges))[a-z,-]*(@[0-9]+)?$": Note that you could drop this and put under 'additionalProperties'. You would lose some node name checking, but there's really little standard on these nodes. > + type: object > + > + description: > > + Each child of the reserved-memory node specifies one or more regions of > + reserved memory. Each child node may either use a 'reg' property to > + specify a specific range of reserved memory, or a 'size' property with > + optional constraints to request a dynamically allocated block of memory. > + > + Following the generic-names recommended practice, node names should > + reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit > + address (@
) should be appended to the name if the node is a > + static allocation. > + > + properties: > + reg: true > + > + size: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Length based on parent's \#size-cells. Size in bytes of memory to > + reserve. > + > + alignment: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Length based on parent's \#size-cells. Address boundary for > + alignment of allocation. > + > + alloc-ranges: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Address and Length pairs. Specifies regions of memory that are > + acceptable to allocate from. > + > + compatible: > + oneOf: > + - const: shared-dma-pool > + description: > > + This indicates a region of memory meant to be used as a shared > + pool of DMA buffers for a set of devices. It can be used by an > + operating system to instantiate the necessary pool management > + subsystem if necessary. > + > + # Vendor-specific compatibles in the form ,[-] > + - const: mediatek,trustzone-bootinfo I think these should be separate schema files. At least, we're going to need to support separate files because I don't think we want ones adding custom properties here. This would fail unless we add every compatible here. We could also be a bit more exact as to which properties below apply (e.g. linux,.*-default is only valid for shared-dma-pool). > + > + no-map: > + type: boolean > + description: > > + Indicates the operating system must not create a virtual mapping of > + the region as part of its standard mapping of system memory, nor > + permit speculative access to it under any circumstances other than > + under the control of the device driver using the region. > + > + reusable: > + type: boolean > + description: > > + The operating system can use the memory in this region with the > + limitation that the device driver(s) owning the region need to be > + able to reclaim it back. Typically that means that the operating > + system can use that region to store volatile or cached data that > + can be otherwise regenerated or migrated elsewhere. > + > + linux,cma-default: > + type: boolean > + description: > > + If this property is present, then Linux will use the region for the > + default pool of the contiguous memory allocator. > + > + linux,dma-default: > + type: boolean > + description: > > + If this property is present, then Linux will use the region for the > + default pool of the consistent DMA allocator. > + > + allOf: > + - if: > + required: > + - no-map > + > + then: > + not: > + required: > + - reusable > + > + - if: > + required: > + - reusable > + > + then: > + not: > + required: > + - no-map > + > + oneOf: > + - required: > + - reg > + > + - required: > + - size > + > + additionalProperties: true > + > +additionalProperties: true This should be false, right? > + > +examples: > + - | > + / { > + #address-cells = <1>; > + #size-cells = <1>; > + model = "MediaTek MT2701 evaluation board"; > + compatible = "mediatek,mt2701-evb", "mediatek,mt2701"; > + > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + /* global autoconfigured region for contiguous allocations */ > + linux,cma { > + compatible = "shared-dma-pool"; > + reusable; > + size = <0x4000000>; > + alignment = <0x2000>; > + linux,cma-default; > + }; > + > + display_reserved: framebuffer@78000000 { > + reg = <0x78000000 0x800000>; > + }; > + > + trustzone-bootinfo@80002000 { > + compatible = "mediatek,trustzone-bootinfo"; > + reg = <0x80002000 0x1000>; > + }; > + }; > + }; > + > +... > -- > 2.31.1 > _______________________________________________ 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 From: Rob Herring Subject: Re: [PATCH 05/54] dt-bindings: Convert Reserved Memory binding to a schema Date: Wed, 21 Jul 2021 08:30:43 -0600 Message-ID: References: <20210721140424.725744-1-maxime@cerno.tech> <20210721140424.725744-6-maxime@cerno.tech> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626877857; bh=ItoMV2w0siUwl28cOzY8vDd1juPLnJDPTjp4OHicjsY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ClvtVxu6OzSCTr6zmptraNDY5OLNM624UREm7ezvDoU7BW5bC7r8V6ZGzAZy4bz+s sJmW+LWR+x+z38wxw+FmxcRcR3VpAili1h7VPCl3/irV2M+zsa6ltHGlpNRW3joXxb qiGO227LA3oUUwE+OoUR5Fu8ZX+U03rbDw2VN5xN/OfXGUj4oZJLRs7BhcNb9PHRHa lMOv2MfIHgkGFQInTs+9K/XPN8JjjdnzcYx83pg5Go6wg10Pw7FlgESAqmTDqVrVDX vXdI0cnQYmzHSoBs+o0R54zCBZ3MKEfh4VhiWFx5NPNp2fXiHaImlqF/qOEP0ti2ob j+9LQ+FyekYLw== In-Reply-To: <20210721140424.725744-6-maxime-R63rPqgGiG5yDzI6CaY1VQ@public.gmane.org> List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Maxime Ripard , Grant Likely Cc: Chen-Yu Tsai , Jernej Skrabec , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Frank Rowand , linux-arm-kernel , linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Mailing List On Wed, Jul 21, 2021 at 8:04 AM Maxime Ripard wrote: > > The Reserved Memory mechanism is supported by Linux thanks to its device > tree binding. > > Now that we have the DT validation in place, let's convert the device > tree bindings for that driver over to a YAML schema. Thanks for this! > > Cc: Mailing List > Signed-off-by: Maxime Ripard > --- > .../reserved-memory/reserved-memory.txt | 141 --------------- > .../reserved-memory/reserved-memory.yaml | 167 ++++++++++++++++++ > 2 files changed, 167 insertions(+), 141 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > new file mode 100644 > index 000000000000..b61527f11953 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > @@ -0,0 +1,167 @@ > +# SPDX-License-Identifier: GPL-2.0 I think this is okay to dual license. Grant (Linaro) is the original author and there's only a few lines from other authors. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: /reserved-memory Node > + > +maintainers: > + - Devicetree Specification Mailing List > + > +description: > > + Reserved memory is specified as a node under the /reserved-memory node. The > + operating system shall exclude reserved memory from normal usage one can > + create child nodes describing particular reserved (excluded from normal use) > + memory regions. Such memory regions are usually designed for the special > + usage by various device drivers. > + > +properties: > + $nodename: > + const: reserved-memory > + > + "#address-cells": true > + "#size-cells": true > + ranges: true > + > +patternProperties: > + "^(?!(ranges))[a-z,-]*(@[0-9]+)?$": Note that you could drop this and put under 'additionalProperties'. You would lose some node name checking, but there's really little standard on these nodes. > + type: object > + > + description: > > + Each child of the reserved-memory node specifies one or more regions of > + reserved memory. Each child node may either use a 'reg' property to > + specify a specific range of reserved memory, or a 'size' property with > + optional constraints to request a dynamically allocated block of memory. > + > + Following the generic-names recommended practice, node names should > + reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit > + address (@
) should be appended to the name if the node is a > + static allocation. > + > + properties: > + reg: true > + > + size: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Length based on parent's \#size-cells. Size in bytes of memory to > + reserve. > + > + alignment: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Length based on parent's \#size-cells. Address boundary for > + alignment of allocation. > + > + alloc-ranges: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > > + Address and Length pairs. Specifies regions of memory that are > + acceptable to allocate from. > + > + compatible: > + oneOf: > + - const: shared-dma-pool > + description: > > + This indicates a region of memory meant to be used as a shared > + pool of DMA buffers for a set of devices. It can be used by an > + operating system to instantiate the necessary pool management > + subsystem if necessary. > + > + # Vendor-specific compatibles in the form ,[-] > + - const: mediatek,trustzone-bootinfo I think these should be separate schema files. At least, we're going to need to support separate files because I don't think we want ones adding custom properties here. This would fail unless we add every compatible here. We could also be a bit more exact as to which properties below apply (e.g. linux,.*-default is only valid for shared-dma-pool). > + > + no-map: > + type: boolean > + description: > > + Indicates the operating system must not create a virtual mapping of > + the region as part of its standard mapping of system memory, nor > + permit speculative access to it under any circumstances other than > + under the control of the device driver using the region. > + > + reusable: > + type: boolean > + description: > > + The operating system can use the memory in this region with the > + limitation that the device driver(s) owning the region need to be > + able to reclaim it back. Typically that means that the operating > + system can use that region to store volatile or cached data that > + can be otherwise regenerated or migrated elsewhere. > + > + linux,cma-default: > + type: boolean > + description: > > + If this property is present, then Linux will use the region for the > + default pool of the contiguous memory allocator. > + > + linux,dma-default: > + type: boolean > + description: > > + If this property is present, then Linux will use the region for the > + default pool of the consistent DMA allocator. > + > + allOf: > + - if: > + required: > + - no-map > + > + then: > + not: > + required: > + - reusable > + > + - if: > + required: > + - reusable > + > + then: > + not: > + required: > + - no-map > + > + oneOf: > + - required: > + - reg > + > + - required: > + - size > + > + additionalProperties: true > + > +additionalProperties: true This should be false, right? > + > +examples: > + - | > + / { > + #address-cells = <1>; > + #size-cells = <1>; > + model = "MediaTek MT2701 evaluation board"; > + compatible = "mediatek,mt2701-evb", "mediatek,mt2701"; > + > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + /* global autoconfigured region for contiguous allocations */ > + linux,cma { > + compatible = "shared-dma-pool"; > + reusable; > + size = <0x4000000>; > + alignment = <0x2000>; > + linux,cma-default; > + }; > + > + display_reserved: framebuffer@78000000 { > + reg = <0x78000000 0x800000>; > + }; > + > + trustzone-bootinfo@80002000 { > + compatible = "mediatek,trustzone-bootinfo"; > + reg = <0x80002000 0x1000>; > + }; > + }; > + }; > + > +... > -- > 2.31.1 >