aboutsummaryrefslogtreecommitdiff
path: root/include/asm-arm/fpstate.h
AgeCommit message (Collapse)Author
2008-01-26[ARM] 4583/1: ARMv7: Add VFPv3 supportCatalin Marinas
This patch adds the support for VFPv3 (the kernel currently supports VFPv2). The main difference is 32 double registers (compared to 16). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-01-25[ARM] 4111/1: Allow VFP to work with thread migration on SMPCatalin Marinas
The current lazy saving of the VFP registers is no longer possible with thread migration on SMP. This patch implements a per-CPU vfp-state pointer and the saving of the VFP registers at every context switch. The registers restoring is still performed in a lazy way. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-06-28[ARM] 3370/2: ep93xx: add crunch supportLennert Buytenhek
Patch from Lennert Buytenhek Add the necessary kernel bits for crunch task switching. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-04-26Don't include linux/config.h from anywhere else in include/David Woodhouse
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-04-10[ARM] 3472/1: Use the D variants of FLDMIA/FSTMIA on ARMv6Catalin Marinas
Patch from Catalin Marinas The X variants are deprecated starting with ARMv6. Using the D variants, the fpmx_state in vfp_hard_struct is no longer needed. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-03-12[ARM] iwmmxt thread state alignmentRussell King
This patch removes the reliance of iwmmxt on hand coded alignments. Since thread_info is always 8K aligned, specifying that fpstate is 8-byte aligned achieves the same effect without needing to resort to hand coded alignments. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!