Documentation/arm/Sharp-LH/VectoredInterruptController

   1 README on the Vectored Interrupt Controller of the LH7A404
   2 ==========================================================
   3
   4 The 404 revision of the LH7A40X series comes with two vectored
   5 interrupts controllers.  While the kernel does use some of the
   6 features of these devices, it is far from the purpose for which they
   7 were designed.
   8
   9 When this README was written, the implementation of the VICs was in
  10 flux.  It is possible that some details, especially with priorities,
  11 will change.
  12
  13 The VIC support code is inspired by routines written by Sharp.
  14
  15
  16 Priority Control
  17 ----------------
  18
  19 The significant reason for using the VIC's vectoring is to control
  20 interrupt priorities.  There are two tables in
  21 arch/arm/mach-lh7a40x/irq-lh7a404.c that look something like this.
  22
  23   static unsigned char irq_pri_vic1[] = { IRQ_GPIO3INTR, };
  24   static unsigned char irq_pri_vic2[] = {
  25         IRQ_T3UI, IRQ_GPIO7INTR,
  26         IRQ_UART1INTR, IRQ_UART2INTR, IRQ_UART3INTR, };
  27
  28 The initialization code reads these tables and inserts a vector
  29 address and enable for each indicated IRQ.  Vectored interrupts have
  30 higher priority than non-vectored interrupts.  So, on VIC1,
  31 IRQ_GPIO3INTR will be served before any other non-FIQ interrupt.  Due
  32 to the way that the vectoring works, IRQ_T3UI is the next highest
  33 priority followed by the other vectored interrupts on VIC2.  After
  34 that, the non-vectored interrupts are scanned in VIC1 then in VIC2.
  35
  36
  37 ISR
  38 ---
  39
  40 The interrupt service routine macro get_irqnr() in
  41 arch/arm/kernel/entry-armv.S scans the VICs for the next active
  42 interrupt.  The vectoring makes this code somewhat larger than it was
  43 before using vectoring (refer to the LH7A400 implementation).  In the
  44 case where an interrupt is vectored, the implementation will tend to
  45 be faster than the non-vectored version.  However, the worst-case path
  46 is longer.
  47
  48 It is worth noting that at present, there is no need to read
  49 VIC2_VECTADDR because the register appears to be shared between the
  50 controllers.  The code is written such that if this changes, it ought
  51 to still work properly.
  52
  53
  54 Vector Addresses
  55 ----------------
  56
  57 The proper use of the vectoring hardware would jump to the ISR
  58 specified by the vectoring address.  Linux isn't structured to take
  59 advantage of this feature, though it might be possible to change
  60 things to support it.
  61
  62 In this implementation, the vectoring address is used to speed the
  63 search for the active IRQ.  The address is coded such that the lowest
  64 6 bits store the IRQ number for vectored interrupts.  These numbers
  65 correspond to the bits in the interrupt status registers.  IRQ zero is
  66 the lowest interrupt bit in VIC1.  IRQ 32 is the lowest interrupt bit
  67 in VIC2.  Because zero is a valid IRQ number and because we cannot
  68 detect whether or not there is a valid vectoring address if that
  69 address is zero, the eigth bit (0x100) is set for vectored interrupts.
  70 The address for IRQ 0x18 (VIC2) is 0x118.  Only the ninth bit is set
  71 for the default handler on VIC1 and only the tenth bit is set for the
  72 default handler on VIC2.
  73
  74 In other words.
  75
  76   0x000         - no active interrupt
  77   0x1ii         - vectored interrupt 0xii
  78   0x2xx         - unvectored interrupt on VIC1 (xx is don't care)
  79   0x4xx         - unvectored interrupt on VIC2 (xx is don't care)
  80