litmus-rt.git/arch/arm/vfp, branch linux-tip

ARM: 6203/1: Make VFPv3 usable on ARMv6

2010-07-09T13:41:34+00:00

MVFR0 and MVFR1 are only available starting with ARM1136 r1p0 release
according to "B.5 VFP changes" in DDI0211F_arm1136_r1p0_trm.pdf. This is
also when TLS register got added, so we can use HAS_TLS also to test for
MVFR0 and MVFR1.

Otherwise VFPFMRX and VFPFMXR access fails and we get:

Internal error: Oops - undefined instruction: 0 [#1]
PC is at no_old_VFP_process+0x8/0x3c
LR is at __und_svc+0x48/0x80
...

Signed-off-by: Tony Lindgren 
Acked-by: Catalin Marinas 
Signed-off-by: Russell King

ARM: VFP: Fix vfp_put_double() for d16-d31

2010-05-27T09:32:06+00:00

vfp_put_double() takes the double value in r0,r1 not r1,r2.

Reported-by: Tarun Kanti DebBarma 
Cc: 
Signed-off-by: Russell King

ARM: 6050/1: VFP: fix the SMP versions of vfp_{sync,flush}_hwstate

2010-04-14T10:11:30+00:00

From: Imre Deak 

Recently the UP versions of these functions were refactored and as
a side effect it became possible to call them for the current thread.
This isn't true for the SMP versions however, so fix this up.

Signed-off-by: Imre Deak 
Signed-off-by: Russell King

ARM: 5997/1: ARM: Correct the VFPv3 detection

2010-03-28T09:40:14+00:00

A CPU has VFPv3 hardware if the FPSID[19:16] bits are 2 or more.
Currently Linux was only checking for 3 or more.

Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King

Merge branch 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm

2010-03-01T17:15:15+00:00

* 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm: (100 commits)
  ARM: Eliminate decompressor -Dstatic= PIC hack
  ARM: 5958/1: ARM: U300: fix inverted clk round rate
  ARM: 5956/1: misplaced parentheses
  ARM: 5955/1: ep93xx: move timer defines into core.c and document
  ARM: 5954/1: ep93xx: move gpio interrupt support to gpio.c
  ARM: 5953/1: ep93xx: fix broken build of clock.c
  ARM: 5952/1: ARM: MM: Add ARM_L1_CACHE_SHIFT_6 for handle inside each ARCH Kconfig
  ARM: 5949/1: NUC900 add gpio virtual memory map
  ARM: 5948/1: Enable timer0 to time4 clock support for nuc910
  ARM: 5940/2: ARM: MMCI: remove custom DBG macro and printk
  ARM: make_coherent(): fix problems with highpte, part 2
  MM: Pass a PTE pointer to update_mmu_cache() rather than the PTE itself
  ARM: 5945/1: ep93xx: include correct irq.h in core.c
  ARM: 5933/1: amba-pl011: support hardware flow control
  ARM: 5930/1: Add PKMAP area description to memory.txt.
  ARM: 5929/1: Add checks to detect overlap of memory regions.
  ARM: 5928/1: Change type of VMALLOC_END to unsigned long.
  ARM: 5927/1: Make delimiters of DMA area globally visibly.
  ARM: 5926/1: Add "Virtual kernel memory..." printout.
  ARM: 5920/1: OMAP4: Enable L2 Cache
  ...

Fix up trivial conflict in arch/arm/mach-mx25/clock.c

ARM: vfp ptrace: no point flushing hw context for PTRACE_GETVFPREGS

2010-02-15T21:39:53+00:00

If we're only reading the VFP context via the ptrace call, there's
no need to invalidate the hardware context - we only need to do that
on PTRACE_SETVFPREGS.  This allows more efficient monitoring of a
traced task.

Signed-off-by: Russell King

ARM: vfp: fix vfp_sync_state()

2010-02-15T21:39:53+00:00

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 don't touch
the hardware.

Signed-off-by: Russell King

ARM: 5909/1: ARM: Correct the FPSCR bits setting when raising exceptions

2010-02-01T20:05:09+00:00

Commit c98929c07a removed the clearing of the FPSCR[31:28] bits from the
vfp_raise_exceptions() function and the new bits are or'ed with the old
FPSCR bits leading to unexpected results (the original commit was
referring to the cumulative bits - FPSCR[4:0]).

Reported-by: Tom Hameenanttila 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King

ARM: Convert VFP/Crunch/XscaleCP thread_release() to exit_thread()

2009-12-18T14:53:41+00:00

This avoids races in the VFP code where the dead thread may have
state on another CPU.  By moving this code to exit_thread(), we
will be running as the thread, and therefore be running on the
current CPU.

This means that we can ensure that the only local state is accessed
in the thread notifiers.

Acked-by: Catalin Marinas 
Signed-off-by: Russell King

ARM: VFP: fix vfp thread init bug and document vfp notifier entry conditions

2009-12-13T16:33:19+00:00

When the VFP notifier is called for flush_thread(), we may be
preemptible, meaning we might migrate to another CPU, which means
referencing the current CPU number without some form of locking is
invalid, and can cause data corruption.

For the most cases, this isn't a problem since atomic notifiers are run
under rcu lock, which for most configurations results in preemption
being disabled - except when the preemptable tree-based rcu
implementation is selected.

Let's make it safe anyway.

Signed-off-by: Russell King