1. 15 Feb, 2010 1 commit
    • Russell King's avatar
      ARM: vfp: fix vfp_sync_state() · 54cb3dbb
      Russell King authored
      
      
      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: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      54cb3dbb
  2. 18 Dec, 2009 1 commit
  3. 13 Dec, 2009 1 commit
    • Russell King's avatar
      ARM: VFP: fix vfp thread init bug and document vfp notifier entry conditions · 0d782dc4
      Russell King authored
      
      
      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: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      0d782dc4
  4. 30 May, 2009 1 commit
    • Catalin Marinas's avatar
      Fix the VFP handling on the Feroceon CPU · 85d6943a
      Catalin Marinas authored
      
      
      This CPU generates synchronous VFP exceptions in a non-standard way -
      the FPEXC.EX bit set but without the FPSCR.IXE bit being set like in the
      VFP subarchitecture 1 or just the FPEXC.DEX bit like in VFP
      subarchitecture 2. The main problem is that the faulty instruction
      (which needs to be emulated in software) will be restarted several times
      (normally until a context switch disables the VFP). This patch ensures
      that the VFP exception is treated as synchronous.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Nicolas Pitre <nico@cam.org>
      85d6943a
  5. 01 Apr, 2009 1 commit
  6. 12 Feb, 2009 2 commits
  7. 18 Dec, 2008 1 commit
    • Ben Dooks's avatar
      [ARM] 5349/1: VFP: Add PM code to save and restore current VFP state · fc0b7a20
      Ben Dooks authored
      
      
      When CONFIG_PM is selected, the VFP code does not have any handler
      installed to deal with either saving the VFP state of the current
      task, nor does it do anything to try and restore the VFP after a
      resume.
      
      On resume, the VFP will have been reset and the co-processor access
      control registers are in an indeterminate state (very probably the
      CP10 and CP11 the VFP uses will have been disabled by the ARM core
      reset). When this happens, resume will break as soon as it tries to
      unfreeze the tasks and restart scheduling.
      
      Add a sys device to allow us to hook the suspend call to save the
      current thread state if the thread is using VFP and a resume hook
      which restores the CP10/CP11 access and ensures the VFP is disabled
      so that the lazy swapping will take place on next access.
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      fc0b7a20
  8. 06 Nov, 2008 1 commit
  9. 26 Jun, 2008 1 commit
  10. 26 Jan, 2008 1 commit
    • Catalin Marinas's avatar
      [ARM] 4582/2: Add support for the common VFP subarchitecture · c98929c0
      Catalin Marinas authored
      
      
      This patch allows the VFP support code to run correctly on CPUs
      compatible with the common VFP subarchitecture specification (Appendix
      B in the ARM ARM v7-A and v7-R edition). It implements support for VFP
      subarchitecture 2 while being backwards compatible with
      subarchitecture 1.
      
      On VFP subarchitecture 1, the arithmetic exceptions are asynchronous
      (or imprecise as described in the old ARM ARM) unless the FPSCR.IXE
      bit is 1. The exceptional instructions can be read from FPINST and
      FPINST2 registers. With VFP subarchitecture 2, the arithmetic
      exceptions can also be synchronous and marked by the FPEXC.DEX bit
      (the FPEXC.EX bit is cleared). CPUs implementing the synchronous
      arithmetic exceptions don't have the FPINST and FPINST2 registers and
      accessing them would trigger and undefined exception.
      
      Note that FPEXC.EX bit has an additional meaning on subarchitecture 1
      - if it isn't set, there is no additional information in FPINST and
      FPINST2 that needs to be saved at context switch or when lazy-loading
      the VFP state of a different thread.
      
      The patch also removes the clearing of the cumulative exception flags in
      FPSCR when additional exceptions were raised. It is up to the user
      application to clear these bits.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      c98929c0
  11. 20 Oct, 2007 1 commit
  12. 13 Sep, 2007 1 commit
  13. 20 Jul, 2007 1 commit
  14. 10 Jun, 2007 1 commit
    • Russell King's avatar
      [ARM] VFP: fix section mismatch error · 5d4cae5f
      Russell King authored
      
      
      Fix a real section mismatch issue; the test code is thrown away after
      initialisation, but if we do not detect the VFP hardware, it is left
      hooked into the exception handler.  Any VFP instructions which are
      subsequently executed risk calling the discarded exception handler.
      
      Introduce a new "null" handler which returns to the "unrecognised
      fault" return address.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      5d4cae5f
  15. 25 Jan, 2007 1 commit
  16. 02 Jan, 2007 1 commit
  17. 08 Dec, 2006 1 commit
    • Russell King's avatar
      [ARM] Handle HWCAP_VFP in VFP support code · efe90d27
      Russell King authored
      
      
      Don't set HWCAP_VFP in the processor support file; not only does it
      depend on the processor features, but it also depends on the support
      code being present.  Therefore, only set it if the support code
      detects that we have a VFP coprocessor attached.
      
      Also, move the VFP handling of the coprocessor access register into
      the VFP support code.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      efe90d27
  18. 28 Oct, 2006 1 commit
  19. 11 Oct, 2006 1 commit
  20. 20 Sep, 2006 1 commit
  21. 27 Aug, 2006 1 commit
  22. 30 Jun, 2006 1 commit
  23. 22 Jun, 2006 1 commit
    • Russell King's avatar
      [ARM] Add thread_notify infrastructure · d6551e88
      Russell King authored
      
      
      Some machine classes need to allow VFP support to be built into the
      kernel, but still allow the kernel to run even though VFP isn't
      present.  Unfortunately, the kernel hard-codes VFP instructions
      into the thread switch, which prevents this being run-time selectable.
      
      Solve this by introducing a notifier which things such as VFP can
      hook into to be informed of events which affect the VFP subsystem
      (eg, creation and destruction of threads, switches between threads.)
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      d6551e88
  24. 05 May, 2006 1 commit
  25. 25 Apr, 2006 1 commit
  26. 29 Jun, 2005 1 commit
  27. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!
      1da177e4