Message ID | 20220831013359.1807905-1-jwerner@chromium.org |
---|---|
Headers | show |
Series | dt-bindings: memory: Describing LPDDR topology | expand |
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
> 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.