From: Peter De Schrijver <pdeschrijver@nvidia.com>
To: Rob Herring <robh@kernel.org>
Cc: <vkuruturi@nvidia.com>, <linux-clk@vger.kernel.org>,
<linux-tegra@vger.kernel.org>, <thierry.reding@gmail.com>,
<jonathanh@nvidia.com>, <devicetree@vger.kernel.org>,
<daniel@octaforge.org>, <a.heider@gmail.com>, <swtcr0@gmail.com>
Subject: Re: [RFC 14/14] dt-bindings: tegra: Add Tegra210 EMC binding
Date: Tue, 25 Sep 2018 16:03:29 +0300 [thread overview]
Message-ID: <20180925130329.GK7636@tbergstrom-lnx.Nvidia.com> (raw)
In-Reply-To: <5baa1ae9.1c69fb81.1ab9.1805@mx.google.com>
On Mon, Sep 24, 2018 at 02:04:24PM -0700, Rob Herring wrote:
> On Fri, Sep 14, 2018 at 11:03:09PM +0300, Peter De Schrijver wrote:
> > Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>
> Needs a commit msg.
>
> > ---
> > .../memory-controllers/nvidia,tegra210-emc.txt | 448 +++++++++++++++++++++
> > 1 file changed, 448 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.txt
> > new file mode 100644
> > index 0000000..1c52f47
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.txt
> > @@ -0,0 +1,448 @@
> > +NVIDIA Tegra210 SoC EMC (external memory controller)
> > +====================================================
> > +
> > +Required properties :
> > +- compatible : Should be "nvidia,tegra21-emc", "nvidia,tegra124-emc".
> > +- reg : physical base address and length of the controller's registers.
> > +- nvidia,memory-controller : phandle of the MC driver.
>
> Huh? What is this block then?
>
> > +- clocks : phandles of the possible source clocks
> > +- clock-names : names of the possible source clocks
> > +
> > +The node should contain a "emc-table" subnode for each supported RAM type
> > +(see field RAM_CODE in register PMC_STRAPPING_OPT_A), with its unit address
> > +being its RAM_CODE.
>
> Unit address is based on reg property.
>
> > +
> > +Required properties for "emc-table" nodes :
> > +- nvidia,ram-code : Should contain the value of RAM_CODE this timing set is
> > +used for.
> > +
> > +Each "emc-table" node should contain a "emc-table" subnode for every supported
> > +EMC clock rate. The "emc-table" subnodes should have the clock rate in kHz as
> > +their unit address.
> > +
> > +Required properties for "emc-table" nodes :
>
> Which emc-table nodes, the child or grand-child nodes?
>
> > +- compatible "nvidia,tegra21-emc-table", "nvidia,tegra210-emc-table"
>
> > +- nvidia,revision : revision of the parameter set used for this node. All
> > + nodes in the same "emc-table" should have the same revision
> > +- clock-frequency : frequency in kHz
> > +- nvidia,emc-min-mv : minimum voltage for this OPP
> > +- nvidia,gk20a-min-mv : minimum GPU voltage for this OPP
> > +- nvidia,source : clock source to be used for this OPP
>
> Is this memory timings/settings or OPPs? We have a binding for OPPs
> already.
>
> > +- nvidia,src-sel-reg : value of EMC CAR register to be used for this OPP
> > +- nvidia,needs-training : 1 if the OPP needs training at boot, 0 otherwise
> > +- nvidia,trained : 1 if initial training has been done by firmware, 0 otherwise
> > +- nvidia,periodic_training : 1 if the OPP needs periodic training, 0 otherwise
> > +- nvidia,trained_dram_clktree_c0d0u0 : training data word
> > +- nvidia,trained_dram_clktree_c0d0u1 : training data word
>
> [...]
>
> This is a huge list of properties. For all the things that are memory
> timings, is there really value to defining a property for each setting?
> Perhaps you should just define your own format and either make it a
> separate firmware file or include that file in the dtb.
>
The problem with moving to a binary blob is that it will break compatibility
with existing devices (eg. Jetson TX1 and shield TV) because their bootloaders
rely on the existing format.
Peter.
next prev parent reply other threads:[~2018-09-25 19:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1536955389-30442-1-git-send-email-pdeschrijver@nvidia.com>
[not found] ` <1536955389-30442-15-git-send-email-pdeschrijver@nvidia.com>
[not found] ` <5baa1ae9.1c69fb81.1ab9.1805@mx.google.com>
[not found] ` <20180925121107.GJ7636@tbergstrom-lnx.Nvidia.com>
2018-09-25 12:51 ` [RFC 14/14] dt-bindings: tegra: Add Tegra210 EMC binding Peter De Schrijver
2018-09-25 14:37 ` Rob Herring
2018-09-26 8:14 ` Peter De Schrijver
2018-09-25 13:03 ` Peter De Schrijver [this message]
2018-09-25 14:45 ` Rob Herring
2018-09-14 21:48 [RFC 00/14] Tegra210 EMC scaling Peter De Schrijver
2018-09-14 21:48 ` [RFC 14/14] dt-bindings: tegra: Add Tegra210 EMC binding 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=20180925130329.GK7636@tbergstrom-lnx.Nvidia.com \
--to=pdeschrijver@nvidia.com \
--cc=a.heider@gmail.com \
--cc=daniel@octaforge.org \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh@kernel.org \
--cc=swtcr0@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=vkuruturi@nvidia.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