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

[Chen Baozi <baozich@xxxxxxxxx>]

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.

Baozi


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