LPDDR and DDR channels exist and share the same properties, they have a
compatible, ranks, and an io-width.
Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
...pddr-channel.yaml => jedec,memory-channel.yaml} | 26 +++++++++++-----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
similarity index 82%
rename from Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
rename to Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
index 34b5bd153f63..3bf3a63466eb 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
@@ -1,16 +1,16 @@
# 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#
+$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,memory-channel.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: LPDDR channel with chip/rank topology description
+title: Memory 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.
+ A memory channel is a completely independent set of pins (DQ, CA, CS,
+ CK, etc.) that connect one or more memory chips to a host system. The main
+ purpose of this node is to overall memory topology of the system, including the
+ amount of individual memory chips and the ranks per chip.
maintainers:
- Julius Werner <jwerner@chromium.org>
@@ -26,14 +26,14 @@ properties:
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
+ from (a multiple of) the io-width of the memory 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.
+ connected memory chip, times the io-width of the channel divided by
+ the io-width of the memory chip.
enum:
- 8
- 16
@@ -51,8 +51,8 @@ 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
+ Each physical memory chip may have one or more ranks. Ranks are
+ internal but fully independent sub-units of the chip. Each memory 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.
@@ -107,7 +107,7 @@ additionalProperties: false
examples:
- |
- lpddr-channel0 {
+ memory-channel0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "jedec,lpddr3-channel";
@@ -122,7 +122,7 @@ examples:
};
};
- lpddr-channel1 {
+ memory-channel1 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "jedec,lpddr4-channel";
--
2.43.0
On Tue, Jul 22, 2025 at 04:03:24PM +0200, Clément Le Goffic wrote:
> LPDDR and DDR channels exist and share the same properties, they have a
> compatible, ranks, and an io-width.
Maybe it is true for all types of SDRAM, like RDRAM and eDRAM, but I
don't think all memory types do.
I think this should be renamed to sdram-channel.
>
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
> ---
> ...pddr-channel.yaml => jedec,memory-channel.yaml} | 26 +++++++++++-----------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
> similarity index 82%
> rename from Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
> rename to Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
> index 34b5bd153f63..3bf3a63466eb 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
> @@ -1,16 +1,16 @@
> # 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#
> +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,memory-channel.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: LPDDR channel with chip/rank topology description
> +title: Memory 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.
> + A memory channel is a completely independent set of pins (DQ, CA, CS,
A memory channel of SDRAM memory like DDR SDRAM or LPDDR SDRAM is ...
> + CK, etc.) that connect one or more memory chips to a host system. The main
> + purpose of this node is to overall memory topology of the system, including the
> + amount of individual memory chips and the ranks per chip.
>
> maintainers:
> - Julius Werner <jwerner@chromium.org>
> @@ -26,14 +26,14 @@ properties:
> 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
> + from (a multiple of) the io-width of the memory 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.
> + connected memory chip, times the io-width of the channel divided by
> + the io-width of the memory chip.
> enum:
> - 8
> - 16
> @@ -51,8 +51,8 @@ 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
> + Each physical memory chip may have one or more ranks. Ranks are
> + internal but fully independent sub-units of the chip. Each memory 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.
> @@ -107,7 +107,7 @@ additionalProperties: false
>
> examples:
> - |
> - lpddr-channel0 {
> + memory-channel0 {
If doing this, then separate commit based on generic node name
convention. But then we need to come with generic node name first,
sdram-channel?
And also '-0', not '0' suffix.
Best regards,
Krzysztof
Hi Krzysztof,
On 7/23/25 08:57, Krzysztof Kozlowski wrote:
> On Tue, Jul 22, 2025 at 04:03:24PM +0200, Clément Le Goffic wrote:
>> LPDDR and DDR channels exist and share the same properties, they have a
>> compatible, ranks, and an io-width.
>
> Maybe it is true for all types of SDRAM, like RDRAM and eDRAM, but I
> don't think all memory types do.
>
> I think this should be renamed to sdram-channel.
Ok, do you want me to also the memory-props patch into sdram-props ?
>
>>
>> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
>> ---
>> ...pddr-channel.yaml => jedec,memory-channel.yaml} | 26 +++++++++++-----------
>> 1 file changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
>> similarity index 82%
>> rename from Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
>> rename to Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
>> index 34b5bd153f63..3bf3a63466eb 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
>> +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-channel.yaml
>> @@ -1,16 +1,16 @@
>> # 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#
>> +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,memory-channel.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: LPDDR channel with chip/rank topology description
>> +title: Memory 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.
>> + A memory channel is a completely independent set of pins (DQ, CA, CS,
>
> A memory channel of SDRAM memory like DDR SDRAM or LPDDR SDRAM is ...
Ack
>
>> + CK, etc.) that connect one or more memory chips to a host system. The main
>> + purpose of this node is to overall memory topology of the system, including the
>> + amount of individual memory chips and the ranks per chip.
>>
>> maintainers:
>> - Julius Werner <jwerner@chromium.org>
>> @@ -26,14 +26,14 @@ properties:
>> 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
>> + from (a multiple of) the io-width of the memory 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.
>> + connected memory chip, times the io-width of the channel divided by
>> + the io-width of the memory chip.
>> enum:
>> - 8
>> - 16
>> @@ -51,8 +51,8 @@ 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
>> + Each physical memory chip may have one or more ranks. Ranks are
>> + internal but fully independent sub-units of the chip. Each memory 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.
>> @@ -107,7 +107,7 @@ additionalProperties: false
>>
>> examples:
>> - |
>> - lpddr-channel0 {
>> + memory-channel0 {
>
> If doing this, then separate commit based on generic node name
> convention. But then we need to come with generic node name first,
> sdram-channel?
I don't want anything specific so yes it could be cool to have a generic
node name.
"sdram-channel" is fine for me.
@Julius what do you think about it ?
Is your existing software generating it in the kernel ?
I'm curious about dynamic node name generation.
>
> And also '-0', not '0' suffix.
Ack
> Best regards,
> Krzysztof
>
> I don't want anything specific so yes it could be cool to have a generic > node name. > "sdram-channel" is fine for me. > @Julius what do you think about it ? > Is your existing software generating it in the kernel ? > I'm curious about dynamic node name generation. I'm fine with whatever for the example here as long as the kernel does not rely on any specific format. `sdram-channel-X` seems fine. On our platforms we generate these dynamically in the bootloader based on what we enumerated during memory training, so there's no kernel code for it. If you're curious, our bootloader code generating it is here: https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/main/src/boot/memchipinfo.c#25 (We can update this if there's kernel consensus on a new format, but we'll still have older platforms that keep running the old implementation and we also want those to remain compatible with newer versions of Linux.)
On 23/07/2025 10:10, Clement LE GOFFIC wrote: > Hi Krzysztof, > > On 7/23/25 08:57, Krzysztof Kozlowski wrote: >> On Tue, Jul 22, 2025 at 04:03:24PM +0200, Clément Le Goffic wrote: >>> LPDDR and DDR channels exist and share the same properties, they have a >>> compatible, ranks, and an io-width. >> >> Maybe it is true for all types of SDRAM, like RDRAM and eDRAM, but I >> don't think all memory types do. >> >> I think this should be renamed to sdram-channel. > > Ok, do you want me to also the memory-props patch into sdram-props ? Yes. Best regards, Krzysztof
On 23/07/2025 08:57, Krzysztof Kozlowski wrote: > On Tue, Jul 22, 2025 at 04:03:24PM +0200, Clément Le Goffic wrote: >> LPDDR and DDR channels exist and share the same properties, they have a >> compatible, ranks, and an io-width. > > Maybe it is true for all types of SDRAM, like RDRAM and eDRAM, but I Although these were not JEDEC probably... > don't think all memory types do. > > I think this should be renamed to sdram-channel. ... yet still JEDEC also has some standards for SRAM, EPROM, HBM and SGRAM (graphics), see: https://www.jedec.org/category/technology-focus-area/memory-configurations-jesd21-c Best regards, Krzysztof
Hi, On 7/23/25 09:06, Krzysztof Kozlowski wrote: > On 23/07/2025 08:57, Krzysztof Kozlowski wrote: >> On Tue, Jul 22, 2025 at 04:03:24PM +0200, Clément Le Goffic wrote: >>> LPDDR and DDR channels exist and share the same properties, they have a >>> compatible, ranks, and an io-width. >> >> Maybe it is true for all types of SDRAM, like RDRAM and eDRAM, but I > > > Although these were not JEDEC probably... Hmm so no "sdram-channel" ? I don't get your point here. > >> don't think all memory types do. >> >> I think this should be renamed to sdram-channel. > ... yet still JEDEC also has some standards for SRAM, EPROM, HBM and > SGRAM (graphics), see: > https://www.jedec.org/category/technology-focus-area/memory-configurations-jesd21-c In a more generic point of view we can think compatible, density and io- width as common for all sort of memory no ? > > Best regards, > Krzysztof
> + purpose of this node is to overall memory topology of the system, including the
nit: Might take the opportunity to fix the typo here (missing words:
"is to describe the overall memory topology").
> - Julius Werner <jwerner@chromium.org>
Why remove me? (Although I'm also not really sure why I'm maintainer
for this file and Krzysztof for all the others, tbh.)
> examples:
> - |
I think that's a load-bearing pipe character you're removing here?
> - lpddr-channel0 {
> + memory-channel0 {
Just to double-check, the name of this node doesn't really mean
anything and isn't directly interpreted by the kernel, right? I'm fine
with changing the example here to fit better with the new expanded
scope of the schema, but we have existing firmware that generates
nodes with the `lpddr-channel0` name, I want to make sure that it
won't break from making changes here.
On 7/22/25 23:58, Julius Werner wrote:
>> + purpose of this node is to overall memory topology of the system, including the
>
> nit: Might take the opportunity to fix the typo here (missing words:
> "is to describe the overall memory topology").
Yes true.
>
>> - Julius Werner <jwerner@chromium.org>
>
> Why remove me? (Although I'm also not really sure why I'm maintainer
> for this file and Krzysztof for all the others, tbh.)
I didn't remove you. It is just the minus of the maintainer list :-)
>
>> examples:
>> - |
>
> I think that's a load-bearing pipe character you're removing here?
Didn't remove either. There are spaces before so it it is not the git
minus char.
>
>> - lpddr-channel0 {
>> + memory-channel0 {
>
> Just to double-check, the name of this node doesn't really mean
> anything and isn't directly interpreted by the kernel, right? I'm fine
> with changing the example here to fit better with the new expanded
> scope of the schema, but we have existing firmware that generates
> nodes with the `lpddr-channel0` name, I want to make sure that it
> won't break from making changes here.
Oh ok didn't know about that and didn't find it though.
For now no pattern has been defined for the node name so it shouldn't
break anything.
Best regards,
Clément
© 2016 - 2025 Red Hat, Inc.