Skip to contentSkip to conversation

tegra20-emc: Identify memory chip by LPDDR configuration

PATCH Applied Dmitry Osipenko 4 participants 26 messages Oct 6, 2021 – Feb 11, 2022

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

v5 cover tegra20-emc: Identify memory chip by LPDDR configuration

Support memory chip identification by LPDDR2 configuration, which is needed by ASUS Transformer TF101 tablet device that doesn't store RAMCODE in Tegra's NVMEM.

Changelog:

v5: - Added new patch which adds vendor prefix for Elpida Inc.

- Added new patch that updates existing device-tree to use proper lowercase "elpida," compatible prefix.

- Changed Krzysztof's email address in the LPDDR2 binding.

- Added uint32 types to the LPDDR2 binding, which was requested by Krzysztof Kozlowski.

v4: - Moved DDR bindings directory to memory-controllers/, like it
was suggested by Krzysztof Kozlowski.

- Converted existing LPDDR2 binding to schema and utilized it, like it was requested by Krzysztof Kozlowski.

- Added Elpida B8132B2PB-6D-F compatible.

- Made code changes that were requested by Krzysztof Kozlowski.

v3: - Corrected sub-node name in tegra20-emc.yaml.

v2: - Added separate binding for standard LPDDR2 properties, like it
was suggested by Krzysztof Kozlowski.

- Switched Tegra binding to use new lpddr2-configuration sub-node that contains the standard properties.

- Extended commit message of the "emc: Document new LPDDR2 sub-node" patch, telling how the properties are supposed to be used, which was requested by Krzysztof Kozlowski.

- Added new common helpers for parsing LPDDR2 properties and made tegra20-emc driver to use these helpers.

Dmitry Osipenko (9):
dt-bindings: Relocate DDR bindings
dt-bindings: memory: lpddr2: Convert to schema
dt-bindings: memory: lpddr2: Add revision-id properties
dt-bindings: memory: lpddr2: Document Elpida B8132B2PB-6D-F
dt-bindings: Add vendor prefix for Elpida Memory
ARM: dts: elpida_ecb240abacn: Change Elpida compatible
dt-bindings: memory: tegra20: emc: Document new LPDDR2 sub-node
memory: Add LPDDR2-info helpers
memory: tegra20-emc: Support matching timings by LPDDR2 configuration

 .../devicetree/bindings/ddr/lpddr2.txt        | 102 --------
 .../memory-controllers/ddr/jedec,lpddr2.yaml  | 223 ++++++++++++++++++
 .../ddr/lpddr2-timings.txt                    |   0
 .../ddr/lpddr3-timings.txt                    |   0
 .../{ => memory-controllers}/ddr/lpddr3.txt   |   0
 .../nvidia,tegra20-emc.yaml                   |  23 +-
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm/boot/dts/elpida_ecb240abacn.dtsi     |   2 +-
 drivers/memory/jedec_ddr.h                    |  47 ++++
 drivers/memory/jedec_ddr_data.c               |  41 ++++
 drivers/memory/of_memory.c                    |  87 +++++++
 drivers/memory/of_memory.h                    |   9 +
 drivers/memory/tegra/Kconfig                  |   1 +
 drivers/memory/tegra/tegra20-emc.c            | 199 ++++++++++++++--
 14 files changed, 617 insertions(+), 119 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/ddr/lpddr2.txt
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr2-timings.txt (100%)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr3-timings.txt (100%)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr3.txt (100%)
Signature · 1 line
2.32.0
#1 lore raw

PATCH v5 1/9 dt-bindings: Relocate DDR bindings

Move DDR bindings to memory-controllers directory to make them more discoverable.

---
 .../bindings/{ => memory-controllers}/ddr/lpddr2-timings.txt      | 0
 .../devicetree/bindings/{ => memory-controllers}/ddr/lpddr2.txt   | 0
 .../bindings/{ => memory-controllers}/ddr/lpddr3-timings.txt      | 0
 .../devicetree/bindings/{ => memory-controllers}/ddr/lpddr3.txt   | 0
 4 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr2-timings.txt (100%)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr2.txt (100%)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr3-timings.txt (100%)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr3.txt (100%)
Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt renamed from Documentation/devicetree/bindings/ddr/lpddr2-timings.txt +0 -0
similarity index 100%
rename from Documentation/devicetree/bindings/ddr/lpddr2-timings.txt
rename to Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt
Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2.txt renamed from Documentation/devicetree/bindings/ddr/lpddr2.txt +0 -0
similarity index 100%
rename from Documentation/devicetree/bindings/ddr/lpddr2.txt
rename to Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2.txt
Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt renamed from Documentation/devicetree/bindings/ddr/lpddr3-timings.txt +0 -0
similarity index 100%
rename from Documentation/devicetree/bindings/ddr/lpddr3-timings.txt
rename to Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt
Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt renamed from Documentation/devicetree/bindings/ddr/lpddr3.txt +0 -0
similarity index 100%
rename from Documentation/devicetree/bindings/ddr/lpddr3.txt
rename to Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt
Signature · 1 line
2.32.0
maintainer Acked-by on v5 1/9
#2 lore raw

Re: [PATCH v5 1/9] dt-bindings: Relocate DDR bindings

Quoted 5 lines · Dmitry Osipenko

Move DDR bindings to memory-controllers directory to make them more discoverable.

Quoted 11 lines
---
 .../bindings/{ => memory-controllers}/ddr/lpddr2-timings.txt      | 0
 .../devicetree/bindings/{ => memory-controllers}/ddr/lpddr2.txt   | 0
 .../bindings/{ => memory-controllers}/ddr/lpddr3-timings.txt      | 0
 .../devicetree/bindings/{ => memory-controllers}/ddr/lpddr3.txt   | 0
 4 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr2-timings.txt (100%)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr2.txt (100%)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr3-timings.txt (100%)
 rename Documentation/devicetree/bindings/{ => memory-controllers}/ddr/lpddr3.txt (100%)
#3 lore raw

PATCH v5 2/9 dt-bindings: memory: lpddr2: Convert to schema

In reply to Dmitry Osipenko

Convert LPDDR2 binding to schema. I removed obsolete ti,jedec-lpddr2-* compatibles since they were never used by device-trees and by the code. I also changed "Elpida" compatible prefix to lowercase "elpida".

---
 .../memory-controllers/ddr/jedec,lpddr2.yaml  | 208 ++++++++++++++++++
 .../memory-controllers/ddr/lpddr2.txt         | 102 ---------
 2 files changed, 208 insertions(+), 102 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
 delete mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2.txt
Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml new file +208 -0
new file mode 100644
index 000000000000..f931fe910ce5
@@ -0,0 +1,208 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LPDDR2 SDRAM compliant to JEDEC JESD209-2
+
+maintainers:
+  - Krzysztof Kozlowski <[email protected]>
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - elpida,ECB240ABACN
+          - enum:
+              - jedec,lpddr2-s4
+      - items:
+          - enum:
+              - jedec,lpddr2-s2
+      - items:
+          - enum:
+              - jedec,lpddr2-nvm
+
+  density:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: |
+      Density in megabits of SDRAM chip. Obtained from device datasheet.
+    enum:
+      - 64
+      - 128
+      - 256
+      - 512
+      - 1024
+      - 2048
+      - 4096
+      - 8192
+      - 16384
+      - 32768
+
+  io-width:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: |
+      IO bus width in bits of SDRAM chip. Obtained from device datasheet.
+    enum:
+      - 32
+      - 16
+      - 8
+
+  tRRD-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      Active bank a to active bank b in terms of number of clock cycles.
+      Obtained from device datasheet.
+
+  tWTR-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      Internal WRITE-to-READ command delay in terms of number of clock cycles.
+      Obtained from device datasheet.
+
+  tXP-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      Exit power-down to next valid command delay in terms of number of clock
+      cycles. Obtained from device datasheet.
+
+  tRTP-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      Internal READ to PRECHARGE command delay in terms of number of clock
+      cycles. Obtained from device datasheet.
+
+  tCKE-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      CKE minimum pulse width (HIGH and LOW pulse width) in terms of number
+      of clock cycles. Obtained from device datasheet.
+
+  tRPab-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      Row precharge time (all banks) in terms of number of clock cycles.
+      Obtained from device datasheet.
+
+  tRCD-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      RAS-to-CAS delay in terms of number of clock cycles. Obtained from
+      device datasheet.
+
+  tWR-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      WRITE recovery time in terms of number of clock cycles. Obtained from
+      device datasheet.
+
+  tRASmin-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      Row active time in terms of number of clock cycles. Obtained from device
+      datasheet.
+
+  tCKESR-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      CKE minimum pulse width during SELF REFRESH (low pulse width during
+      SELF REFRESH) in terms of number of clock cycles. Obtained from device
+      datasheet.
+
+  tFAW-min-tck:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 16
+    description: |
+      Four-bank activate window in terms of number of clock cycles. Obtained
+      from device datasheet.
+
+patternProperties:
+  "^lpddr2-timings":
+    type: object
+    description: |
+      The lpddr2 node may have one or more child nodes of type "lpddr2-timings".
+      "lpddr2-timings" provides AC timing parameters of the device for
+      a given speed-bin. The user may provide the timings for as many
+      speed-bins as is required. Please see Documentation/devicetree/
+      bindings/memory-controllers/ddr/lpddr2-timings.txt for more information
+      on "lpddr2-timings".
+
+required:
+  - compatible
+  - density
+  - io-width
+
+additionalProperties: false
+
+examples:
+  - |
+    elpida_ECB240ABACN: lpddr2 {
+        compatible = "elpida,ECB240ABACN", "jedec,lpddr2-s4";
+        density = <2048>;
+        io-width = <32>;
+
+        tRPab-min-tck = <3>;
+        tRCD-min-tck = <3>;
+        tWR-min-tck = <3>;
+        tRASmin-min-tck = <3>;
+        tRRD-min-tck = <2>;
+        tWTR-min-tck = <2>;
+        tXP-min-tck = <2>;
+        tRTP-min-tck = <2>;
+        tCKE-min-tck = <3>;
+        tCKESR-min-tck = <3>;
+        tFAW-min-tck = <8>;
+
+        timings_elpida_ECB240ABACN_400mhz: lpddr2-timings0 {
+            compatible = "jedec,lpddr2-timings";
+            min-freq = <10000000>;
+            max-freq = <400000000>;
+            tRPab = <21000>;
+            tRCD = <18000>;
+            tWR = <15000>;
+            tRAS-min = <42000>;
+            tRRD = <10000>;
+            tWTR = <7500>;
+            tXP = <7500>;
+            tRTP = <7500>;
+            tCKESR = <15000>;
+            tDQSCK-max = <5500>;
+            tFAW = <50000>;
+            tZQCS = <90000>;
+            tZQCL = <360000>;
+            tZQinit = <1000000>;
+            tRAS-max-ns = <70000>;
+        };
+
+        timings_elpida_ECB240ABACN_200mhz: lpddr2-timings1 {
+            compatible = "jedec,lpddr2-timings";
+            min-freq = <10000000>;
+            max-freq = <200000000>;
+            tRPab = <21000>;
+            tRCD = <18000>;
+            tWR = <15000>;
+            tRAS-min = <42000>;
+            tRRD = <10000>;
+            tWTR = <10000>;
+            tXP = <7500>;
+            tRTP = <7500>;
+            tCKESR = <15000>;
+            tDQSCK-max = <5500>;
+            tFAW = <50000>;
+            tZQCS = <90000>;
+            tZQCL = <360000>;
+            tZQinit = <1000000>;
+            tRAS-max-ns = <70000>;
+        };
+    };
Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2.txt deleted +0 -102

102 lines not on this page · raw message

Signature · 1 line
2.32.0
maintainer Reviewed-by on v5 2/9
#4 lore raw

Re: [PATCH v5 2/9] dt-bindings: memory: lpddr2: Convert to schema

Quoted 4 lines · Dmitry Osipenko

Convert LPDDR2 binding to schema. I removed obsolete ti,jedec-lpddr2-* compatibles since they were never used by device-trees and by the code. I also changed "Elpida" compatible prefix to lowercase "elpida".

Quoted 9 lines
---
 .../memory-controllers/ddr/jedec,lpddr2.yaml  | 208 ++++++++++++++++++
 .../memory-controllers/ddr/lpddr2.txt         | 102 ---------
 2 files changed, 208 insertions(+), 102 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
 delete mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2.txt
#5 lore raw

PATCH v5 3/9 dt-bindings: memory: lpddr2: Add revision-id properties

In reply to Dmitry Osipenko

Add optional revision-id standard LPDDR2 properties which will help to identify memory chip.

---
 .../memory-controllers/ddr/jedec,lpddr2.yaml       | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml +14 -0
index f931fe910ce5..fe573750577e 100644
@@ -24,6 +24,18 @@ properties:
           - enum:
               - jedec,lpddr2-nvm
 
+  revision-id1:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 255
+    description: |
+      Revision 1 value of SDRAM chip. Obtained from device datasheet.
+
+  revision-id2:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 255
+    description: |
+      Revision 2 value of SDRAM chip. Obtained from device datasheet.
+
   density:
     $ref: /schemas/types.yaml#/definitions/uint32
     description: |
@@ -151,6 +163,8 @@ examples:
         compatible = "elpida,ECB240ABACN", "jedec,lpddr2-s4";
         density = <2048>;
         io-width = <32>;
+        revision-id1 = <1>;
+        revision-id2 = <0>;
 
         tRPab-min-tck = <3>;
         tRCD-min-tck = <3>;
Signature · 1 line
2.32.0
maintainer Reviewed-by on v5 3/9
#6 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

Quoted 8 lines · Dmitry Osipenko

Add optional revision-id standard LPDDR2 properties which will help to identify memory chip.

---
 .../memory-controllers/ddr/jedec,lpddr2.yaml       | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
#7 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

Apologies for only noticing this a couple of months too late... but this patch added the same thing to the "jedec,lpddr2" bindings that were previously added by
https://www.spinics.net/lists/devicetree/msg413733.html to "jedec,lpddr3", but in a slightly incompatible manner. Should we adjust it to make them consistent (two bytes in one property, rather than a separate property for each)? Or is it too late to change that?

#8 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

Quoted 7 lines · Julius Werner

Apologies for only noticing this a couple of months too late... but this patch added the same thing to the "jedec,lpddr2" bindings that were previously added by
https://www.spinics.net/lists/devicetree/msg413733.html to "jedec,lpddr3", but in a slightly incompatible manner. Should we adjust it to make them consistent (two bytes in one property, rather than a separate property for each)? Or is it too late to change that?

Unfortunately I have no clue what patch you talk about ("this patch"). There is no context here, no link except the older LPDDR3.

The latest discussion is about dtschema conversion, so no new fields are being added:
https://lore.kernel.org/lkml/[email protected]/

Feel free to propose something new on top of it.

Best regards,
Krzysztof

#9 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

Quoted 2 lines

Unfortunately I have no clue what patch you talk about ("this patch"). There is no context here, no link except the older LPDDR3.

Sorry, I tried to reply to
https://lore.kernel.org/all/[email protected]/
([PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties) and was hoping that would automatically provide context. That patch added two one-cell properties revision-id1 and revision-id2 to "jedec,lpddr2". Earlier in
https://www.spinics.net/lists/devicetree/msg413733.html ([PATCH]
dt-bindings: ddr: Add optional manufacturer and revision ID to LPDDR3), I had added a single two-cell property revision-id for the same purpose to "jedec,lpddr3".

I think it would be better if this was consistent between the two types of LPDDR memory. Should I just send a patch that replaces the two revision IDs in "jedec,lpddr2" with a single one according to the principle of "jedec,lpddr3"? Or is it too late for that now and the binding already considered stable and unchangeable?

#10 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

Quoted 14 lines · Julius Werner
Quoted 2 lines

Unfortunately I have no clue what patch you talk about ("this patch"). There is no context here, no link except the older LPDDR3.

Sorry, I tried to reply to
https://lore.kernel.org/all/[email protected]/
([PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties) and was hoping that would automatically provide context. That patch added two one-cell properties revision-id1 and revision-id2 to "jedec,lpddr2". Earlier in
https://www.spinics.net/lists/devicetree/msg413733.html ([PATCH]
dt-bindings: ddr: Add optional manufacturer and revision ID to LPDDR3), I had added a single two-cell property revision-id for the same purpose to "jedec,lpddr3".

Quoted 5 lines

I think it would be better if this was consistent between the two types of LPDDR memory. Should I just send a patch that replaces the two revision IDs in "jedec,lpddr2" with a single one according to the principle of "jedec,lpddr3"? Or is it too late for that now and the binding already considered stable and unchangeable?

Hi Julius,

Having same bindings for revision ID makes sense. Sadly this was not spotted during review, eh, life... Unfortunately the bindings are already in a mainline release, so they are considered stable. You can however bring patches (bindings + drivers/memory/of + dts) which make the revision-id[12] deprecated and introduce new revision-id.

It should be something similar to what I did for max-freq:
https://lore.kernel.org/all/[email protected]/

Dmitry,
Any early comments on such approach from you?

Best regards,
Krzysztof

#11 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

09.02.2022 11:58, Krzysztof Kozlowski пишет:

Quoted 29 lines · Julius Werner
Quoted 14 lines
Quoted 2 lines

Unfortunately I have no clue what patch you talk about ("this patch"). There is no context here, no link except the older LPDDR3.

Sorry, I tried to reply to
https://lore.kernel.org/all/[email protected]/
([PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties) and was hoping that would automatically provide context. That patch added two one-cell properties revision-id1 and revision-id2 to "jedec,lpddr2". Earlier in
https://www.spinics.net/lists/devicetree/msg413733.html ([PATCH]
dt-bindings: ddr: Add optional manufacturer and revision ID to LPDDR3), I had added a single two-cell property revision-id for the same purpose to "jedec,lpddr3".

Quoted 5 lines

I think it would be better if this was consistent between the two types of LPDDR memory. Should I just send a patch that replaces the two revision IDs in "jedec,lpddr2" with a single one according to the principle of "jedec,lpddr3"? Or is it too late for that now and the binding already considered stable and unchangeable?

Hi Julius,

Having same bindings for revision ID makes sense. Sadly this was not spotted during review, eh, life... Unfortunately the bindings are already in a mainline release, so they are considered stable. You can however bring patches (bindings + drivers/memory/of + dts) which make the revision-id[12] deprecated and introduce new revision-id.

Quoted 5 lines

It should be something similar to what I did for max-freq:
https://lore.kernel.org/all/[email protected]/

Dmitry,
Any early comments on such approach from you?

I don't mind, but I also don't see where the revision-id property of LPDDR3 is used at all. I can't find any device-tree with LPDDR3 revision-id and don't see it being used in the code either. Maybe it's the LPDDR3 binding that needs to be changed?
I made each LPDDR2 revision-id property to correspond to a dedicated MR of LPDDR, which feels okay to me to since it matches h/w.

#12 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

Quoted 4 lines

I don't mind, but I also don't see where the revision-id property of LPDDR3 is used at all. I can't find any device-tree with LPDDR3 revision-id and don't see it being used in the code either. Maybe it's the LPDDR3 binding that needs to be changed?

We are using the revision ID in userspace (read through /proc/device-tree) for runtime memory identification. We don't have a kernel driver bound to it. Our boot firmware is inserting this value at runtime into the FDT (that's basically the reason we have this, our firmware auto-detects memory during boot and we use the FDT to report what it found to userspace), that's why you can't find it anywhere in the static device trees in boot/dts/.

Quoted 2 lines

I made each LPDDR2 revision-id property to correspond to a dedicated MR of LPDDR, which feels okay to me to since it matches h/w.

I'm not super married to my solution, so if that makes things easier we can standardize on the two-property version as well. I mostly designed it my way because I thought we may one day also want to do something like this for the 8-byte LPDDR5 serial-id, and then it would get kinda cumbersome to have serial-id1 through serial-id8 all as separate properties. But that's also a bridge we can cross when we get there.

My use case is in a position where we could still change this now without requiring backwards-compatibility. Krzysztof, would you be okay if I instead changed the "jedec,lpddr3" to the same thing "jedec,lpddr2" does -- seeing as the original patch was from me, my use case could handle the switch, there has never been any actual kernel code using the property, and it seems very unlikely that anyone else has silently started using the same thing in the time it's been in the tree? Or do we also need to go the official deprecation route for that?

#13 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

В Wed, 9 Feb 2022 16:32:25 -0800
Julius Werner <[email protected]> пишет:

Quoted 5 lines
Quoted 4 lines

I don't mind, but I also don't see where the revision-id property of LPDDR3 is used at all. I can't find any device-tree with LPDDR3 revision-id and don't see it being used in the code either. Maybe it's the LPDDR3 binding that needs to be changed?

Quoted 7 lines

We are using the revision ID in userspace (read through /proc/device-tree) for runtime memory identification. We don't have a kernel driver bound to it. Our boot firmware is inserting this value at runtime into the FDT (that's basically the reason we have this, our firmware auto-detects memory during boot and we use the FDT to report what it found to userspace), that's why you can't find it anywhere in the static device trees in boot/dts/.

Thank you for the clarification. Which device is that and why userspace needs to know so much about memory?

Quoted 12 lines
Quoted 3 lines

I made each LPDDR2 revision-id property to correspond to a dedicated MR of LPDDR, which feels okay to me to since it matches h/w.

I'm not super married to my solution, so if that makes things easier we can standardize on the two-property version as well. I mostly designed it my way because I thought we may one day also want to do something like this for the 8-byte LPDDR5 serial-id, and then it would get kinda cumbersome to have serial-id1 through serial-id8 all as separate properties. But that's also a bridge we can cross when we get there.

Quoted 9 lines

My use case is in a position where we could still change this now without requiring backwards-compatibility. Krzysztof, would you be okay if I instead changed the "jedec,lpddr3" to the same thing "jedec,lpddr2" does -- seeing as the original patch was from me, my use case could handle the switch, there has never been any actual kernel code using the property, and it seems very unlikely that anyone else has silently started using the same thing in the time it's been in the tree? Or do we also need to go the official deprecation route for that?

If you're going to use multiple cells for other properties, then indeed will be better to keep it consistent.

#14 lore raw

Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

Quoted 25 lines · Dmitry Osipenko

В Wed, 9 Feb 2022 16:32:25 -0800
Julius Werner <[email protected]> пишет:

Quoted 13 lines
Quoted 4 lines

I made each LPDDR2 revision-id property to correspond to a dedicated MR of LPDDR, which feels okay to me to since it matches h/w.

I'm not super married to my solution, so if that makes things easier we can standardize on the two-property version as well. I mostly designed it my way because I thought we may one day also want to do something like this for the 8-byte LPDDR5 serial-id, and then it would get kinda cumbersome to have serial-id1 through serial-id8 all as separate properties. But that's also a bridge we can cross when we get there.

Quoted 9 lines

My use case is in a position where we could still change this now without requiring backwards-compatibility. Krzysztof, would you be okay if I instead changed the "jedec,lpddr3" to the same thing "jedec,lpddr2" does -- seeing as the original patch was from me, my use case could handle the switch, there has never been any actual kernel code using the property, and it seems very unlikely that anyone else has silently started using the same thing in the time it's been in the tree? Or do we also need to go the official deprecation route for that?

Quoted 2 lines

If you're going to use multiple cells for other properties, then indeed will be better to keep it consistent.

Yeah, LPDDR5 is a nice argument. Let's go with the array approach (so LPDDR3).

Julius,
Official deprecation is needed, because the property might be used also in other projects or customers. But this is not a big deal - we will just keep old property for some time.

Will you send a patch for it?

Best regards,
Krzysztof

#15 lore raw

PATCH v5 4/9 dt-bindings: memory: lpddr2: Document Elpida B8132B2PB-6D-F

In reply to Dmitry Osipenko

Elpida B8132B2PB-6D-F memory chip is used by ASUS Transformer TF101 tablet, add compatible for it. We need to specify this compatible it for a device-tree node containing corresponding memory timings in order to allow software to match the timings with the detected hardware.

---
 .../devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml | 1 +
 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml +1 -0
index fe573750577e..25ed0266f6dd 100644
@@ -15,6 +15,7 @@ properties:
       - items:
           - enum:
               - elpida,ECB240ABACN
+              - elpida,B8132B2PB-6D-F
           - enum:
               - jedec,lpddr2-s4
       - items:
Signature · 1 line
2.32.0
maintainer Reviewed-by on v5 4/9
#16 lore raw

Re: [PATCH v5 4/9] dt-bindings: memory: lpddr2: Document Elpida B8132B2PB-6D-F

Quoted 10 lines · Dmitry Osipenko

Elpida B8132B2PB-6D-F memory chip is used by ASUS Transformer TF101 tablet, add compatible for it. We need to specify this compatible it for a device-tree node containing corresponding memory timings in order to allow software to match the timings with the detected hardware.

---
 .../devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml | 1 +
 1 file changed, 1 insertion(+)
#17 lore raw

PATCH v5 5/9 dt-bindings: Add vendor prefix for Elpida Memory

In reply to Dmitry Osipenko

Elpida Memory designed, manufactured and sold dynamic random-access memory (DRAM) products. It was acquired by Micron Technology in 2013, still there are many devices with components from Elpida. Document the vendor prefix.

---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0
index 1d77f151555b..8e06e3049a4f 100644
@@ -355,6 +355,8 @@ patternProperties:
     description: Shenzhen Elida Technology Co., Ltd.
   "^elimo,.*":
     description: Elimo Engineering Ltd.
+  "^elpida,.*":
+    description: Elpida Memory, Inc.
   "^embest,.*":
     description: Shenzhen Embest Technology Co., Ltd.
   "^emlid,.*":
Signature · 1 line
2.32.0
maintainer Reviewed-by on v5 5/9
#18 lore raw

Re: [PATCH v5 5/9] dt-bindings: Add vendor prefix for Elpida Memory

Quoted 10 lines · Dmitry Osipenko

Elpida Memory designed, manufactured and sold dynamic random-access memory (DRAM) products. It was acquired by Micron Technology in 2013, still there are many devices with components from Elpida. Document the vendor prefix.

---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)
#19 lore raw

PATCH v5 6/9 ARM: dts: elpida_ecb240abacn: Change Elpida compatible

In reply to Dmitry Osipenko

Vendor prefix shouldn't start with capital letter. The Elpida Memory compatible was never used in practice, hence just correct the compatible.

---
 arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/elpida_ecb240abacn.dtsi +1 -1
index d87ee4794f83..9698801cbcfb 100644
@@ -5,7 +5,7 @@
 
 / {
 	elpida_ECB240ABACN: lpddr2 {
-		compatible	= "Elpida,ECB240ABACN","jedec,lpddr2-s4";
+		compatible	= "elpida,ECB240ABACN","jedec,lpddr2-s4";
 		density		= <2048>;
 		io-width	= <32>;
 
Signature · 1 line
2.32.0
#20 lore raw

PATCH v5 7/9 dt-bindings: memory: tegra20: emc: Document new LPDDR2 sub-node

In reply to Dmitry Osipenko

Some Tegra20 boards don't have RAM code stored in NVMEM, which is used for the memory chip identification and the identity information should be read out from LPDDR2 chip in this case. Document new sub-node containing generic LPDDR2 properties that will be used for the memory chip identification if RAM code isn't available. The identification is done by reading out memory configuration values from generic LPDDR2 mode registers of SDRAM chip and comparing them with the values of device-tree 'lpddr2' sub-node.

---
 .../nvidia,tegra20-emc.yaml                   | 23 +++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml +21 -2
index cac6842dc8f1..2fa44951cfde 100644
@@ -164,12 +164,20 @@ patternProperties:
       "#size-cells":
         const: 0
 
+      lpddr2:
+        $ref: "ddr/jedec,lpddr2.yaml#"
+        type: object
+
     patternProperties:
       "^emc-table@[0-9]+$":
         $ref: "#/$defs/emc-table"
 
-    required:
-      - nvidia,ram-code
+    oneOf:
+      - required:
+          - nvidia,ram-code
+
+      - required:
+          - lpddr2
 
     additionalProperties: false
 
@@ -227,4 +235,15 @@ examples:
                         0x00000000 0x00000000 0x00000000 0x00000000>;
             };
         };
+
+        emc-tables@1 {
+            reg = <1>;
+
+            lpddr2 {
+                compatible = "elpida,B8132B2PB-6D-F", "jedec,lpddr2-s4";
+                revision-id1 = <1>;
+                density = <2048>;
+                io-width = <16>;
+            };
+        };
     };
Signature · 1 line
2.32.0
maintainer Reviewed-by on v5 7/9
#21 lore raw

Re: [PATCH v5 7/9] dt-bindings: memory: tegra20: emc: Document new LPDDR2 sub-node

Quoted 8 lines · Dmitry Osipenko

Some Tegra20 boards don't have RAM code stored in NVMEM, which is used for the memory chip identification and the identity information should be read out from LPDDR2 chip in this case. Document new sub-node containing generic LPDDR2 properties that will be used for the memory chip identification if RAM code isn't available. The identification is done by reading out memory configuration values from generic LPDDR2 mode registers of SDRAM chip and comparing them with the values of device-tree 'lpddr2' sub-node.

Quoted 5 lines
---
 .../nvidia,tegra20-emc.yaml                   | 23 +++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)
#22 lore raw

PATCH v5 8/9 memory: Add LPDDR2-info helpers

In reply to Dmitry Osipenko

Add common helpers for reading and parsing standard LPDDR2 configuration properties.

---
 drivers/memory/jedec_ddr.h      | 47 ++++++++++++++++++
 drivers/memory/jedec_ddr_data.c | 41 ++++++++++++++++
 drivers/memory/of_memory.c      | 87 +++++++++++++++++++++++++++++++++
 drivers/memory/of_memory.h      |  9 ++++
 4 files changed, 184 insertions(+)
drivers/memory/jedec_ddr.h +47 -0
index e59ccbd982d0..6cd508478b14 100644
@@ -112,6 +112,26 @@
 #define NUM_DDR_ADDR_TABLE_ENTRIES			11
 #define NUM_DDR_TIMING_TABLE_ENTRIES			4
 
+#define LPDDR2_MANID_SAMSUNG				1
+#define LPDDR2_MANID_QIMONDA				2
+#define LPDDR2_MANID_ELPIDA				3
+#define LPDDR2_MANID_ETRON				4
+#define LPDDR2_MANID_NANYA				5
+#define LPDDR2_MANID_HYNIX				6
+#define LPDDR2_MANID_MOSEL				7
+#define LPDDR2_MANID_WINBOND				8
+#define LPDDR2_MANID_ESMT				9
+#define LPDDR2_MANID_SPANSION				11
+#define LPDDR2_MANID_SST				12
+#define LPDDR2_MANID_ZMOS				13
+#define LPDDR2_MANID_INTEL				14
+#define LPDDR2_MANID_NUMONYX				254
+#define LPDDR2_MANID_MICRON				255
+
+#define LPDDR2_TYPE_S4					0
+#define LPDDR2_TYPE_S2					1
+#define LPDDR2_TYPE_NVM					2
+
 /* Structure for DDR addressing info from the JEDEC spec */
 struct lpddr2_addressing {
 	u32 num_banks;
@@ -170,6 +190,33 @@ extern const struct lpddr2_timings
 	lpddr2_jedec_timings[NUM_DDR_TIMING_TABLE_ENTRIES];
 extern const struct lpddr2_min_tck lpddr2_jedec_min_tck;
 
+/* Structure of MR8 */
+union lpddr2_basic_config4 {
+	u32 value;
+
+	struct {
+		unsigned int arch_type : 2;
+		unsigned int density : 4;
+		unsigned int io_width : 2;
+	} __packed;
+};
+
+/*
+ * Structure for information about LPDDR2 chip. All parameters are
+ * matching raw values of standard mode register bitfields or set to
+ * -ENOENT if info unavailable.
+ */
+struct lpddr2_info {
+	int arch_type;
+	int density;
+	int io_width;
+	int manufacturer_id;
+	int revision_id1;
+	int revision_id2;
+};
+
+const char *lpddr2_jedec_manufacturer(unsigned int manufacturer_id);
+
 /*
  * Structure for timings for LPDDR3 based on LPDDR2 plus additional fields.
  * All parameters are in pico seconds(ps) excluding max_freq, min_freq which
drivers/memory/jedec_ddr_data.c +41 -0

44 lines not on this page · raw message

drivers/memory/of_memory.c +87 -0

90 lines not on this page · raw message

drivers/memory/of_memory.h +9 -0
index 4a99b232ab0a..1c4e47fede8a 100644
@@ -20,6 +20,9 @@ const struct lpddr3_min_tck *of_lpddr3_get_min_tck(struct device_node *np,
 const struct lpddr3_timings *
 of_lpddr3_get_ddr_timings(struct device_node *np_ddr,
 			  struct device *dev, u32 device_type, u32 *nr_frequencies);
+
+const struct lpddr2_info *of_lpddr2_get_info(struct device_node *np,
+					     struct device *dev);
 #else
 static inline const struct lpddr2_min_tck
 	*of_get_min_tck(struct device_node *np, struct device *dev)
@@ -46,6 +49,12 @@ static inline const struct lpddr3_timings
 {
 	return NULL;
 }
+
+static inline const struct lpddr2_info
+	*of_lpddr2_get_info(struct device_node *np, struct device *dev)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF && CONFIG_DDR */
 
 #endif /* __LINUX_MEMORY_OF_REG_ */
Signature · 1 line
2.32.0
#23 lore raw

PATCH v5 9/9 memory: tegra20-emc: Support matching timings by LPDDR2 configuration

In reply to Dmitry Osipenko

ASUS Transformer TF101 doesn't provide RAM code and in this case memory timings should be selected based on identity information read out from SDRAM chip. Support matching timings by LPDDR2 configuration.

---
 drivers/memory/tegra/Kconfig       |   1 +
 drivers/memory/tegra/tegra20-emc.c | 199 +++++++++++++++++++++++++++--
 2 files changed, 186 insertions(+), 14 deletions(-)
drivers/memory/tegra/Kconfig +1 -0
index f9bae36c03a3..7951764b4efe 100644
@@ -16,6 +16,7 @@ config TEGRA20_EMC
 	depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
 	select DEVFREQ_GOV_SIMPLE_ONDEMAND
 	select PM_DEVFREQ
+	select DDR
 	help
 	  This driver is for the External Memory Controller (EMC) found on
 	  Tegra20 chips. The EMC controls the external DRAM on the board.
drivers/memory/tegra/tegra20-emc.c +185 -14

303 lines not on this page · raw message

Signature · 1 line
2.32.0
#24 lore raw
In reply to Dmitry Osipenko
Quoted 9 lines · Dmitry Osipenko

Support memory chip identification by LPDDR2 configuration, which is needed by ASUS Transformer TF101 tablet device that doesn't store RAMCODE in Tegra's NVMEM.

Changelog:

v5: - Added new patch which adds vendor prefix for Elpida Inc.

[...]

Applied, thanks!

[1/9] dt-bindings: Relocate DDR bindings
(no commit info)
[2/9] dt-bindings: memory: lpddr2: Convert to schema

      commit: 8a3294b74ac621ab03ef88cb964c13089ffdf015
[3/9] dt-bindings: memory: lpddr2: Add revision-id properties
      commit: 3c1a1b4b191978559cae5c626da012ef897c1139
[4/9] dt-bindings: memory: lpddr2: Document Elpida B8132B2PB-6D-F
      commit: 624f42157b99d253e6a52a7f93123eb0dbe1b26c
[5/9] dt-bindings: Add vendor prefix for Elpida Memory
      commit: 8712faaf12106bc70fcaef2cb89f7958faddbe59
[7/9] dt-bindings: memory: tegra20: emc: Document new LPDDR2 sub-node
      commit: ab4dd82cf5f8dd1943acf9243058262bc33c5af6
[8/9] memory: Add LPDDR2-info helpers
      commit: 5c767f684651e74f81c4d6a363e3779af3a77cc0
[9/9] memory: tegra20-emc: Support matching timings by LPDDR2 configuration
      commit: 4964b3e5c9ad4ad85b44f826a12c008af826545c

(dts patch not applied)

Best regards,

Signature · 1 line
Krzysztof Kozlowski <[email protected]>
#25 lore raw

15.10.2021 10:20, Krzysztof Kozlowski пишет:

Quoted 31 lines · Dmitry Osipenko
Quoted 9 lines

Support memory chip identification by LPDDR2 configuration, which is needed by ASUS Transformer TF101 tablet device that doesn't store RAMCODE in Tegra's NVMEM.

Changelog:

v5: - Added new patch which adds vendor prefix for Elpida Inc.

[...]

Applied, thanks!

[1/9] dt-bindings: Relocate DDR bindings
(no commit info)
[2/9] dt-bindings: memory: lpddr2: Convert to schema

      commit: 8a3294b74ac621ab03ef88cb964c13089ffdf015
[3/9] dt-bindings: memory: lpddr2: Add revision-id properties
      commit: 3c1a1b4b191978559cae5c626da012ef897c1139
[4/9] dt-bindings: memory: lpddr2: Document Elpida B8132B2PB-6D-F
      commit: 624f42157b99d253e6a52a7f93123eb0dbe1b26c
[5/9] dt-bindings: Add vendor prefix for Elpida Memory
      commit: 8712faaf12106bc70fcaef2cb89f7958faddbe59
[7/9] dt-bindings: memory: tegra20: emc: Document new LPDDR2 sub-node
      commit: ab4dd82cf5f8dd1943acf9243058262bc33c5af6
[8/9] memory: Add LPDDR2-info helpers
      commit: 5c767f684651e74f81c4d6a363e3779af3a77cc0
[9/9] memory: tegra20-emc: Support matching timings by LPDDR2 configuration
      commit: 4964b3e5c9ad4ad85b44f826a12c008af826545c
Quoted 1 line

(dts patch not applied)

I'll try to send that dts patch to OMAP people, thanks.