From patchwork Thu Sep 15 00:32:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julius Werner X-Patchwork-Id: 606722 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8BC3ECAAD3 for ; Thu, 15 Sep 2022 00:32:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230107AbiIOAcj (ORCPT ); Wed, 14 Sep 2022 20:32:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230095AbiIOAci (ORCPT ); Wed, 14 Sep 2022 20:32:38 -0400 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A96B86FD5 for ; Wed, 14 Sep 2022 17:32:33 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id fs14so16152176pjb.5 for ; Wed, 14 Sep 2022 17:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date; bh=wgA0pQDx3veU9g0AoVu5wc85WYVoT5GTHjt98pcKj9k=; b=mobLF2m/Bm7QflNMvTf+auy6gLr0+oTzSWRF5VlrT7aEbDZmRcWt9teXqQi2jq2qkY EEp2VqygMUUR9p8KdUkOcbIzGlaLM2bpGmJw3zft6RxbmRykjjJVdYeHoaQ6WbS2y0J/ JU/DOwPF8/xYnMuYalPu99y65ebSYiGGOFxdY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=wgA0pQDx3veU9g0AoVu5wc85WYVoT5GTHjt98pcKj9k=; b=lTkVagFG9ElMXGZSsy/85iM3NbtcMHjroqShIk92Me4Q8f9r9DAQ+/4NtZotYr5BIe Mwb9edKH0bs6NexpOcM1pePik+qlSXevQ7dbwdnR6nZOb4DMSb1FXUA5z/axyxPWMskJ 9CkvfN2B9Gwf6JzXJrdiYlXVy8cgRNb+fhv8BhY+gNFPiB5sY6GGFQoZVLAsj36RsOIj lQQKgy0jc/wZE3niQhDG4ybvBd1YNRGZhBen/IfKFkIaF7jh0U6SpgCGE7jryygFcYrK g8HXohjrjpaexe8tFHde1WYwAyqrebBpYBE4Rx9/i8bCxHdb1CD12E8tAMa+fG0hUnxs ehsA== X-Gm-Message-State: ACrzQf1cHibJQZiun30/Mt5QRhznLKxQFRR6JtpB8Zvq1iwHutwxgDf4 cjDehqT/tzyaks8Ilbq8fQUZBUUEvuNjdA== X-Google-Smtp-Source: AMsMyM4w69T/vqw4XP1OMabuKOrP+WlzN90PH8kVL60I39PX3eLtYbvrXFzq8OJAQLplRPaFbu7p6g== X-Received: by 2002:a17:902:a418:b0:174:6711:92c1 with SMTP id p24-20020a170902a41800b00174671192c1mr1609699plq.146.1663201953163; Wed, 14 Sep 2022 17:32:33 -0700 (PDT) Received: from jwerner-p920.mtv.corp.google.com ([2620:15c:202:201:347e:2a81:558b:d912]) by smtp.gmail.com with ESMTPSA id 199-20020a6214d0000000b0053e22c7f135sm10991202pfu.141.2022.09.14.17.32.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 17:32:32 -0700 (PDT) From: Julius Werner To: Krzysztof Kozlowski , Rob Herring Cc: Dmitry Osipenko , Doug Anderson , Jian-Jia Su , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Julius Werner Subject: [PATCH 2/4 v4] dt-bindings: memory: Add numeric LPDDR compatible string variant Date: Wed, 14 Sep 2022 17:32:20 -0700 Message-Id: <20220915003222.1296421-2-jwerner@chromium.org> X-Mailer: git-send-email 2.37.2.789.g6183377224-goog In-Reply-To: <20220915003222.1296421-1-jwerner@chromium.org> References: <20220915003222.1296421-1-jwerner@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org This patch allows a new kind of compatible string for LPDDR parts in the device tree bindings, in addition to the existing hardcoded , strings. The new format contains manufacturer and part (revision) information in numerical form, such as lpddr3-ff,0201 for an LPDDR3 part with manufacturer ID ff and revision ID 0201. This helps cases where LPDDR parts are probed at runtime by boot firmware and cannot be matched to hardcoded part numbers, such as the firmware on the qcom/sc7280-herobrine boards does (which supports 4 different memory configurations at the moment, and more are expected to be added later at a point where the boot firmware can no longer be updated to specifically accomodate them). Signed-off-by: Julius Werner --- .../memory-controllers/ddr/jedec,lpddr-props.yaml | 10 ++++++++++ .../memory-controllers/ddr/jedec,lpddr2.yaml | 8 +++++--- .../memory-controllers/ddr/jedec,lpddr3.yaml | 12 ++++++++---- 3 files changed, 23 insertions(+), 7 deletions(-) Changelog: - v2 - Updated commit message to describe intended use case as an example - v3 - no changes - v4 - no changes diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml index 02700ac3c387ec..4114cfa8de67f1 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml @@ -15,6 +15,16 @@ maintainers: - Krzysztof Kozlowski properties: + compatible: + description: + Compatible strings can be either explicit vendor names and part numbers + (e.g. elpida,ECB240ABACN), or generated strings of the form + lpddrX-YY,ZZZZ where X is the LPDDR version, YY is the manufacturer ID + (from MR5) and ZZZZ is the revision ID (from MR6 and MR7). Both IDs are + formatted in lower case hexadecimal representation with leading zeroes. + The latter form can be useful when LPDDR nodes are created at runtime by + boot firmware that doesn't have access to static part number information. + revision-id: $ref: /schemas/types.yaml#/definitions/uint32-array description: diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml index e5e15d288d89b2..a237bc259273bf 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml @@ -20,13 +20,15 @@ properties: - elpida,ECB240ABACN - elpida,B8132B2PB-6D-F - enum: - - jedec,lpddr2-s4 - - items: - - enum: + - jedec,lpddr2-nvm - jedec,lpddr2-s2 + - jedec,lpddr2-s4 - items: + - pattern: "^lpddr2-[0-9a-f]{2},[0-9a-f]{4}$" - enum: - jedec,lpddr2-nvm + - jedec,lpddr2-s2 + - jedec,lpddr2-s4 revision-id1: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml index 0f7ab51842ae09..e328a1195ba646 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml @@ -14,10 +14,14 @@ allOf: properties: compatible: - items: - - enum: - - samsung,K3QF2F20DB - - const: jedec,lpddr3 + oneOf: + - items: + - enum: + - samsung,K3QF2F20DB + - const: jedec,lpddr3 + - items: + - pattern: "^lpddr3-[0-9a-f]{2},[0-9a-f]{4}$" + - const: jedec,lpddr3 '#address-cells': const: 1 From patchwork Thu Sep 15 00:32:22 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julius Werner X-Patchwork-Id: 606721 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62BC4C6FA89 for ; Thu, 15 Sep 2022 00:32:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230095AbiIOAcn (ORCPT ); Wed, 14 Sep 2022 20:32:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230113AbiIOAck (ORCPT ); Wed, 14 Sep 2022 20:32:40 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A62E89919 for ; Wed, 14 Sep 2022 17:32:36 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id q15-20020a17090a304f00b002002ac83485so15990523pjl.0 for ; Wed, 14 Sep 2022 17:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date; bh=XmAEu+rEqMnoQ4fYaJ1lwcyZ2oHP4Ye2gu5ZnE2+iKI=; b=b9zRb5qx26NUMFO1t3kdBHxBzUummX61WcTsSce8Wh+jvgHT2w9HZ77xKg8/lbEJAV NvKUrGrdluj4TJyMiDRW8qvnQoqUohlvHxEm+0Kqx1vHe0Ab52ySj5SUMx5YxLuBmCDm HQnW1VB9bjJydsu4znkdg41Hpg6xxxpOx5vBo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=XmAEu+rEqMnoQ4fYaJ1lwcyZ2oHP4Ye2gu5ZnE2+iKI=; b=1dVcAsV7h88bv6BGD1tAmgfGWLf42xx+IaruFaj6qsX40JO4v8RBeG65keF4fMTbVJ 6OkFoZHcdEHRSCD4DlS4B0IkHeYT+vzc6Vzin2WI4XYqJ4o5egubM9woExk9ZSzqGyYG 0h4Ytn2I7L6pEItUiLB8TEVdtaPv1wqSw2Oj84iCBnSNapbj0BELF23fcWPb6L+u9f+r MSBVEVFVgjpYZMatWeScevHcxTxHTsBl4nME0lpRKhhjt3mXFZRKGJr/0lYR8IeWpQue /NM9nPU0X//BoQ9UcPUFowJ7aj9GlTbMWSK9GfBaJ4QLRZeU4oMjf7IPmKZcq4TinSyn ETEw== X-Gm-Message-State: ACrzQf3rx9uQ8dMMQ73BdaDiIRJ1YFqPcw/eBEi12g/JnfrlOkPcjF4Q Nhu9SqsCe8irC8Ylo42cVKb8p6LAFPgW+Q== X-Google-Smtp-Source: AMsMyM5h+vAYH6x4dFdq8BwMyVkTmfrO+P6807dDuE2WtrINEtklFntFef3cPp2vZ6Sqh5QruBma2g== X-Received: by 2002:a17:90a:d149:b0:1fb:6dfb:1fb8 with SMTP id t9-20020a17090ad14900b001fb6dfb1fb8mr7431902pjw.25.1663201955492; Wed, 14 Sep 2022 17:32:35 -0700 (PDT) Received: from jwerner-p920.mtv.corp.google.com ([2620:15c:202:201:347e:2a81:558b:d912]) by smtp.gmail.com with ESMTPSA id 199-20020a6214d0000000b0053e22c7f135sm10991202pfu.141.2022.09.14.17.32.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 17:32:34 -0700 (PDT) From: Julius Werner To: Krzysztof Kozlowski , Rob Herring Cc: Dmitry Osipenko , Doug Anderson , Jian-Jia Su , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Julius Werner Subject: [PATCH 4/4 v4] dt-bindings: memory: Add jedec,lpddrX-channel binding Date: Wed, 14 Sep 2022 17:32:22 -0700 Message-Id: <20220915003222.1296421-4-jwerner@chromium.org> X-Mailer: git-send-email 2.37.2.789.g6183377224-goog In-Reply-To: <20220915003222.1296421-1-jwerner@chromium.org> References: <20220915003222.1296421-1-jwerner@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org This patch adds a new device tree binding for an LPDDR channel to serve as a top-level organizing node for LPDDR part nodes nested below it. An LPDDR channel needs to have an "io-width" property to describe its width (this is important because this width does not always match the io-width of the part number, indicating that multiple parts are wired in parallel on the same channel), as well as one or more nested "rank@X" nodes. Those represent information about the individual ranks of each LPDDR part connected on that channel and should match the existing "jedec,lpddrX" bindings for individual LPDDR parts. New platforms should be using this node -- the existing practice of providing a raw, toplevel "jedec,lpddrX" node without indication of how many identical parts are in the system should be considered deprecated. Signed-off-by: Julius Werner --- .../ddr/jedec,lpddr-channel.yaml | 146 ++++++++++++++++++ .../ddr/jedec,lpddr-props.yaml | 10 +- 2 files changed, 155 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml Changelog: - v2: - changed $ref for rank subnode to specifically match LPDDR type in compatible string - moved `reg` up to be listed right below `compatible` - v3: - no changes - v4: - no changes diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml new file mode 100644 index 00000000000000..34b5bd153f63e0 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr-channel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR channel with chip/rank topology description + +description: + An LPDDR channel is a completely independent set of LPDDR pins (DQ, CA, CS, + CK, etc.) that connect one or more LPDDR chips to a host system. The main + purpose of this node is to overall LPDDR topology of the system, including the + amount of individual LPDDR chips and the ranks per chip. + +maintainers: + - Julius Werner + +properties: + compatible: + enum: + - jedec,lpddr2-channel + - jedec,lpddr3-channel + - jedec,lpddr4-channel + - jedec,lpddr5-channel + + io-width: + description: + The number of DQ pins in the channel. If this number is different + from (a multiple of) the io-width of the LPDDR chip, that means that + multiple instances of that type of chip are wired in parallel on this + channel (with the channel's DQ pins split up between the different + chips, and the CA, CS, etc. pins of the different chips all shorted + together). This means that the total physical memory controlled by a + channel is equal to the sum of the densities of each rank on the + connected LPDDR chip, times the io-width of the channel divided by + the io-width of the LPDDR chip. + enum: + - 8 + - 16 + - 32 + - 64 + - 128 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^rank@[0-9]+$": + type: object + description: + Each physical LPDDR chip may have one or more ranks. Ranks are + internal but fully independent sub-units of the chip. Each LPDDR bus + transaction on the channel targets exactly one rank, based on the + state of the CS pins. Different ranks may have different densities and + timing requirements. + required: + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: jedec,lpddr2-channel + then: + patternProperties: + "^rank@[0-9]+$": + $ref: /schemas/memory-controllers/ddr/jedec,lpddr2.yaml# + - if: + properties: + compatible: + contains: + const: jedec,lpddr3-channel + then: + patternProperties: + "^rank@[0-9]+$": + $ref: /schemas/memory-controllers/ddr/jedec,lpddr3.yaml# + - if: + properties: + compatible: + contains: + const: jedec,lpddr4-channel + then: + patternProperties: + "^rank@[0-9]+$": + $ref: /schemas/memory-controllers/ddr/jedec,lpddr4.yaml# + - if: + properties: + compatible: + contains: + const: jedec,lpddr5-channel + then: + patternProperties: + "^rank@[0-9]+$": + $ref: /schemas/memory-controllers/ddr/jedec,lpddr5.yaml# + +required: + - compatible + - io-width + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + lpddr-channel0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "jedec,lpddr3-channel"; + io-width = <32>; + + rank@0 { + compatible = "lpddr3-ff,0100", "jedec,lpddr3"; + reg = <0>; + density = <8192>; + io-width = <16>; + revision-id = <1 0>; + }; + }; + + lpddr-channel1 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "jedec,lpddr4-channel"; + io-width = <32>; + + rank@0 { + compatible = "lpddr4-05,0301", "jedec,lpddr4"; + reg = <0>; + density = <4096>; + io-width = <32>; + revision-id = <3 1>; + }; + + rank@1 { + compatible = "lpddr4-05,0301", "jedec,lpddr4"; + reg = <1>; + density = <2048>; + io-width = <32>; + revision-id = <3 1>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml index 92ef660888f318..30267ce701249a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml @@ -9,7 +9,8 @@ title: Common properties for LPDDR types description: Different LPDDR types generally use the same properties and only differ in the range of legal values for each. This file defines the common parts that can be - reused for each type. + reused for each type. Nodes using this schema should generally be nested under + an LPDDR channel node. maintainers: - Krzysztof Kozlowski @@ -25,6 +26,13 @@ properties: The latter form can be useful when LPDDR nodes are created at runtime by boot firmware that doesn't have access to static part number information. + reg: + description: + The rank number of this LPDDR rank when used as a subnode to an LPDDR + channel. + minimum: 0 + maximum: 3 + revision-id: $ref: /schemas/types.yaml#/definitions/uint32-array description: