From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: mvebu: Enable SCU Speculative linefills to L2 for Armada 375/38x
Date: Thu, 26 Jun 2014 16:52:30 +0200 [thread overview]
Message-ID: <20140626165230.374f285e@free-electrons.com> (raw)
In-Reply-To: <1403790178-23902-1-git-send-email-gregory.clement@free-electrons.com>
Dear Gregory CLEMENT,
On Thu, 26 Jun 2014 15:42:58 +0200, Gregory CLEMENT wrote:
> +#define SCU_CTRL 0x00
> +#define SCU_SPEC_LINEFILL_EN BIT(3)
> +
> +
> /*
> * Enables the SCU when available. Obviously, this is only useful on
> * Cortex-A based SOCs, not on PJ4B based ones.
> @@ -44,7 +48,15 @@ static void __init mvebu_scu_enable(void)
> struct device_node *np =
> of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
> if (np) {
> + u32 scu_ctrl;
> scu_base = of_iomap(np, 0);
> + /* already enabled? */
> + scu_ctrl = __raw_readl(scu_base + SCU_CTRL);
Unless the SCU uses the native endianess of the system, and therefore
switches to big endian when the system is running big endian, using
__raw_{readl,writel} is wrong here, and will break big endian
configurations.
> + if (!(scu_ctrl & 1)) {
What is this bit 0 you're checking here? How does it relate to the bit
3 you're setting when bit 0 is not set?
A broader question is: if this feature is generic to all Cortex-A9, why
not offer a function in smp_scu.c to enable it? It seems weird to have
the offset and bit definitions for something as generic as the SCU
present deep into a Marvell-specific file.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-06-26 14:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-26 13:42 [PATCH] ARM: mvebu: Enable SCU Speculative linefills to L2 for Armada 375/38x Gregory CLEMENT
2014-06-26 14:52 ` Thomas Petazzoni [this message]
2014-06-26 15:09 ` Gregory CLEMENT
2014-06-26 16:12 ` Andrew Lunn
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=20140626165230.374f285e@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--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 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.