Messages in this thread | | | Date | Wed, 16 Feb 2011 11:36:45 -0800 | Subject | Re: [PATCH v2] ARM: vfp: Always save VFP state in vfp_pm_suspend | From | Colin Cross <> |
| |
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); 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |