From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/8] of: Add Tegra124 EMC bindings
Date: Tue, 29 Jul 2014 09:49:10 -0600 [thread overview]
Message-ID: <53D7C276.2080204@wwwdotorg.org> (raw)
In-Reply-To: <53D75B90.7050501@nvidia.com>
On 07/29/2014 02:30 AM, Mikko Perttunen wrote:
> Looks like the TRM doesn't document this either. I'll add an option
> ("nvidia,short-ram-code" ?) for the next version.
Using the 2-bit RAM code field as the RAM code is normal operation, so I
wouldn't call this "short".
Using the 2-bit boot device code field as extra RAM code bits is
non-standard.
I would suggest nvidia,use-4-bit-ram-code or
nvidia,use-boot-device-code-as-ram-code-msbs(!) as the property.
I see that the TRM implies the whole 4-bit field is RAM code, rather
than there being 2 separate 2-bit fields for RAM code and boot device
code. Can you please file a bug against the TRM to document this
correctly? (The details of which bits are which are visible on the
Jetson TK1 schematics for example).
> On 22/07/14 20:34, Stephen Warren wrote:
>> On 07/22/2014 11:22 AM, Andrew Bresticker wrote:
>>> On Tue, Jul 22, 2014 at 9:45 AM, Stephen Warren
>>> <swarren@wwwdotorg.org> wrote:
>>>>
>>>> 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?
>>>
>>> No, the DT contains all possible EMC timings for that board.
>>>
>>>> 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?)
>>>
>>> Right, there are normally only 2 SDRAM strapping bits available.
>>> ChromeOS gets around this by having 4 identical boot device entries in
>>> the BCT, so all possible values of STRAPPING_OPT_A[7:6] map to the
>>> same boot device. This allows us to use all 4 strapping bits in
>>> coreboot to pick the SDRAM configuration.
>>
>> OK, that explains how it works.
>>
>> But that means that when the kernel reads the strapping options, it will
>> have to know if it uses just 2 bits (standard) or all 4 bits
>> (non-standard) to index into the DT's array of SDRAM configurations.
>> We'll need a DT property to represent that.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2014-07-29 15:49 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
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 [this message]
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=53D7C276.2080204@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).