From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Tegra: Configure L2 cache control reg properly.
Date: Fri, 29 Mar 2013 16:43:45 -0600 [thread overview]
Message-ID: <51561921.2040709@wwwdotorg.org> (raw)
In-Reply-To: <1364589490-2759-1-git-send-email-twarren@nvidia.com>
On 03/29/2013 02:38 PM, Tom Warren wrote:
> Without this change, kernel fails at calling function cache_clean_flush
> during kernel early boot.
>
> Aprocryphally, intended for T114 only, so I check for a T114 SoC.
> Works (i.e. dalmore 3.8 kernel now starts printing to console).
I don't know enough about the caches to really review this, but I have
no particular objection to it. My one comment is ...
> diff --git a/arch/arm/cpu/tegra-common/cache.c b/arch/arm/cpu/tegra-common/cache.c
> +void config_cache(void)
> + /* Currently, only T114 needs this L2 cache change to boot Linux */
> + reg = (readl(&gp->hidrev) & HIDREV_CHIPID_MASK);
> + if (reg != (CHIPID_TEGRA114 << HIDREV_CHIPID_SHIFT))
> + return;
Can we introduce a standard function for that instead? We already have
tegra_get_chip_type() which returns a SKU-based ID. I think we need to
introduce a tegra_get_soc_type() that returns a pure Tegra20/30/114
value, and probably use this in most places we currently use the result
of tegra_get_chip_type(), since most care about SW-compatibility of
features rather than SKU which drivers performance levels instead
typically. Then, perhaps rename tegra_get_chip_type() to
tegra_get_soc_sku() and re-write it to use tegra_get_soc_type()?
next prev parent reply other threads:[~2013-03-29 22:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-29 20:38 [U-Boot] [PATCH] Tegra: Configure L2 cache control reg properly Tom Warren
2013-03-29 22:43 ` Stephen Warren [this message]
2013-03-29 23:32 ` Tom Warren
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=51561921.2040709@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.