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

[Chen Baozi <baozich@xxxxxxxxx>]

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?

Cheers,

Baozi

> 
>> 
>> Are you using console_sync? It might mask any issue arising from not
>> getting these interrupts (or maybe even cause your initial issue?)
> 
> Yes. I have tried to shut this down to test whether it is the cause of  my
> issue. But it seems not.
> 
>> 
>> The LSI register is only of use if we care about RTS/CTS or something. I
>> don't know if we do, but I'd be surprised if just asking for the
>> interrupt was sufficient (i.e. we'd need to do something with the irq)
>> 
>> How did you configure this interrupt line, level or edge trigger? I'd
>> have expected it to need to be edge, and the issue sounds a bit like it
>> might be level.
> 
> It is high-level read from the DTS. I've also changed to it to edge trigger
> manually and every other possibilities when debugging. And it seems
> edge trigger doesn't help.
> 
> Anyway, some research must be done for this patch and my fixes to the
> issue next.
> 
> Thanks.
> 
> Baozi
> 
>> 
>> Ian.
>> 
>>> Signed-off-by: Chen Baozi <baozich@xxxxxxxxx>
>>> ---
>>> xen/drivers/char/ns16550.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
>>> index 9248330..60512be 100644
>>> --- a/xen/drivers/char/ns16550.c
>>> +++ b/xen/drivers/char/ns16550.c
>>> @@ -237,8 +237,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart)
>>>         ns_write_reg(uart,
>>>                      UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS);
>>> 
>>> -        /* Enable receive and transmit interrupts. */
>>> -        ns_write_reg(uart, UART_IER, UART_IER_ERDAI | UART_IER_ETHREI);
>>> +        /* Enable receive and line status interrupts. */
>>> +        ns_write_reg(uart, UART_IER, UART_IER_ERDAI | UART_IER_ELSI);
>>>     }
>>> 
>>>     if ( uart->irq >= 0 )
>> 
>> 


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