From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Dmitry Osipenko <digetx@gmail.com>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH v1 1/2] dt-bindings: memory: tegra20: emc: Document optional LPDDR properties
Date: Thu, 30 Sep 2021 08:54:21 +0200 [thread overview]
Message-ID: <2df06f23-1a5e-f6e9-8e2c-0bb4c93fe23c@canonical.com> (raw)
In-Reply-To: <20210929200305.4245-2-digetx@gmail.com>
On 29/09/2021 22:03, Dmitry Osipenko wrote:
> Some Tegra20 boards don't use RAM code for the memory chip identification
> and the identity information should read out from LPDDR chip in this case.
> Document new optional generic LPDDR properties that will be used for the
> memory chip identification if RAM code isn't provided.
Please mention how they are going to be used. Naively I would assume
that these new properties describe the RAM you have. However it seems
you do not use them to configure the device but to compare with the
device. Why do you need them?
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
> .../nvidia,tegra20-emc.yaml | 43 +++++++++++++++++--
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
> index cac6842dc8f1..6d01b1bf6304 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
> @@ -158,6 +158,46 @@ patternProperties:
> description:
> Value of RAM_CODE this timing set is used for.
>
> + jedec,lpddr-manufacturer-id:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Unique manufacturer ID of SDRAM chip this timing set is used for.
> + See MR5 description in JEDEC LPDDR2 specification (JESD209-2).
> +
> + jedec,lpddr-revision-id1:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Revision 1 value of SDRAM chip this timing set is used for.
> + See MR6 description in chip vendor specification.
> +
> + jedec,lpddr-revision-id2:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Revision 2 value of SDRAM chip this timing set is used for.
> + See MR7 description in chip vendor specification.
> +
> + jedec,lpddr-density-mbits:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Density in megabits of SDRAM chip this timing set is used for.
> + See MR8 description in JEDEC LPDDR2 specification.
> +
> + jedec,lpddr-io-width-bits:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + IO bus width in bits of SDRAM chip this timing set is used for.
> + See MR8 description in JEDEC LPDDR2 specification.
> +
> + jedec,lpddr-type:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + LPDDR type which corresponds to a number of words SDRAM pre-fetches
> + per column request that this timing set is used for.
> + See MR8 description in JEDEC LPDDR2 specification.
> + enum:
> + - 4 # S4 (4 words prefetch architecture)
> + - 2 # S2 (2 words prefetch architecture)
I think instead you should use generic lpddr{2,3} bindings - have a
separate node and reference it via a phandle.
Best regards,
Krzysztof
next prev parent reply other threads:[~2021-09-30 6:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-29 20:03 [PATCH v1 0/2] tegra20-emc: Identify memory chip by LPDDR configuration Dmitry Osipenko
2021-09-29 20:03 ` [PATCH v1 1/2] dt-bindings: memory: tegra20: emc: Document optional LPDDR properties Dmitry Osipenko
2021-09-30 6:54 ` Krzysztof Kozlowski [this message]
2021-09-30 14:55 ` Dmitry Osipenko
2021-09-29 20:03 ` [PATCH v1 2/2] memory: tegra20-emc: Support timings matching by LPDDR configuration Dmitry Osipenko
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=2df06f23-1a5e-f6e9-8e2c-0bb4c93fe23c@canonical.com \
--to=krzysztof.kozlowski@canonical.com \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.com \
/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).