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

[Chen Baozi <baozich@xxxxxxxxx>]

On Jul 24, 2013, at 6:04 PM, Chen Baozi <baozich@xxxxxxxxx> wrote:

> 
> 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.


According to my test today, this dead loop above only happens in case that I 
have
loaded both xen-uImage & zImage(dom0). Once I loaded both two images, reset the
board and boot the system with xen-uImage only at the same address, the 
phenomenon
keeps the same (dead loop). However, if I powered down the board and then start
the system with xen-uImage only, or if I reset the board and load xen-uImage at
the address where zImage should be, this would not happen. Instead, there would
be a bunch of 'a' printed after interrupt enabled. And the following output info
after interrupt enabled would be print as expected. In other word, the while
loop does clear the transmit FIFO. 

Interestingly, the phenomenon when IER_ETHREI is not enabled is similar. If both
xen-uImage and zImage are loaded at the right address (zImage is loaded at
the address specified in DTS module@0), some external events need to be sent to
trigger the driver to continue outputting infos.

All the test described above is done without 'sync_console' bootargs.

Besides this test, I noticed that we set a timer to poll UART after enabling
the interrupt. And the timer initialization codes are platform specific, which
should be implemented in xen/arch/arm/platforms/omap5.c for example. However,
I haven't done this yet. (I used to plan to turn to this work after UART porting
has been done.) Is it a possible factor that may cause my issues?

Any ideas?

Cheers,

Baozi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel