Re: [Xen-devel] [PATCH 3/4] xen: set the right flags when enabling interrupts for 8250

[Chen Baozi <baozich@xxxxxxxxx>]

On Jul 23, 2013, at 7:47 PM, Chen Baozi <baozich@xxxxxxxxx> wrote:

> 
> On Jul 22, 2013, at 8:59 PM, Chen Baozi <baozich@xxxxxxxxx> wrote:
> 
>> 
>> On Jul 19, 2013, at 11:18 PM, Chen Baozi <baozich@xxxxxxxxx> wrote:
>> 
>>> On Fri, Jul 19, 2013 at 10:15 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
>>> wrote:
>>>> 
>>>> On Fri, 2013-07-19 at 20:57 +0800, Chen Baozi wrote:
>>>>> Previous bits setting would cause generating THRE interrupts, which cannot
>>>>> be cleared and make system loop in gic_interrupt endlessly. Set 'received
>>>>> data available' and 'receiver line status' bits of IER when enabling
>>>>> interrupts as what Linux 8250 driver does.
>>>> 
>>>> We do actually want THRE interrupts though, don't we? Otherwise how do
>>>> we know when we can send more stuff?
>>> 
>>> I'm not very sure about it. In Linux 8250 driver THRE is not set at this 
>>> stage.
>>> And following it does work for OMAP5. I'll try to dig it next to see
>>> whether this fix is reasonable.
>> 
>> I rechecked the Linux codes today. In Linux, THRE is only enabled during tx
>> (enable at start_tx and disable at stop_tx) when enabling Modem Status 
>> interrupt.
>> Every time when handling irq, the Linux driver will check the MSR. If Modem
>> Status interrupt is enabled and delta-CTS flag is set, it will enter the 
>> codes
>> switching THRE status (by start_tx or stop_tx). So at least, I think, THRE 
>> should
>> not be enabled all the time once 8250 driver is initialized. Since Xen UART 
>> driver
>> doesn't seem to be complex as Linux does, I haven't found a proper pointer 
>> to insert
>> "start_tx/stop_tx" logic in Xen UART driver yet. And I think THRE might not 
>> be set
>> at ns16550_setup_postirq actually.
>> 
>> For "how do we know when we can send more stuff?", I think the while loop in
>> ns16550_interrupt checking UART_LSR_THRE flag can guarantee it. UART_LSR_THRE
>> is set when the THR (or transmitter FIFO) and the TSR are both empty 
>> regardless
>> of status of THRE flag in IER register.
>> 
>> BTW, I've also re-checked about console_sync and irq type. Neither of them is
>> the cause of my issue.
>> 
>> Any ideas?
> 
> According to my test today, when disable sync_consoleïTHRE interrupt is needed
> to transmit info. However, enabling it all the time since postirq is not
> appropriate because it would keep on interrupting system endless after the tx
> is completed.

There is a very weird phenomenon of my OMAP5 UART.

According to its manual, when the transmitter FIFO and THRE interrupt are 
enabled,
transmit interrupts occur as follows:

1. The transmitter holding register interrupt (IIR & 0xf == 0x2) occurs when the
transmit FIFO is empty. The transmit FIFO is cleared (IIR & 0xf == 0x1) when the
THR is written to or the IIR is read.

2. ...

What is weird is that I found the transmit FIFO is not cleared (IIR & 0xf == 
0x2)
no matter I write THR or read IIR.

I add the following piece of codes to test in ns16550_interrupt:

+       while (ns_read_reg(hart, UART_IIR) & 0x2) {
+               ns_write_reg(uart, UART_THR, 'a');
+       }

The result shows that it will never end the loop even if I've both written THR 
and read IIR.

PS, I re-confirmed about the interrupt type in the manual and the latest dts 
description in Linux kernel. It is a level triggered interrupt rather than the
edge.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel