1. 30 Nov, 2008 1 commit
    • Arnd Bergmann's avatar
      powerpc/cell/axon-msi: Retry on missing interrupt · d015fe99
      Arnd Bergmann authored
      
      
      The MSI capture logic for the axon bridge can sometimes
      lose interrupts in case of high DMA and interrupt load,
      when it signals an MSI interrupt to the MPIC interrupt
      controller while we are already handling another MSI.
      
      Each MSI vector gets written into a FIFO buffer in main
      memory using DMA, and that DMA access is normally flushed
      by the actual interrupt packet on the IOIF.  An MMIO
      register in the MSIC holds the position of the last
      entry in the FIFO buffer that was written.  However,
      reading that position does not flush the DMA, so that
      we can observe stale data in the buffer.
      
      In a stress test, we have observed the DMA to arrive
      up to 14 microseconds after reading the register.
      
      This patch works around this problem by retrying the
      access to the FIFO buffer.
      
      We can reliably detect the conditioning by writing
      an invalid MSI vector into the FIFO buffer after
      reading from it, assuming that all MSIs we get
      are valid.  After detecting an invalid MSI vector,
      we udelay(1) in the interrupt cascade for up to
      100 times before giving up.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      d015fe99
  2. 09 Jun, 2008 2 commits
  3. 23 May, 2008 1 commit
    • Michael Ellerman's avatar
      [POWERPC] Add debugging trigger to Axon MSI code · 72cac213
      Michael Ellerman authored
      
      
      This adds some debugging code to the Axon MSI driver.  It creates a
      file per MSIC in /sys/kernel/debug/powerpc, which allows the user to
      trigger a fake MSI interrupt by writing to the file.
      
      This can be used to test some of the MSI generation path.  In
      particular, that the MSIC recognises a write to the MSI address,
      generates an interrupt and writes the MSI packet into the ring buffer.
      
      All the code is inside #ifdef DEBUG so it causes no harm unless it's
      enabled.
      Signed-off-by: default avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      72cac213
  4. 24 Apr, 2008 1 commit
  5. 06 Feb, 2008 3 commits
  6. 15 Oct, 2007 2 commits
    • Michael Ellerman's avatar
      Remove msic_dcr_read() in axon_msi.c · 2843e7f7
      Michael Ellerman authored
      
      
      msic_dcr_read() doesn't really do anything useful, just replace it with
      direct calls to dcr_read().
      Signed-off-by: default avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      2843e7f7
    • Michael Ellerman's avatar
      Add dcr_host_t.base in dcr_read()/dcr_write() · 83f34df4
      Michael Ellerman authored
      
      
      Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we
      can save them the trouble and do it in dcr_read()/dcr_write().
      
      As some background to why we just went through all this jiggery-pokery,
      benh sayeth:
      
       Initially the goal of the dcr_read/dcr_write routines was to operate like
       mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx
       hardware, indirect DCR access is a pain (goes through a table of
       instructions) and it's useful to have the compiler resolve an absolute DCR
       inline.
      
       We decided that wasn't worth the API bastardisation since most places
       where absolute DCR values are used are low level 4xx-only code which may
       as well continue using mfdcr/mtdcr, while the new API is designed for
       device "instances" that can exist on 4xx and Axon type platforms and may
       be located at variable DCR offsets.
      Signed-off-by: default avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      83f34df4
  7. 03 Oct, 2007 1 commit
  8. 02 Oct, 2007 1 commit
  9. 13 Sep, 2007 2 commits
  10. 20 Jul, 2007 1 commit