From: Joseph Lo <josephl@nvidia.com>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org, Stephen Boyd <sboyd@kernel.org>,
Peter De Schrijver <pdeschrijver@nvidia.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Thierry Reding <thierry.reding@gmail.com>,
linux-tegra@vger.kernel.org, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/8] dt-bindings: memory: tegra: Add Tegra210 EMC bindings
Date: Mon, 1 Apr 2019 15:57:47 +0800 [thread overview]
Message-ID: <7d680700-d2f2-7b6c-a8bf-dca6d54dbf2c@nvidia.com> (raw)
In-Reply-To: <5ca06133.1c69fb81.11ebf.91ce@mx.google.com>
On 3/31/19 2:41 PM, Rob Herring wrote:
> On Mon, Mar 25, 2019 at 03:45:16PM +0800, Joseph Lo wrote:
>> Add the binding document for the external memory controller (EMC) which
>> communicates with external LPDDR4 devices. It includes the bindings of
>> the EMC node and the EMC table of different rates.
>>
>> To support high rates for LPDDR4, the EMC table must be trained before
>> it can be used for runtime clock switching. It has been done by firmware
>> and merged to the table that Linux kernel uses. For backward
>> compatibility with the devices that had been launched on the market, like
>> Shield and Jetson platforms, the bindings in the EMC table should remain
>> the same. So the firmware can recognize them and merge the trained EMC
>> table for the kernel.
Hi Rob,
Thanks for reviewing.
>
> Overall seems pretty bloated. How much of this really varies by board
> vs. just being a dump of all the register values to stuff?
Most of them are register values. And by different SDRAM devices that
could be used on the same platform (use ram code to identify them), the
value could be different.
>
> Primarily, I'm leary of getting a similar binding for every vendor's DDR
> setup.
>
> Some mostly trivial comments follow.
Really sorry about that. I understand these basic rules for DT bindings,
but the case here is that these un-reviewed bindings have been used in
the firmware on the shipped products. To support the same with the
upstream kernel and consider the firmware blob may not be updated, we
have no choice to just use the same bindings in the upstream kernel.
How can we deal with this case?
>
snip.
>> +Example:
>> + external-memory-controller@7001b000 {
>> + compatible = "nvidia,tegra21-emc", "nvidia,tegra210-emc";
>> + reg = <0x0 0x7001b000 0x0 0x1000>,
>> + <0x0 0x7001e000 0x0 0x1000>,
>> + <0x0 0x7001f000 0x0 0x1000>;
>> + clocks = <&tegra_car TEGRA210_CLK_EMC>,
>> + <&tegra_car TEGRA210_CLK_PLL_M>,
>> + <&tegra_car TEGRA210_CLK_PLL_C>,
>> + <&tegra_car TEGRA210_CLK_PLL_P>,
>> + <&tegra_car TEGRA210_CLK_CLK_M>,
>> + <&tegra_car TEGRA210_CLK_PLL_M_UD>,
>> + <&tegra_car TEGRA210_CLK_PLL_MB_UD>,
>> + <&tegra_car TEGRA210_CLK_PLL_MB>,
>> + <&tegra_car TEGRA210_CLK_PLL_P_UD>;
>> + clock-names = "emc", "pll_m", "pll_c", "pll_p", "clk_m",
>> + "pll_m_ud", "pll_mb_ud", "pll_mb", "pll_p_ud";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + nvidia,memory-controller = <&mc>;
>> + nvidia,use-ram-code;
>> +
>> + emc-table@0 {
>
> Unit address without reg is not valid.
>
>> + nvidia,ram-code = <0>;
>> + emc-table@40800 {
>
> And here.
>
Will fix this.
Thanks,
Joseph
>> + compatible = "nvidia,tegra21-emc-table";
>> + ...
>> + };
>> + emc-table@204000 {
>> + ...
>> + };
>> + ...
>> + };
>> +
>> + emc-table@1 {
>> + nvidia,ram-code = <1>;
>> + emc-table@40800 {
>> + compatible = "nvidia,tegra21-emc-table";
>> + ...
>> + };
>> + emc-table@204000 {
>> + ...
>> + };
>> + ...
>> + };
>> + };
>> --
>> 2.21.0
>>
>
next prev parent reply other threads:[~2019-04-01 7:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 7:45 [PATCH 0/8] Add EMC scaling support for Tegra210 Joseph Lo
2019-03-25 7:45 ` [PATCH 1/8] dt-bindings: memory: tegra: Add Tegra210 EMC bindings Joseph Lo
2019-03-31 6:41 ` Rob Herring
2019-04-01 7:57 ` Joseph Lo [this message]
2019-04-03 4:26 ` Rob Herring
2019-04-10 2:41 ` Joseph Lo
2019-04-01 12:12 ` Dmitry Osipenko
2019-04-02 2:26 ` Joseph Lo
2019-04-02 10:21 ` Dmitry Osipenko
2019-04-04 9:17 ` Dmitry Osipenko
2019-04-04 9:30 ` Dmitry Osipenko
2019-04-08 8:49 ` Joseph Lo
2019-03-25 7:45 ` [PATCH 2/8] clk: tegra: clock changes for emc scaling support on Tegra210 Joseph Lo
2019-04-03 9:22 ` Thierry Reding
2019-04-08 7:52 ` Joseph Lo
2019-04-08 9:15 ` Peter De Schrijver
2019-03-25 7:45 ` [PATCH 3/8] memory: tegra: Add Tegra210 EMC clock driver Joseph Lo
2019-04-03 11:34 ` Thierry Reding
2019-04-08 9:25 ` Peter De Schrijver
2019-04-03 11:55 ` Dmitry Osipenko
2019-03-25 7:45 ` [PATCH 4/8] memory: tegra: add EMC scaling support code for Tegra210 Joseph Lo
2019-04-02 11:39 ` Dmitry Osipenko
2019-04-02 14:53 ` Joseph Lo
2019-03-25 7:45 ` [PATCH 5/8] memory: tegra: Add EMC scaling sequence " Joseph Lo
2019-04-02 11:36 ` Dmitry Osipenko
2019-04-02 14:49 ` Joseph Lo
2019-03-25 7:45 ` [PATCH 6/8] arm64: tegra: Add external memory controller node " Joseph Lo
2019-03-29 14:41 ` [PATCH 0/8] Add EMC scaling support " Peter De Schrijver
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=7d680700-d2f2-7b6c-a8bf-dca6d54dbf2c@nvidia.com \
--to=josephl@nvidia.com \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=pdeschrijver@nvidia.com \
--cc=robh@kernel.org \
--cc=sboyd@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).