| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |