linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Clement LE GOFFIC <clement.legoffic@foss.st.com>
To: Julius Werner <jwerner@chromium.org>
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>,
	Le Goffic <legoffic.clement@gmail.com>,
	<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 v3 05/19] dt-bindings: memory: factorise LPDDR props into memory props
Date: Wed, 23 Jul 2025 09:21:48 +0200	[thread overview]
Message-ID: <822bd852-2cbc-4a89-a077-d05a8327e149@foss.st.com> (raw)
In-Reply-To: <CAODwPW_fDPY78bmwvLmLkt1yWpVdG=VC8h2NSdWtoiEknajhNw@mail.gmail.com>

Hi Julius,

Thanks for the review.

On 7/22/25 23:57, 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 where X is the LPDDR version, YY is the manufacturer ID
> 
> When you say "in case of LPDDR" below, you should also change this
> line to take other cases into account. Maybe the best way to write
> this would be something like:
> 
> ...or generated strings of a memory type dependent form. For LPDDR
> types, that form is lpddrX-YY,ZZZZ where X is [...same text...]. For
> DDR types, that form is ddrX-YY,ZZZZZ... where X is [...new definition
> for DDR types, based on what's available in SPD...].

Yes I agree and if there is no SPD I'll mention the datasheet of the 
memory chip.

> 
>>     revision-id:
>>       $ref: /schemas/types.yaml#/definitions/uint32-array
>>       description:
>> -      Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>).
>> +      Revision IDs read from Mode Register 6 and 7 in case of LPDDR.
>> +      One byte per uint32 cell (i.e. <MR6 MR7>).
> 
> If this doesn't exist for DDR, then rather than "in case of LPDDR"
> this should probably say something like "LPDDR only"?

It exists in case of DDR, but it is either in the SPD if the memory is 
DIMM like or in the datasheet for soldered memory chip.

> 
>>     density:
>>       $ref: /schemas/types.yaml#/definitions/uint32
>>       description:
>> -      Density in megabits of SDRAM chip. Decoded from Mode Register 8.
>> +      Density in megabits of SDRAM chip. Decoded from Mode Register 8 in case of
>> +      LPDDR.
> 
> Can you list here where in SPD density and I/O width are stored for
> the various DDR types?

I'll try to find the info and yes.

Best regards,
Clément


  reply	other threads:[~2025-07-23  7:28 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-22 14:03 [PATCH v3 00/19] Introduce STM32 DDR PMU for STM32MP platforms Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 01/19] bus: firewall: move stm32_firewall header file in include folder Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 02/19] dt-bindings: stm32: stm32mp25: add `access-controller-cell` property Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 03/19] clk: stm32mp25: add firewall grant_access ops Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 04/19] arm64: dts: st: set rcc as an access-controller Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 05/19] dt-bindings: memory: factorise LPDDR props into memory props Clément Le Goffic
2025-07-22 21:57   ` Julius Werner
2025-07-23  7:21     ` Clement LE GOFFIC [this message]
2025-07-22 14:03 ` [PATCH v3 06/19] dt-bindings: memory: introduce DDR4 Clément Le Goffic
2025-07-22 21:57   ` Julius Werner
2025-07-23  7:30     ` Clement LE GOFFIC
2025-07-22 14:03 ` [PATCH v3 07/19] dt-bindings: memory: factorise LPDDR channel binding into memory channel Clément Le Goffic
2025-07-22 21:58   ` Julius Werner
2025-07-23  7:54     ` Clement LE GOFFIC
2025-07-23  6:57   ` Krzysztof Kozlowski
2025-07-23  7:06     ` Krzysztof Kozlowski
2025-07-23  8:14       ` Clement LE GOFFIC
2025-07-23  8:10     ` Clement LE GOFFIC
2025-07-23  8:18       ` Krzysztof Kozlowski
2025-07-23 21:16       ` Julius Werner
2025-07-22 14:03 ` [PATCH v3 08/19] dt-binding: memory: add DDR4 channel compatible Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 09/19] arm64: dts: st: add LPDDR channel to stm32mp257f-dk board Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 10/19] arm64: dts: st: add DDR channel to stm32mp257f-ev1 board Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 11/19] dt-bindings: perf: stm32: introduce DDRPERFM dt-bindings Clément Le Goffic
2025-07-22 17:01   ` Rob Herring (Arm)
2025-07-22 14:03 ` [PATCH v3 12/19] perf: stm32: introduce DDRPERFM driver Clément Le Goffic
2025-07-25 10:56   ` Jonathan Cameron
2025-07-25 10:59     ` Jonathan Cameron
2025-07-28 13:12       ` Clement LE GOFFIC
2025-07-28 13:12     ` Clement LE GOFFIC
2025-07-22 14:03 ` [PATCH v3 13/19] Documentation: perf: stm32: add ddrperfm support Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 14/19] MAINTAINERS: add myself as STM32 DDR PMU maintainer Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 15/19] ARM: dts: stm32: add ddrperfm on stm32mp131 Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 16/19] ARM: dts: stm32: add ddrperfm on stm32mp151 Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 17/19] arm64: dts: st: add ddrperfm on stm32mp251 Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 18/19] arm64: dts: st: support ddrperfm on stm32mp257f-dk Clément Le Goffic
2025-07-22 14:03 ` [PATCH v3 19/19] 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=822bd852-2cbc-4a89-a077-d05a8327e149@foss.st.com \
    --to=clement.legoffic@foss.st.com \
    --cc=alexandre.torgue@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=legoffic.clement@gmail.com \
    --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).