Message ID | 20240201210529.7728-2-quic_c_gdjako@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-48847-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:9bc1:b0:106:209c:c626 with SMTP id op1csp23309dyc; Thu, 1 Feb 2024 13:07:03 -0800 (PST) X-Google-Smtp-Source: AGHT+IExGpt2fa1Lg6ATKGf0zNDQT27SlIitBhNDX1+DdXsGhGE2CIbM9aMYNYFKquB7wlmro5+s X-Received: by 2002:a17:906:fcc9:b0:a35:e5bf:b585 with SMTP id qx9-20020a170906fcc900b00a35e5bfb585mr145573ejb.35.1706821622907; Thu, 01 Feb 2024 13:07:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706821622; cv=pass; d=google.com; s=arc-20160816; b=YxJWRDtsq9pUcXqMED4KSY3I44RBEu9vZKDVxY6tQrvpcJCsHY8Gj+OqJ7CNDjE83x b6t2yG6ss988bfOROU/C5SHtsyd9pk7lUEDAIa7sBQ2GjvNBxE88r6IhzzMyGP5a2Z7x tToAXNcyqbADMIb4zMFKcyiqrOp2ByTVChjNgXYlIFEmmcQ3SGq2vZNcHtYydtRhcRR/ MIf4qMX7irD9wm8VmkzVFtsUYATGkDS1wdPUbfo4YO4R7vYpy43APha5FyOkVvHMzuKT c1+NxZ68E67ojID+Nx43ythybhdsllasAOrwUf7cOGFPVxdr2tdGYNK6jxS6MsRN2mpB DuSQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=iNUFl+O4Q+nSOF+40pkCYbU/d8xhFCc4glTBr+0sDes=; fh=c7uAj6tdlTNPqvniKDY8jg46YnFhgCaOG66KbLhFGaE=; b=aWBYYjtCMXg3ljrkFIsY2afatpNyVm5Dw0LWW1gs6o16K+N0mOa4eJneI57DBdS315 OKmxOQmd6ULmGMnx2F7uXfHL5eht435epoVm+49s0pH4v+XJXoulXgw75m0mzAX0dPst e1UQt3X6kKw81RCjxEJRGI/MjXwXgU1soKnguMKTXoydEvABoyZm3Cei57YA+VU3FX3q 79k3puIDoCjIoJH8mqCAIrWp/K/eqptwpU3K0FF7x0lT3Vp2VoFBugXUFRGXfRhV1Sfp 7W2sQLAY+ciPxPg6lFnsUTTvm3kG98c73Oyy1eFBLzg8nUaLhEfJPAURyHJ1Pt/uWim5 ts2g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=CCsN8STO; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-48847-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-48847-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com X-Forwarded-Encrypted: i=1; AJvYcCXU4iJB22R2k0xRtSGKJnsdU2GoQPqkpkLsb8lyd/MKpijcB7N456fOfunfhXlr0HLIZhCMDH8JHXvjZCot4NobBxrBKA== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id kj19-20020a170907765300b00a35990c2b5csi149650ejc.407.2024.02.01.13.07.02 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 13:07:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-48847-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=CCsN8STO; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-48847-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-48847-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 211921F26C21 for <ouuuleilei@gmail.com>; Thu, 1 Feb 2024 21:06:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DB9273FE58; Thu, 1 Feb 2024 21:06:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="CCsN8STO" Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AAEC12FB12; Thu, 1 Feb 2024 21:05:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706821560; cv=none; b=tpT+jRdCHYFRXmUfepsjTPwsP0Wu2LIoPPuf/vJaIO1Dx1UOgix1tjwVyAfzSf54iDhDfr9wnnrHLNfKhFe1Ypj5gvK5SXnUpFVk6QbplIVQUYcPxiaAXxr/rXarOhuLLBZH6bNABcgZ4DBRI8D49mu+y0LUmO9nyvop6KvYm3w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706821560; c=relaxed/simple; bh=/+/FVvxYw1m3V4PhXzToj3z3g3YjB/Ca5+UW7tj+rmI=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HT+taFTJ8Eb5WdGPMy9YnhT4jwOxy2CNWDJVelNqfHNNMHtCLg6l/2R+jtJdnbeUQahJIPdkUbeOE03+L5c1UA9xeRTcdbsBXIhPvYgOJ1bq1oeQqW2jO1OH9ccE1RunSSkr3ymBqQBDVOiYre8TXvfYaFPMtyn+N1OwdVNqlRo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=CCsN8STO; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 411Jmb1u032191; Thu, 1 Feb 2024 21:05:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; s=qcppdkim1; bh=iNUFl+O4Q+nSOF+40pkC YbU/d8xhFCc4glTBr+0sDes=; b=CCsN8STOuOQydrW2DiW9sLzAgCcnWBlTWOxH 8pO3bAmGbIR/FtkFFmjwZ60zscEnNvuMDHNGHWohrAUI4me7/oliDb+f/GRUj8XL XngxdUgNdraRY21pNBrTVczEXmYcV92nqOblcD/Jo9G8+JOk467HUtRFaMG7JYAI plSG00FDcw1ySYghtEl1RWbDuaYw1H/BI/VXZSM6WFBJG80n5k6mf41WfsScBSYE ZzEVR1J8TpgqsPFh1rcCTo71Gq94XUx+XpuhQdEDi5mklmxwrajqnwblikmO/WkN xX+wLYZoRDww66GeEFI4Mqg62dQ9iemVT0q722EYhBY4quGVJA== Received: from nasanppmta02.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3w0b4y16vh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Feb 2024 21:05:41 +0000 (GMT) Received: from nasanex01a.na.qualcomm.com (nasanex01a.na.qualcomm.com [10.52.223.231]) by NASANPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 411L5eZv028370 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Feb 2024 21:05:40 GMT Received: from hu-c-gdjako-lv.qualcomm.com (10.49.16.6) by nasanex01a.na.qualcomm.com (10.52.223.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Thu, 1 Feb 2024 13:05:39 -0800 From: Georgi Djakov <quic_c_gdjako@quicinc.com> To: <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <will@kernel.org>, <robin.murphy@arm.com>, <joro@8bytes.org>, <iommu@lists.linux.dev> CC: <devicetree@vger.kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <robdclark@gmail.com>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <quic_cgoldswo@quicinc.com>, <quic_sukadev@quicinc.com>, <quic_pdaly@quicinc.com>, <quic_sudaraja@quicinc.com>, <djakov@kernel.org> Subject: [PATCH v4 01/10] dt-bindings: iommu: Add Translation Buffer Unit bindings Date: Thu, 1 Feb 2024 13:05:20 -0800 Message-ID: <20240201210529.7728-2-quic_c_gdjako@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240201210529.7728-1-quic_c_gdjako@quicinc.com> References: <20240201210529.7728-1-quic_c_gdjako@quicinc.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: nalasex01a.na.qualcomm.com (10.47.209.196) To nasanex01a.na.qualcomm.com (10.52.223.231) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: BDMj7KM5nmqU7Ej7G0k1JUIEKGi1vezK X-Proofpoint-GUID: BDMj7KM5nmqU7Ej7G0k1JUIEKGi1vezK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-01_06,2024-01-31_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 malwarescore=0 bulkscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 adultscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2401190000 definitions=main-2402010163 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789732190331644592 X-GMAIL-MSGID: 1789732190331644592 |
Series |
Add support for Translation Buffer Units
|
|
Commit Message
Georgi Djakov
Feb. 1, 2024, 9:05 p.m. UTC
Add common bindings for the TBUs to describe their properties. The
TBUs are modelled as child devices of the IOMMU and each of them is
described with their compatible, reg and stream-id-range properties.
There could be other implementation specific properties to describe
any resources like clocks, regulators, power-domains, interconnects
that would be needed for TBU operation. Such properties will be
documented in a separate vendor-specific TBU schema.
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
---
.../devicetree/bindings/iommu/arm,smmu.yaml | 14 ++++++++++
.../devicetree/bindings/iommu/tbu-common.yaml | 28 +++++++++++++++++++
2 files changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/tbu-common.yaml
Comments
On Thu, Feb 01, 2024 at 01:05:20PM -0800, Georgi Djakov wrote: > Add common bindings for the TBUs to describe their properties. The > TBUs are modelled as child devices of the IOMMU and each of them is > described with their compatible, reg and stream-id-range properties. > There could be other implementation specific properties to describe > any resources like clocks, regulators, power-domains, interconnects > that would be needed for TBU operation. Such properties will be > documented in a separate vendor-specific TBU schema. > > Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com> > --- > .../devicetree/bindings/iommu/arm,smmu.yaml | 14 ++++++++++ > .../devicetree/bindings/iommu/tbu-common.yaml | 28 +++++++++++++++++++ > 2 files changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iommu/tbu-common.yaml > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > index a4042ae24770..ba3237023b39 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > @@ -235,6 +235,20 @@ properties: > enabled for any given device. > $ref: /schemas/types.yaml#/definitions/phandle > > + '#address-cells': > + enum: [ 1, 2 ] > + > + '#size-cells': > + enum: [ 1, 2 ] > + > + ranges: true > + > +patternProperties: > + "^tbu@[0-9a-f]+$": > + description: TBU child nodes > + type: object > + $ref: tbu-common.yaml# additionalProperties: false However, that's going to break with the extra QCom properties. In json-schema, you can't have 2 schemas and extend the properties of their child nodes. The validator doesn't "see" the child node schemas at the same time. You are going to have to move QCom SMMU to its own schema and remove it from arm,smmu.yaml. Rob
On 2024-02-02 9:17 pm, Rob Herring wrote: > On Thu, Feb 01, 2024 at 01:05:20PM -0800, Georgi Djakov wrote: >> Add common bindings for the TBUs to describe their properties. The >> TBUs are modelled as child devices of the IOMMU and each of them is >> described with their compatible, reg and stream-id-range properties. >> There could be other implementation specific properties to describe >> any resources like clocks, regulators, power-domains, interconnects >> that would be needed for TBU operation. Such properties will be >> documented in a separate vendor-specific TBU schema. >> >> Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com> >> --- >> .../devicetree/bindings/iommu/arm,smmu.yaml | 14 ++++++++++ >> .../devicetree/bindings/iommu/tbu-common.yaml | 28 +++++++++++++++++++ >> 2 files changed, 42 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/iommu/tbu-common.yaml >> >> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml >> index a4042ae24770..ba3237023b39 100644 >> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml >> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml >> @@ -235,6 +235,20 @@ properties: >> enabled for any given device. >> $ref: /schemas/types.yaml#/definitions/phandle >> >> + '#address-cells': >> + enum: [ 1, 2 ] >> + >> + '#size-cells': >> + enum: [ 1, 2 ] >> + >> + ranges: true >> + >> +patternProperties: >> + "^tbu@[0-9a-f]+$": >> + description: TBU child nodes >> + type: object >> + $ref: tbu-common.yaml# > > additionalProperties: false > > > However, that's going to break with the extra QCom properties. In > json-schema, you can't have 2 schemas and extend the properties of > their child nodes. The validator doesn't "see" the child node schemas at > the same time. You are going to have to move QCom SMMU to its own schema > and remove it from arm,smmu.yaml. Although this common binding is pretty pointless - sorry I missed the previous discussion, but these TBU registers are on obscure debugging feature of Qualcomm's own invention and definitely not generic. The internal topology of the unmodified Arm MMU-500 implementation isn't software-visible at all without getting into its own integration and debug registers (and maybe to a lesser extent the PMU), and even then everything is proxied through the TCU via an internal AXI stream interconnect, so there aren't really any TBU-owned resources which would warrant describing as such in DT. If anything, the way this binding is defined as an MMIO bus with "ranges" would actively *prevent* being able to describe the standard hardware this way, since the internal debug stuff all wants to refer to TBUs by numerical index. Conversely, given that the Qualcomm TBU registers seem to be describing their own entirely independent resources and inheriting nothing from the parent node, I'm not sure it's necessarily worth all the bother of describing and supporting them them as children at all, when they could just as well be standalone nodes with a phandle to associate an SMMU instance. Thanks, Robin.
On 2024-02-01 9:05 pm, Georgi Djakov wrote: > Add common bindings for the TBUs to describe their properties. The > TBUs are modelled as child devices of the IOMMU and each of them is > described with their compatible, reg and stream-id-range properties. > There could be other implementation specific properties to describe > any resources like clocks, regulators, power-domains, interconnects > that would be needed for TBU operation. Such properties will be > documented in a separate vendor-specific TBU schema. > > Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com> > --- > .../devicetree/bindings/iommu/arm,smmu.yaml | 14 ++++++++++ > .../devicetree/bindings/iommu/tbu-common.yaml | 28 +++++++++++++++++++ > 2 files changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iommu/tbu-common.yaml > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > index a4042ae24770..ba3237023b39 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > @@ -235,6 +235,20 @@ properties: > enabled for any given device. > $ref: /schemas/types.yaml#/definitions/phandle > > + '#address-cells': > + enum: [ 1, 2 ] > + > + '#size-cells': > + enum: [ 1, 2 ] > + > + ranges: true > + > +patternProperties: > + "^tbu@[0-9a-f]+$": > + description: TBU child nodes > + type: object > + $ref: tbu-common.yaml# > + > required: > - compatible > - reg > diff --git a/Documentation/devicetree/bindings/iommu/tbu-common.yaml b/Documentation/devicetree/bindings/iommu/tbu-common.yaml > new file mode 100644 > index 000000000000..3e95b356e572 > --- /dev/null > +++ b/Documentation/devicetree/bindings/iommu/tbu-common.yaml > @@ -0,0 +1,28 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/iommu/tbu-common.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Translation Buffer Unit (TBU) common properties > + > +maintainers: > + - Georgi Djakov <quic_c_gdjako@quicinc.com> > + > +description: > + The SMMU implements a TBU for system masters. It consists if a > + Translation Lookaside Buffer (TLB) that caches page tables. > + > +properties: > + reg: > + maxItems: 1 > + > + stream-id-range: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: Stream ID range (address and size) that is assigned by the TBU > + items: > + minItems: 2 > + maxItems: 2 Actually, even this doesn't work - for the 15-bit StreamID config, there's no guarantee that the devices behind each TBU will use a single contiguous StreamID range. Conversely, for any other config the StreamIDs are already uniquely associated with a TBU by their top 5 bits, so the "size" doesn't matter. Thanks, Robin. > + > +additionalProperties: true > +...
On 12/02/2024 20:12, Robin Murphy wrote: >>> + '#address-cells': >>> + enum: [ 1, 2 ] >>> + >>> + '#size-cells': >>> + enum: [ 1, 2 ] >>> + >>> + ranges: true >>> + >>> +patternProperties: >>> + "^tbu@[0-9a-f]+$": >>> + description: TBU child nodes >>> + type: object >>> + $ref: tbu-common.yaml# >> >> additionalProperties: false >> >> >> However, that's going to break with the extra QCom properties. In >> json-schema, you can't have 2 schemas and extend the properties of >> their child nodes. The validator doesn't "see" the child node schemas at >> the same time. You are going to have to move QCom SMMU to its own schema >> and remove it from arm,smmu.yaml. > > Although this common binding is pretty pointless - sorry I missed the > previous discussion, but these TBU registers are on obscure debugging Hi Robin, I am not sure if your comments were resolved (no response here), so please kindly check if nothing got lost from your feedback in v5: https://lore.kernel.org/all/20240226172218.69486-2-quic_c_gdjako@quicinc.com/ Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index a4042ae24770..ba3237023b39 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -235,6 +235,20 @@ properties: enabled for any given device. $ref: /schemas/types.yaml#/definitions/phandle + '#address-cells': + enum: [ 1, 2 ] + + '#size-cells': + enum: [ 1, 2 ] + + ranges: true + +patternProperties: + "^tbu@[0-9a-f]+$": + description: TBU child nodes + type: object + $ref: tbu-common.yaml# + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iommu/tbu-common.yaml b/Documentation/devicetree/bindings/iommu/tbu-common.yaml new file mode 100644 index 000000000000..3e95b356e572 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/tbu-common.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/tbu-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Translation Buffer Unit (TBU) common properties + +maintainers: + - Georgi Djakov <quic_c_gdjako@quicinc.com> + +description: + The SMMU implements a TBU for system masters. It consists if a + Translation Lookaside Buffer (TLB) that caches page tables. + +properties: + reg: + maxItems: 1 + + stream-id-range: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Stream ID range (address and size) that is assigned by the TBU + items: + minItems: 2 + maxItems: 2 + +additionalProperties: true +...