1. 16 Sep, 2009 2 commits
    • Philippe Gerum's avatar
      Blackfin: use generic name for EVT14 handler · 9703a73c
      Philippe Gerum authored
      
      
      The purpose of the EVT14 handler may depend on whether CONFIG_IPIPE is
      enabled, albeit its implementation can be the same in both cases. When
      the interrupt pipeline is enabled, EVT14 can be used to raise the core
      priority level for the running code; when CONFIG_IPIPE is off, EVT14
      can be used to lower this level before running softirq handlers.
      
      Rename evt14_softirq to evt_evt14 to pick an identifier that fits
      both, which allows to reuse the same vector setup code as well.
      Signed-off-by: default avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      9703a73c
    • Robin Getz's avatar
      Blackfin: make EVT3->EVT5 lowering more robust wrt IPEND[4] · ae4f073c
      Robin Getz authored
      
      
      We handle many exceptions at EVT5 (hardware error level) so that we can
      catch exceptions in our exception handling code.  Today - if the global
      interrupt enable bit (IPEND[4]) is set (interrupts disabled) our trap
      handling code goes into a infinite loop, since we need interrupts to be
      on to defer things to EVT5.
      
      Normal kernel code should not trigger this for any reason as IPEND[4] gets
      cleared early (when doing an interrupt context save) and the kernel stack
      there should be sane (or something much worse is happening in the system).
      But there have been a few times where this has happened, so this change
      makes sure we dump a proper crash message even when things have gone south.
      Signed-off-by: default avatarRobin Getz <robin.getz@analog.com>
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      ae4f073c
  2. 15 Jul, 2009 1 commit
  3. 22 Jun, 2009 1 commit
  4. 13 Jun, 2009 2 commits
  5. 12 Jun, 2009 2 commits
    • Robin Getz's avatar
      Blackfin: make deferred hardware errors more exact · b9a3899d
      Robin Getz authored
      
      
      Hardware errors on the Blackfin architecture are queued by nature of the
      hardware design.  Things that could generate a hardware level queue up at
      the system interface and might not process until much later, at which
      point the system would send a notification back to the core.
      
      As such, it is possible for user space code to do something that would
      trigger a hardware error, but have it delay long enough for the process
      context to switch.  So when the hardware error does signal, we mistakenly
      evaluate it as a different process or as kernel context and panic (erp!).
      This makes it pretty difficult to find the offending context.  But wait,
      there is good news somewhere.
      
      By forcing a SSYNC in the interrupt entry, we force all pending queues at
      the system level to be processed and all hardware errors to be signaled.
      Then we check the current interrupt state to see if the hardware error is
      now signaled.  If so, we re-queue the current interrupt and return thus
      allowing the higher priority hardware error interrupt to process properly.
      Since we haven't done any other context processing yet, the right context
      will be selected and killed.  There is still the possibility that the
      exact offending instruction will be unknown, but at least we'll have a
      much better idea of where to look.
      
      The downside of course is that this causes system-wide syncs at every
      interrupt point which results in significant performance degradation.
      Since this situation should not occur in any properly configured system
      (as hardware errors are triggered by things like bad pointers), make it a
      debug configuration option and disable it by default.
      Signed-off-by: default avatarRobin Getz <robin.getz@analog.com>
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      b9a3899d
    • Graf Yang's avatar
      Blackfin: fix link failure due to CONFIG_EXCEPTION_L1_SCRATCH · f82e0a0c
      Graf Yang authored
      
      
      Move exception stack mess from entry.S to init.c to fix link failure when
      CONFIG_EXCEPTION_L1_SCRATCH is in use.
      Signed-off-by: default avatarGraf Yang <graf.yang@analog.com>
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarBryan Wu <cooloney@kernel.org>
      f82e0a0c
  6. 26 May, 2009 1 commit
  7. 04 Mar, 2009 1 commit
  8. 04 Feb, 2009 1 commit
  9. 07 Jan, 2009 1 commit
    • Bernd Schmidt's avatar
      Blackfin arch: Faster C implementation of no-MPU CPLB handler · dbdf20db
      Bernd Schmidt authored
      
      
      This is a mixture ofcMichael McTernan's patch and the existing cplb-mpu code.
      
      We ditch the old cplb-nompu implementation, which is a good example of
      why a good algorithm in a HLL is preferrable to a bad algorithm written in
      assembly.  Rather than try to construct a table of all posible CPLBs and
      search it, we just create a (smaller) table of memory regions and
      their attributes.  Some of the data structures are now unified for both
      the mpu and nompu cases.  A lot of needless complexity in cplbinit.c is
      removed.
      
      Further optimizations:
        * compile cplbmgr.c with a lot of -ffixed-reg options, and omit saving
          these registers on the stack when entering a CPLB exception.
        * lose cli/nop/nop/sti sequences for some workarounds - these don't
        * make
          sense in an exception context
      
      Additional code unification should be possible after this.
      
      [Mike Frysinger <vapier.adi@gmail.com>:
       - convert CPP if statements to C if statements
       - remove redundant statements
       - use a do...while loop rather than a for loop to get slightly better
         optimization and to avoid gcc "may be used uninitialized" warnings ...
         we know that the [id]cplb_nr_bounds variables will never be 0, so this
         is OK
       - the no-mpu code was the last user of MAX_MEM_SIZE and with that rewritten,
         we can punt it
       - add some BUG_ON() checks to make sure we dont overflow the small
         cplb_bounds array
       - add i/d cplb entries for the bootrom because there is functions/data in
         there we want to access
       - we do not need a NULL trailing entry as any time we access the bounds
         arrays, we use the nr_bounds variable
      ]
      Signed-off-by: default avatarMichael McTernan <mmcternan@airvana.com>
      Signed-off-by: default avatarMike Frysinger <vapier.adi@gmail.com>
      Signed-off-by: default avatarBernd Schmidt <bernds_cb1@t-online.de>
      Signed-off-by: default avatarBryan Wu <cooloney@kernel.org>
      dbdf20db
  10. 18 Nov, 2008 3 commits
  11. 07 Jan, 2009 1 commit
  12. 28 Oct, 2008 1 commit
  13. 27 Oct, 2008 1 commit
  14. 09 Oct, 2008 1 commit
  15. 08 Oct, 2008 1 commit
  16. 13 Oct, 2008 1 commit
  17. 08 Oct, 2008 1 commit
  18. 26 Aug, 2008 1 commit
  19. 14 Aug, 2008 1 commit
  20. 05 Aug, 2008 2 commits
  21. 26 Jul, 2008 1 commit
  22. 06 May, 2008 2 commits
  23. 06 Mar, 2008 1 commit
  24. 24 Apr, 2008 1 commit
  25. 22 Apr, 2008 1 commit
    • Bernd Schmidt's avatar
      [Blackfin] arch: fix bug - when using trace buffer with CONFIG_MPU enabled. · 2a0c4fdb
      Bernd Schmidt authored
      
      
      There were a couple of problems with the way the trace buffer state
      is saved/restored in assembly.  The DEBUG_HWTRACE_SAVE/RESTORE macros
      save a value to the stack, which is not immediately obvious; the CPLB
      exception code needed changes to load the correct value of the stack
      pointer.  The other problem is that the SAVE/RESTORE macros weren't
      pushing and popping the value downwards on the stack, but rather moving
      it _upwards_, which is of course completely broken.
      
      We also need to make sure there's a matching DEBUG_HWTRACE_RESTORE in
      the error case of the CPLB handler.
      Signed-off-by: default avatarBernd Schmidt <bernds_cb1@t-online.de>
      Signed-off-by: default avatarBryan Wu <cooloney@kernel.org>
      2a0c4fdb
  26. 05 Feb, 2008 1 commit
    • Davide Libenzi's avatar
      timerfd: new timerfd API · 4d672e7a
      Davide Libenzi authored
      This is the new timerfd API as it is implemented by the following patch:
      
      int timerfd_create(int clockid, int flags);
      int timerfd_settime(int ufd, int flags,
      		    const struct itimerspec *utmr,
      		    struct itimerspec *otmr);
      int timerfd_gettime(int ufd, struct itimerspec *otmr);
      
      The timerfd_create() API creates an un-programmed timerfd fd.  The "clockid"
      parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
      
      The timerfd_settime() API give new settings by the timerfd fd, by optionally
      retrieving the previous expiration time (in case the "otmr" parameter is not
      NULL).
      
      The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
      is set in the "flags" parameter.  Otherwise it's a relative time.
      
      The timerfd_gettime() API returns the next expiration time of the timer, or
      {0, 0} if the timerfd has not been set yet.
      
      Like the previous timerfd API implementation, read(2) and poll(2) are
      supported (with the same interface).  Here's a simple test program I used to
      exercise the new timerfd APIs:
      
      http://www.xmailserver.org/timerfd-test2.c
      
      
      
      [akpm@linux-foundation.org: coding-style cleanups]
      [akpm@linux-foundation.org: fix ia64 build]
      [akpm@linux-foundation.org: fix m68k build]
      [akpm@linux-foundation.org: fix mips build]
      [akpm@linux-foundation.org: fix alpha, arm, blackfin, cris, m68k, s390, sparc and sparc64 builds]
      [heiko.carstens@de.ibm.com: fix s390]
      [akpm@linux-foundation.org: fix powerpc build]
      [akpm@linux-foundation.org: fix sparc64 more]
      Signed-off-by: default avatarDavide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4d672e7a
  27. 02 Feb, 2008 1 commit
  28. 21 Nov, 2007 4 commits
  29. 27 Jan, 2008 2 commits