Re: Tegra 2: Spurious interrupts from UARTA (@70006000)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Two question for anybody using the serial console on Tegra2 based systems:

  Do you have a early-boot console on it?

  Do you use the 8250 driver or the hsuart driver?

  If the hsuart driver: how did you configure it so that early boot
really gets shown? This currently does now work for me and might be a
workaround here.




And also a follow-up on what I found so far on the interrupt-controller
side:

The UART1 block is connected to the secondary interrupt controller
(LIC). which is in turn connected to the CPUs GIC. I traced the whole
thing by now and here is a collection of what I found in the error case:

* GIC gets interrupt
* gic_handle_irq() gets called and reads 0x44 as the triggering
interrupt. 0x44 = 68 = 32 + 32 + 4. where 32 = cpu-internal ints, 32 =
primary int. controller, 4 = UARTA interrupt of secondary interrupt
controller. so the UARTA interrupt is seen.
* the UARTA handler kicks in and reads the IIR of the UARTA block, which
is 0xC1, where the lower four bits = 0b0001 mean: no interrupt.
* UARTA handler leaves and tegra_eoi gets called, which writes
0x00000010 to the acknowledge-register of the secondary interrupt
register, thus trying to acknowledge the UARTA interrupt anyways.
* interrupt handler leaves
* interrupt handler gets called again immediately with the same outcome.

I traced *all* register accesses to the UART. So I am sure that there is
no interrupt shown in the IIR.
This means that either the secondary interrupt controller gets stuck
somehow, or that the UARTA is triggering interrupts but not showing them
in the IIR.




There is one interesting thing about the events that lead up to the
situation. As i have been tracing all the register accesses, it seems
that it (pretty much) always looks like this:

* interrupts are all ok, everything is working fine.

* when the TX queue is empty:
* UARTA.IER := 0x15. I.e. We enable interrupts RHR (received data), RXS
(receiver line status) and RX_TIMEOUT.

* at some point a character needs to be written, so we enable the
interrupt for an empty TX queue:
* UARTA.IER := 0x17. I.e. we add the "transmitter holding register
empty" interrupt

* we almost immediately get an interrupt, as the queue has been empty
for a while:
* UARTA.IIR == 0xC2

* now we write the char (in interrupt context)
* UARTA.TX := some char

* still inside the ISR, we see that the kernel-side tx queue is empty,
so we disable the interrupt again:
* UARTA.IER := 0x15.

* interrupt gets triggered again immediately after that, but no
interrupt is set:
* UARTA.IIR == 0xC1

and again.
and again...




Thanks,

David
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux