Altera JTAG UART used by kernel does not match IRQ assignment made in Qsys

[Altera_Forum]

Hi all, 

 I'm currently developing a 3.10.31-ltsi kernel that running on a Nios II-based system. This system also contains several components including an Altera JTAG UART, USB host controller and a timer.  In Qsys, I assigned the following Nios II interrupts for these system components: jtaguart: IRQ 0 timer: IRQ 1 usbhc: IRQ 2   The device tree binary (.dtb), U-boot and the kernel are built using these assignments and stored to flash.  However, when the kernel boots, the interrupt for the Altera JTAG UART is remapped to IRQ 2 as seen in the following KERNEL DEBUG message:  ttyJ0 at MMIO 0x1001840 (irq = 2) is a Altera JTAG UART   When this happens, the kernel is no longer able to attach the USB host contoller (usbhc) to IRQ 2 and the following error messages come up:  genirq: flags mismatch irq 2. 00000000 (altera_jtaguart) vs. 00000080 (sls-hcd: usb1) altera_jtaguart: unable to attach altera jtag uart 0 interrupt vector=2   I have some questions about this process that I'm hoping someone can explain:  - When the Altera JTAG component / device is added, why is the interrupt remapped from IRQ 0 to IRQ 2?   - Why isn't the usbhc controller remapped from IRQ 2 to something else?  In addition, when I forced the Altera JTAG UART interrupt to IRQ 0 to match the Qsys setting by modifying the altera_jtaguart driver, when the kernel attempts to attach IRQ 0 to the JTAG UART, the following error message was displayed: altera_jtaguart: unable to attach Altera JTAG UART 0 interrupt vector=0[/I][/I]   However, the usbhc component was correctly added and attached to IRQ 2 as indicated by the following message:sls-hcd sls-hcd.0: irq2, io mem 0xe1008000[/I][/I]   Any feedback that would help explain what is happening with these interrupts during the kernel booting sequence would be appreciated.  - Brad

[Altera_Forum]

Hi Bhaumik, 

 Thank you for all the useful information from your testing. Based on your results, it does appear that IRQ 0 is reserved for something internal and shouldn't be assigned any Qsys component. We have seen similar results in our testing but I didn't perform any methodical tests like the ones you performed. I appreciate you sharing the results.  While it appears that IRQ 0 is reserved for something internal, I was unable to find any documentation that confirms what your test results. I would think that if IRQ 0 is reserved and should be left open then it should be documented somewhere to prevent the interrupt remapping confusion between Qsys and the Linux kernel. Although given, our test results, I will avoid assigning IRQ 0 to any Qsys component in the future when using a Linux OS.  I just returned from vacation so I'm going to catching up on a few items but I hope this will help resolve the interrupt remapped issue(s) I have been seeing. If I have any additional information based on my testing, I will let you know.  Thanks again for your help.  - Brad