From: "Clément Le Goffic" <legoffic.clement@gmail.com>
To: "Julius Werner" <jwerner@chromium.org>,
"Clément Le Goffic" <clement.legoffic@foss.st.com>
Cc: Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Jonathan Corbet <corbet@lwn.net>,
Gatien Chevallier <gatien.chevallier@foss.st.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Gabriel Fernandez <gabriel.fernandez@foss.st.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-clk@vger.kernel.org
Subject: Re: [PATCH v5 05/20] dt-bindings: memory: factorise LPDDR props into SDRAM props
Date: Thu, 14 Aug 2025 16:06:42 +0200 [thread overview]
Message-ID: <4055d2c4-64c7-498f-8cdb-8d749d32ec68@gmail.com> (raw)
In-Reply-To: <CAODwPW-FjCtPGYkNYozo0ybEjz_rVOeDqkvEPiCmQ6M2in0OeQ@mail.gmail.com>
Hi Julius,
On 30/07/2025 20:27, Julius Werner wrote:
>> + Compatible strings can be either explicit vendor names and part numbers
>> + (e.g. elpida,ECB240ABACN), or generated strings of the form
>> + lpddrX,YY,ZZZZ or ddrX-YYYY,AAAA...,ZZZZ where X, Y, A and Z are in lower
>
> If the revision ID is only one byte for DDR, there should be only two Zs.
Indeed, will fix it here and in the dedicated field documentation below.
Wouldn't it be better to add a regex pattern for the compatible ?
>
>> + case hexadecimal with leading zeroes.
>
> AAAA is not hexadecimal, it's a verbatim ASCII string (at least that's
> how I would define it, for readability).
Yes you're right. I'll add the numbers of chars it corresponds to in the
dedicated field below also.
>
>> + For LPDDR and DDR SDRAM, X is the SDRAM version (2, 3, 4, etc.).
>> + For LPDDR SDRAM:
>> + - YY is the manufacturer ID (from MR5), 1 byte
>> + - ZZZZ is the revision ID (from MR6 and MR7), 2 bytes
>> + For DDR4 SDRAM with SPD, according to JEDEC SPD4.1.2.L-6 :
>> + - YYYY is the manufacturer ID, 2 bytes, from bytes 320 and 321
>> + - AAAA... is the part number, 20 bytes, from bytes 329 to 348
>
> This should clarify that it is excluding trailing spaces (so only the
> significant part of those 20 bytes, since they're supposed to be
> padded with spaces at the end).
I'll add a comment about that.
>
>> + - Z is the revision ID, 1 byte, from byte 349
>> + The former form is useful when the SDRAM vendor and part number are
>> + known, such as when the SDRAM is soldered on the board.
>
> This inversion of the statement is a bit odd? I think it's more
> important to explain why we need the latter form (or just explain
> both).
I will document both forms so.
>
>> + SDRAM revision ID:
>> + - LPDDR SDRAM, decoded from Mode Register 6 and 7, always 2 bytes.
>> + - DDR4 SDRAM, decoded from the SPD from byte 349 according to
>> + JEDEC SPD4.1.2.L-6.
>
> nit: Add "always one byte" for clarity and consistency with the LPDDR
> equivalent.
Ack
next prev parent reply other threads:[~2025-08-14 14:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 15:29 [PATCH v5 00/20] Introduce STM32 DDR PMU for STM32MP platforms Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 01/20] bus: firewall: move stm32_firewall header file in include folder Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 02/20] dt-bindings: stm32: stm32mp25: add `#access-controller-cells` property Clément Le Goffic
2025-07-31 13:50 ` Rob Herring (Arm)
2025-07-28 15:29 ` [PATCH v5 03/20] clk: stm32mp25: add firewall grant_access ops Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 04/20] arm64: dts: st: set rcc as an access-controller Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 05/20] dt-bindings: memory: factorise LPDDR props into SDRAM props Clément Le Goffic
2025-07-30 18:27 ` Julius Werner
2025-08-14 14:06 ` Clément Le Goffic [this message]
2025-07-28 15:29 ` [PATCH v5 06/20] dt-bindings: memory: introduce DDR4 Clément Le Goffic
2025-07-30 18:29 ` Julius Werner
2025-08-14 14:40 ` Clément Le Goffic
2025-07-30 21:11 ` Rob Herring
2025-08-14 14:42 ` Clément Le Goffic
2025-08-17 7:19 ` Krzysztof Kozlowski
2025-08-22 13:59 ` Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 07/20] dt-bindings: memory: factorise LPDDR channel binding into SDRAM channel Clément Le Goffic
2025-07-31 13:52 ` Rob Herring (Arm)
2025-07-28 15:29 ` [PATCH v5 08/20] dt-binding: memory: add DDR4 channel compatible Clément Le Goffic
2025-07-31 13:52 ` Rob Herring (Arm)
2025-07-28 15:29 ` [PATCH v5 09/20] dt-bindings: memory: SDRAM channel: standardise node name Clément Le Goffic
2025-07-31 13:53 ` Rob Herring (Arm)
2025-07-28 15:29 ` [PATCH v5 10/20] arm64: dts: st: add LPDDR channel to stm32mp257f-dk board Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 11/20] arm64: dts: st: add DDR channel to stm32mp257f-ev1 board Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 12/20] dt-bindings: perf: stm32: introduce DDRPERFM dt-bindings Clément Le Goffic
2025-07-31 13:54 ` Rob Herring
2025-07-28 15:29 ` [PATCH v5 13/20] perf: stm32: introduce DDRPERFM driver Clément Le Goffic
2025-07-30 14:43 ` kernel test robot
2025-07-28 15:29 ` [PATCH v5 14/20] Documentation: perf: stm32: add ddrperfm support Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 15/20] MAINTAINERS: add myself as STM32 DDR PMU maintainer Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 16/20] ARM: dts: stm32: add ddrperfm on stm32mp131 Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 17/20] ARM: dts: stm32: add ddrperfm on stm32mp151 Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 18/20] arm64: dts: st: add ddrperfm on stm32mp251 Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 19/20] arm64: dts: st: support ddrperfm on stm32mp257f-dk Clément Le Goffic
2025-07-28 15:29 ` [PATCH v5 20/20] arm64: dts: st: support ddrperfm on stm32mp257f-ev1 Clément Le Goffic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4055d2c4-64c7-498f-8cdb-8d749d32ec68@gmail.com \
--to=legoffic.clement@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=clement.legoffic@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=gabriel.fernandez@foss.st.com \
--cc=gatien.chevallier@foss.st.com \
--cc=jwerner@chromium.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mark.rutland@arm.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).