[PATCH v3 05/19] dt-bindings: memory: factorise LPDDR props into memory props
Julius Werner
jwerner at chromium.org
Tue Jul 22 14:57:28 PDT 2025
> 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...].
> 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"?
> 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?
More information about the linux-arm-kernel
mailing list