Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, May 17, 2016 at 12:31:10PM -0400, Chris Patterson wrote:
> On Tue, May 17, 2016 at 9:37 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> wrote:
> >> - The serial controller on the Tegra SoCs doesn't behave in the same
> >> was as most NS16550-compatibles; it actually adheres to the NS16550
> >> spec a little more rigidly than most compatible controllers. A
> >> coworker (Chris Patterson, cc'd) figured out what was going on; from
> >> what I understand, most 16550s generate the "transmit ready" interrupt
> >> once, when the device first can accept new FIFO entries. Both the
> >> original 16550 and the Tegra implementation generate the "transmit
> >> ready" interrupt /continuously/ when there's space available in the
> >> FIFO, slewing the CPU with a stream of constant interrupts.
> >
> > That may also be an issue on x86 I would think.
> >
> 
> On the x86 serial I have tested, it appears that the THRE interrupt
> goes low after the IIR read reset, and doesn't re-assert until
> UART_IER is flipped (or data is transmitted).  On the Tegra, the
> interrupt persists (or immediately re-asserts) after the IIR read
> reset.  I suppose this could be a problem on x86 if this behaviour
> exists in another uart.
> 
> > Is there some simple 16550 'fix' for this? As in reprogram it
> > to not be soo ready?
> 
> Yes, I do have a patch in my queue to address this. It simply
> implements the start_tx and stop_tx hooks and sets or masks
> UART_IER_ETHREI accordingly.  I believe this behaviour is consistent
> with the Linux kernel.  I have done some limited testing on it with
> both x86 and the Tegra (with additional patches for Tegra support) and
> things appear to work well. I can RFC it when our employer gives us
> approval.  Apologies for the delay.

Awesome! Looking forward to them and reviewing them!
> 
> Have a good day!
> -Chris

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