From: Will Deacon <will.deacon@arm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>,
Stephen Warren <swarren@nvidia.com>, Gary King <gking@nvidia.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Colin Cross <ccross@android.com>, Olof Johansson <olof@lixom.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 3/8] ARM: tegra: rework Tegra secondary CPU core bringup
Date: Wed, 1 Feb 2012 11:08:36 +0000 [thread overview]
Message-ID: <20120201110836.GB3058@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20120131225045.GE8338@n2100.arm.linux.org.uk>
On Tue, Jan 31, 2012 at 10:50:45PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 31, 2012 at 06:40:41PM +0200, Peter De Schrijver wrote:
> > +#ifdef CONFIG_ARM_ERRATA_743622
> > + teq r6, #0x20 @ present in r2p0
> > + teqne r6, #0x21 @ present in r2p1
> > + teqne r6, #0x22 @ present in r2p2
> > + teqne r6, #0x27 @ present in r2p7
> > + teqne r6, #0x29 @ present in r2p9
>
> Okay, so we have this errata in proc-v7.S, but only for p0..p2. If
> it's also p7 and p9, then it shows that the errata in the kernel aren't
> being actively maintained, and brings into question their worth.
It looks like the errata document has been updated since I wrote the
workaround in proc-v7.S (and new r2p* versions of the A9 have been
released). The new document states that r2p* are affected, so we should
update the workaround.
> Plus, of course, we don't want platforms re-implementing the errata
> in their own code if we're already implementing it somewhere in the
> kernel. So, that's something which needs to be thought about.
Indeed, that could become extremely confusing, especially when they start
doing different things.
> That's something that needs considering along side the whole 'what
> to do about errata when running in non-secure mode' problem which
> OMAP suffers from.
My view is that the workarounds in the kernel are a good way to highlight
which errata we consider to be important from Linux's point-of-view and also
how to avoid them in practice. It's not always possible to apply them in the
kernel at runtime (due to security constraints) but I think it's important
to show what Linux expects.
I'll go back through the errata document and check if any others have been
updated besides this one.
Will
next prev parent reply other threads:[~2012-02-01 11:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 16:40 [PATCH v2 0/8] Add tegra30 support for secondary cores Peter De Schrijver
2012-01-31 16:40 ` [PATCH v2 1/8] ARM: tegra: export the chipid Peter De Schrijver
2012-02-01 7:26 ` Olof Johansson
2012-01-31 16:40 ` [PATCH v2 2/8] ARM: tegra: functions to access the flowcontroller Peter De Schrijver
2012-02-01 7:26 ` Olof Johansson
2012-01-31 16:40 ` [PATCH v2 3/8] ARM: tegra: rework Tegra secondary CPU core bringup Peter De Schrijver
2012-01-31 22:50 ` Russell King - ARM Linux
2012-02-01 11:08 ` Will Deacon [this message]
2012-02-01 7:54 ` Olof Johansson
2012-02-01 10:01 ` Peter De Schrijver
2012-01-31 16:40 ` [PATCH v2 4/8] ARM: tegra: prepare powergate.c for multiple variants Peter De Schrijver
2012-01-31 16:40 ` [PATCH v2 5/8] ARM: tegra: export tegra_powergate_is_powered() Peter De Schrijver
2012-01-31 16:40 ` [PATCH v2 6/8] ARM: tegra: add support for Tegra30 powerdomains Peter De Schrijver
2012-01-31 16:40 ` [PATCH v2 7/8] ARM: tegra: support for Tegra30 CPU powerdomains Peter De Schrijver
2012-01-31 16:40 ` [PATCH v2 8/8] ARM: tegra: support for secondary cores on Tegra30 Peter De Schrijver
2012-02-02 18:04 ` Stephen Warren
2012-02-06 23:23 ` Peter De Schrijver
2012-02-02 18:17 ` Colin Cross
2012-02-01 8:33 ` [PATCH v2 0/8] Add tegra30 support for secondary cores Olof Johansson
2012-02-01 10:10 ` 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=20120201110836.GB3058@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=arnd@arndb.de \
--cc=ccross@android.com \
--cc=gking@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=olof@lixom.net \
--cc=pdeschrijver@nvidia.com \
--cc=swarren@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
all inboxes | Powered by JetHome®