From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: vfp: Always save VFP state in vfp_pm_suspend
Date: Sun, 20 Feb 2011 12:57:45 +0000 [thread overview]
Message-ID: <20110220125745.GC14495@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <AANLkTim4ANuErvT4c5mBnu+Yg5m9sz6N8xugryXRJeN7@mail.gmail.com>
On Wed, Feb 16, 2011 at 11:36:45AM -0800, Colin Cross wrote:
> On Tue, Feb 15, 2011 at 9:03 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Feb 14, 2011 at 02:55:47PM -0800, Colin Cross wrote:
> >> diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
> >> index 66bf8d1..7231d18 100644
> >> --- a/arch/arm/vfp/vfpmodule.c
> >> +++ b/arch/arm/vfp/vfpmodule.c
> >> @@ -415,13 +415,13 @@ static int vfp_pm_suspend(struct sys_device *dev, pm_message_t state)
> >> ? ? ? struct thread_info *ti = current_thread_info();
> >> ? ? ? u32 fpexc = fmrx(FPEXC);
> >>
> >> - ? ? /* if vfp is on, then save state for resumption */
> >> - ? ? if (fpexc & FPEXC_EN) {
> >> + ? ? /* save state for resume */
> >> + ? ? if (last_VFP_context[ti->cpu]) {
> >
> > I'm not entirely happy with this.
> >
> > It is true that last_VFP_context[] when non-NULL indicates who owns the
> > hardware VFP state, so saving it would seem logical. ?However, this new
> > code now saves the state with the saved fpexc indicating that it's disabled.
> >
> > This will cause a VFP exception to misbehave by reloading the state, and
> > then disabling the VFP unit. ?That will cause another VFP exception which
> > will find the VFP unit disabled, and re-enable it. ?All in all, this is
> > rather wasteful.
> >
> > So...
> > ? ? ? ?/* If lazy disable, re-enable the VFP ready for it to be saved */
> > ? ? ? ?if (last_VFP_context[ti->cpu] != &ti->vfpstate) {
> > ? ? ? ? ? ? ? ?fpexc |= FPEXC_EN;
> > ? ? ? ? ? ? ? ?fmxr(FPEXC, fpexc);
> > ? ? ? ?}
> > ? ? ? ?/* If VFP is on, then save state for resumption */
> > ? ? ? ?if (fpexc & FPEXC_EN) {
> > ? ? ? ? ? ? ? ?...
>
> I think v2 of the patch handles this case correctly:
> /* save state for resume */
> if (last_VFP_context[ti->cpu]) {
> printk(KERN_DEBUG "%s: saving vfp state\n", __func__);
> fmxr(FPEXC, fpexc | FPEXC_EN);
> vfp_save_state(last_VFP_context[ti->cpu], fpexc);
This saves fpexc with the enable flag possibly clear.
> last_VFP_context[ti->cpu] = NULL;
> fmxr(FPEXC, fpexc & ~FPEXC_EN);
> }
>
> This version enables the VFP if it was not enabled, but saves the
> original fpexc value.
Which is wrong as I said above.
next prev parent reply other threads:[~2011-02-20 12:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-13 23:13 [PATCH] ARM: vfp: Always save VFP state in vfp_pm_suspend Colin Cross
2011-02-14 11:42 ` Catalin Marinas
2011-02-14 18:35 ` Colin Cross
2011-02-14 22:55 ` [PATCH v2] " Colin Cross
2011-02-15 16:51 ` Catalin Marinas
2011-02-15 17:03 ` Russell King - ARM Linux
2011-02-16 19:36 ` Colin Cross
2011-02-20 12:57 ` Russell King - ARM Linux [this message]
2011-02-20 18:43 ` Colin Cross
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=20110220125745.GC14495@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).