mbox series

[0/4] dt-bindings: memory: Describing LPDDR topology

Message ID 20220831013359.1807905-1-jwerner@chromium.org
Headers show
Series dt-bindings: memory: Describing LPDDR topology | expand

Message

Julius Werner Aug. 31, 2022, 1:33 a.m. UTC 
This patch series implements a proposal previously discussed on the
mailing list under the topic `[RFC] Correct memory layout reporting for
"jedec,lpddr2" and related bindings`. It adds a new jedec,lpddr-channel
binding which should be used to group nodes of the existing jedec,lpddr
bindings to describe their relative topology on the system and the
amount of chips wired in parallel on each channel, as well as their
different ranks. This also adds bindings for LPDDR4 and LPDDR5 memory
types and deduplicates some common schema elements between different
LPDDR types.

Julius Werner (4):
  dt-bindings: memory: Factor out common properties of LPDDR bindings
  dt-bindings: memory: Add numeric LPDDR compatible string variant
  dt-bindings: memory: Add jedec,lpddr4 and jedec,lpddr5 bindings
  dt-bindings: memory: Add jedec,lpddrX-channel binding

 .../ddr/jedec,lpddr-channel.yaml              | 116 ++++++++++++++++++
 .../ddr/jedec,lpddr-props.yaml                |  82 +++++++++++++
 .../memory-controllers/ddr/jedec,lpddr2.yaml  |  48 ++------
 .../memory-controllers/ddr/jedec,lpddr3.yaml  |  51 ++------
 .../memory-controllers/ddr/jedec,lpddr4.yaml  |  36 ++++++
 .../memory-controllers/ddr/jedec,lpddr5.yaml  |  48 ++++++++
 6 files changed, 303 insertions(+), 78 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml

Comments

Krzysztof Kozlowski Aug. 31, 2022, 6:34 a.m. UTC | #1 
On 31/08/2022 04:33, Julius Werner wrote:
> This patch series implements a proposal previously discussed on the
> mailing list under the topic `[RFC] Correct memory layout reporting for
> "jedec,lpddr2" and related bindings`. It adds a new jedec,lpddr-channel
> binding which should be used to group nodes of the existing jedec,lpddr
> bindings to describe their relative topology on the system and the
> amount of chips wired in parallel on each channel, as well as their
> different ranks. This also adds bindings for LPDDR4 and LPDDR5 memory
> types and deduplicates some common schema elements between different
> LPDDR types.
> 
> Julius Werner (4):
>   dt-bindings: memory: Factor out common properties of LPDDR bindings
>   dt-bindings: memory: Add numeric LPDDR compatible string variant
>   dt-bindings: memory: Add jedec,lpddr4 and jedec,lpddr5 bindings
>   dt-bindings: memory: Add jedec,lpddrX-channel binding

Thanks for the patches. Where are the users of these bindings? Although
bindings do not have requirement of providing user (as kernel API has),
but this is quite a rework so I want to see that it is applicable. That
it matches real use case and need. I can do it only with real DTS in the
kernel.

Best regards,
Krzysztof
Julius Werner Sept. 1, 2022, 1:05 a.m. UTC | #2 
> Thanks for the patches. Where are the users of these bindings? Although
> bindings do not have requirement of providing user (as kernel API has),
> but this is quite a rework so I want to see that it is applicable. That
> it matches real use case and need. I can do it only with real DTS in the
> kernel.

Well, the whole point of the new compatible string format is that it
can be generated by boot firmware at runtime, so I don't have a static
DTS with this that I can check into the kernel tree. The first user of
these bindings will be the
arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts board that's
already in the tree, but since these nodes get generated you won't see
them in that file. It's kinda like /chosen/kaslr-seed, that's also a
valid binding with a schema description that's actively being used but
doesn't show up in any DTS file checked into the tree.