From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 1/2] ARM: VFP: add support to sync the VFP state of the current thread
Date: Sat, 6 Feb 2010 11:20:48 +0000 [thread overview]
Message-ID: <20100206112048.GD1923@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20100206103230.GC1923@n2100.arm.linux.org.uk>
On Sat, Feb 06, 2010 at 10:32:30AM +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 04, 2010 at 11:38:02PM +0200, Imre Deak wrote:
> > So far vfp_sync_state worked only for threads other than the current
> > one. This worked for tracing other threads, but not for PTRACE_TRACEME.
> > Syncing for the current thread will also be needed by an upcoming patch
> > adding support for VFP context save / restore around signal handlers.
> >
> > For SMP we need get_cpu now, since we have to protect the FPEXC
> > register, other than this things remained the same for threads other
> > than the current.
>
> I don't think we should make this function any more complicated than it
> already is.
... and the more I look at vfp_sync_state(), the more I believe it's
trying to do its job in a really obscure way.
Essentially, last_VFP_context[] tracks who owns the state in the VFP
hardware. If last_VFP_context[] is the context for the thread which
we're interested in, then the VFP hardware has context which is not
saved in the software state - so we need to bring the software state
up to date.
If last_VFP_context[] is for some other thread, we really don't care
what state the VFP hardware is in; it doesn't contain any information
pertinent to the thread we're trying to deal with - so leave the
hardware well alone.
As a side effect, this makes vfp_sync_state() callable for the current
thread, and allows it to do the right thing there as well.
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index f60a540..6447d78 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -444,32 +444,28 @@ void vfp_sync_state(struct thread_info *thread)
void vfp_sync_state(struct thread_info *thread)
{
unsigned int cpu = get_cpu();
- u32 fpexc = fmrx(FPEXC);
/*
- * If VFP is enabled, the previous state was already saved and
- * last_VFP_context updated.
+ * If the thread we're interested in is the current owner of the
+ * hardware VFP state, then we need to save its state.
*/
- if (fpexc & FPEXC_EN)
- goto out;
-
- if (!last_VFP_context[cpu])
- goto out;
+ if (last_VFP_context[cpu] == &thread->vfpstate) {
+ u32 fpexc = fmrx(FPEXC);
- /*
- * Save the last VFP state on this CPU.
- */
- fmxr(FPEXC, fpexc | FPEXC_EN);
- vfp_save_state(last_VFP_context[cpu], fpexc);
- fmxr(FPEXC, fpexc);
+ /*
+ * Save the last VFP state on this CPU.
+ */
+ fmxr(FPEXC, fpexc | FPEXC_EN);
+ vfp_save_state(&thread->vfpstate, fpexc | FPEXC_EN);
+ fmxr(FPEXC, fpexc);
- /*
- * Set the context to NULL to force a reload the next time the thread
- * uses the VFP.
- */
- last_VFP_context[cpu] = NULL;
+ /*
+ * Set the context to NULL to force a reload the next time
+ * the thread uses the VFP.
+ */
+ last_VFP_context[cpu] = NULL;
+ }
-out:
put_cpu();
}
#endif
next prev parent reply other threads:[~2010-02-06 11:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1242744292-23776-1-git-send-email-imre.deak@nokia.com>
2010-02-04 21:37 ` [RFC PATCH v2 0/2] ARM: VFP: Save / restore VFP state on the signal handler path Imre Deak
2010-02-04 21:38 ` [RFC PATCH v2 1/2] ARM: VFP: add support to sync the VFP state of the current thread Imre Deak
2010-02-06 10:32 ` Russell King - ARM Linux
2010-02-06 11:20 ` Russell King - ARM Linux [this message]
2010-02-06 11:32 ` Russell King - ARM Linux
2010-02-06 11:41 ` Russell King - ARM Linux
2010-02-06 15:55 ` Imre Deak
2010-02-04 21:38 ` [RFC PATCH v2 2/2] ARM: VFP: preserve the HW context when calling signal handlers Imre Deak
2010-02-06 9:25 ` Russell King - ARM Linux
2010-02-06 10:02 ` Imre Deak
2010-02-06 12:12 ` Russell King - ARM Linux
2010-02-06 16:23 ` Imre Deak
2010-03-29 16:17 ` [RFC PATCH v3 0/3] ARM: VFP: Save / restore VFP state on the signal handler path imre.deak at nokia.com
2010-03-31 21:23 ` [RFC PATCH v4 " imre.deak at nokia.com
2010-04-02 14:36 ` [RFC PATCH v5 0/2] " imre.deak at nokia.com
2010-04-02 14:36 ` [RFC PATCH v5 1/2] ARM: VFP: fix the SMP versions of vfp_{sync, flush}_hwstate imre.deak at nokia.com
2010-04-12 18:39 ` [RFC PATCH v5 1/2] ARM: VFP: fix the SMP versions of vfp_{sync,flush}_hwstate Russell King - ARM Linux
2010-04-02 14:36 ` [RFC PATCH v5 2/2] ARM: VFP: preserve the HW context when calling signal handlers imre.deak at nokia.com
2010-04-12 18:41 ` Russell King - ARM Linux
2010-04-12 22:04 ` [RFC PATCH v5 0/2] ARM: VFP: Save / restore VFP state on the signal handler path Jamie Lokier
2010-04-13 11:42 ` Imre Deak
2010-04-13 11:59 ` Nicolas Pitre
2010-04-07 16:24 ` [RFC PATCH v4 0/3] " Dirk Behme
2010-04-07 16:39 ` Imre Deak
2010-04-07 17:31 ` Jason McMullan
2010-03-31 21:23 ` [RFC PATCH v4 1/3] ARM: VFP: fix the SMP versions of vfp_{sync, flush}_hwstate imre.deak at nokia.com
2010-03-31 21:23 ` [RFC PATCH v4 2/3] ARM: VFP: make user_vfp struct packed imre.deak at nokia.com
2010-03-31 21:23 ` [RFC PATCH v4 3/3] ARM: VFP: preserve the HW context when calling signal handlers imre.deak at nokia.com
2010-03-29 16:17 ` [RFC PATCH v3 1/3] ARM: VFP: add support to sync the VFP state of the current thread imre.deak at nokia.com
2010-03-29 16:17 ` [RFC PATCH v3 2/3] ARM: VFP: make user_vfp struct packed imre.deak at nokia.com
2010-03-29 16:17 ` [RFC PATCH v3 3/3] ARM: VFP: preserve the HW context when calling signal handlers imre.deak at nokia.com
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=20100206112048.GD1923@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--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).