From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/8] of: Add Tegra124 EMC bindings
Date: Tue, 22 Jul 2014 10:45:08 -0600 [thread overview]
Message-ID: <53CE9514.1050903@wwwdotorg.org> (raw)
In-Reply-To: <CAL1qeaHtGQxCO3cGdeCRUYuk6mxei6z1B63-iZdBECEbFqGhHw@mail.gmail.com>
On 07/21/2014 04:52 PM, Andrew Bresticker wrote:
> On Mon, Jul 21, 2014 at 2:28 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/11/2014 10:43 AM, Andrew Bresticker wrote:
>>> On Fri, Jul 11, 2014 at 7:18 AM, Mikko Perttunen <mperttunen@nvidia.com> wrote:
>>>> Add binding documentation for the nvidia,tegra124-emc device tree
>>>> node.
>>>
>>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt
>>>
>>>> +Required properties :
>>>> +- compatible : "nvidia,tegra124-emc".
>>>> +- reg : Should contain 1 or 2 entries:
>>>> + - EMC register set
>>>> + - MC register set : Required only if no node with
>>>> + 'compatible = "nvidia,tegra124-mc"' exists. The MC register set
>>>> + is first read from the MC node. If it doesn't exist, it is read
>>>> + from this property.
>>>> +- timings : Should contain 1 entry for each supported clock rate.
>>>> + Entries should be named "timing at n" where n is a 0-based increasing
>>>> + number. The timings must be listed in rate-ascending order.
>>>
>>> There are upcoming boards which support multiple DRAM configurations
>>> and require a separate set of timings for each configuration. Could
>>> we instead have multiple sets of timings with the proper one selected
>>> at runtime by RAM code, as reported by PMC_STRAPPING_OPT_A_0?
>>> Something like:
>>>
>>> emc {
>>> emc-table at 0 {
>>> nvidia,ram-code = <0>;
>>> timing at 0 {
>>> ...
>>> };
>>> ...
>>> };
>>
>> Until recently, there was a binding for Tegra20 EMC in mainline. We
>> should make sure the Tegra124 driver (or rather binding...) is at least
>> as feature-ful as that was.
>>
>> Furthermore, I thought that with some boards, there were more RAM
>> options that there were available RAM code strap bits. I assume that in
>> mainline, we'll simply have different base DT files for the different
>> sets of configurations? Or, will we want to add another level to the DT
>> to represent different sets of RAM code values? I'm not sure what data
>> source the bootloader uses to determine which set of RAM configuration
>> to use when there aren't enough entries in the BCT for the boot ROM to
>> do this automatically, and whether we have any way to get that value
>> into the kernel, so it could use it for the extra DT level lookup?
>
> For the ChromeOS boards at least we are neither limited by the number
> of strapping bits (4) nor the number of BCT entries supported by the
> boot ROM (since coreboot does not rely on the boot ROM for SDRAM
> initialization), so having a single set of SDRAM configurations for
> each board, indexed by APBDEV_PMC_STRAPPING_OPT_A_0[7:4] works just
> fine.
Does the bootloader adjust the DT that's passed to the kernel so that
only the relevant single set of EMC timings is contained in the DT?
On a system where the boot ROM initializes RAM, and where the HW design
might have multiple SDRAM configuration, here's what usually happens:
a) The BCT contains N sets of SDRAM configurations.
b) The boot ROM reads the SDRAM strapping bits, and uses them to pick
the correct SDRAM configuration from the N sets in the BCT.
c) The kernel DT has N sets of SDRAM configurations.
d) The kernel reads the SDRAM strapping bits, and uses them to pick the
correct SDRAM configuration from the N sets in the DT.
On the ChromeOS boards (so (a) and (b) above are irrelevant) where N is
too large to fit into APBDEV_PMC_STRAPPING_OPT_A_0[7:4], (c) and (d)
won't work. I assume the kernel DT therefore must be adjusted to only
contain the single SDRAM configuration that is relevant for the current HW?
(isn't STRAPPING_OPT_A split into 2 2-bit fields; 2 bits for SDRAM index
and 2 bits for boot flash index, so max N is quite small?)
next prev parent reply other threads:[~2014-07-22 16:45 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 14:18 [PATCH 0/8] Tegra124 EMC (external memory controller) support Mikko Perttunen
2014-07-11 14:18 ` [PATCH 1/8] clk: tegra124: Remove old emc_mux and emc clocks Mikko Perttunen
2014-07-11 14:18 ` [PATCH 2/8] ARM: tegra: Remove TEGRA124_CLK_EMC from tegra124-car.h Mikko Perttunen
2014-07-21 22:37 ` Stephen Warren
2014-07-29 8:28 ` Mikko Perttunen
2014-07-11 14:18 ` [PATCH 3/8] ARM: tegra: Add PLL_M_UD and PLL_C_UD to tegra124-car binding header Mikko Perttunen
2014-08-25 17:41 ` Stephen Warren
2014-09-17 13:41 ` Peter De Schrijver
2014-07-11 14:18 ` [PATCH 4/8] clk: tegra124: Add PLL_M_UD and PLL_C_UD clocks Mikko Perttunen
2014-07-11 14:18 ` [PATCH 5/8] of: Add Tegra124 EMC bindings Mikko Perttunen
2014-07-11 14:51 ` Thierry Reding
2014-07-11 16:01 ` Mikko Perttunen
2014-07-14 7:55 ` Mikko Perttunen
2014-07-14 8:15 ` Thierry Reding
2014-07-14 9:06 ` Mikko Perttunen
2014-07-14 9:31 ` Thierry Reding
2014-07-14 9:57 ` Mikko Perttunen
2014-07-14 10:29 ` Thierry Reding
2014-07-14 10:54 ` Mikko Perttunen
2014-07-14 11:10 ` Thierry Reding
2014-07-14 12:28 ` Mikko Perttunen
2014-07-11 16:43 ` Andrew Bresticker
2014-07-11 16:48 ` Mikko Perttunen
2014-07-21 21:28 ` Stephen Warren
2014-07-21 22:52 ` Andrew Bresticker
2014-07-22 16:45 ` Stephen Warren [this message]
2014-07-22 17:22 ` Andrew Bresticker
2014-07-22 17:34 ` Stephen Warren
2014-07-29 8:30 ` Mikko Perttunen
2014-07-29 15:49 ` Stephen Warren
2014-07-31 10:48 ` Mikko Perttunen
2014-07-31 11:05 ` Mikko Perttunen
2014-07-31 15:32 ` Stephen Warren
2014-07-21 22:36 ` Stephen Warren
2014-07-11 14:18 ` [PATCH 6/8] ARM: tegra: Add EMC to Tegra124 device tree Mikko Perttunen
2014-07-11 14:18 ` [PATCH 7/8] ARM: tegra: Add EMC timings to Jetson TK1 " Mikko Perttunen
2014-07-11 14:18 ` [PATCH 8/8] clk: tegra: Add EMC clock driver Mikko Perttunen
2014-07-22 16:57 ` Stephen Warren
2014-07-29 8:47 ` Mikko Perttunen
2014-07-29 20:19 ` Mike Turquette
2014-07-29 22:14 ` Stephen Warren
2014-07-30 9:34 ` Thierry Reding
2014-07-31 19:06 ` Mike Turquette
2014-07-31 19:53 ` Stephen Warren
2014-07-31 23:08 ` Mike Turquette
2014-08-01 6:31 ` Mikko Perttunen
2014-08-01 8:40 ` Thierry Reding
2014-08-25 17:40 ` [PATCH 0/8] Tegra124 EMC (external memory controller) support Stephen Warren
2014-08-26 7:42 ` Mikko Perttunen
2014-08-26 7:47 ` Thierry Reding
2014-08-26 8:02 ` Mikko Perttunen
2014-09-05 10:22 ` Tomeu Vizoso
2014-09-05 10:55 ` Mikko Perttunen
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=53CE9514.1050903@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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).