From: imre.deak@nokia.com (Imre Deak)
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 17:55:06 +0200 [thread overview]
Message-ID: <20100206155506.GB1109@localhost> (raw)
In-Reply-To: <20100206112048.GD1923@n2100.arm.linux.org.uk>
On Sat, Feb 06, 2010 at 12:20:48PM +0100, ext Russell King - ARM Linux wrote:
> 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.
Agreed, vfp_sync_state is cleaner and more efficient this way. One note
is that the SMP version will still not update the software state in case
it's called for the current thread and the VFP is enabled.
--Imre
>
> 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 15:55 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
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 [this message]
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=20100206155506.GB1109@localhost \
--to=imre.deak@nokia.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 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).