Re: [Xen-devel] [PATCH 27/27 v10] xen/arm: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

[Julien Grall <julien.grall@xxxxxxx>]

Hi Dave,

On 09/26/2017 03:38 PM, Dave Martin wrote:
> On Fri, Sep 22, 2017 at 01:53:26PM +0530, Bhupinder Thakur wrote:
> > This patch fixes the issue observed when pl011 patches were tested on
> > the junos hardware by Andre/Julien. It was observed that when large output is
> > generated such as on running 'find /', output was getting truncated 
> > intermittently
> > due to OUT ring buffer getting full.
> >
> > This issue was due to the fact that the SBSA UART driver expects that when
> > a TX interrupt is asserted then the FIFO queue should be atleast half empty and
> > that it can write N bytes in the FIFO, where N is half the FIFO queue size, 
> > without
> > the bytes getting dropped due to FIFO getting full.
> >
> > The SBSA UART emulation logic was asserting the TX interrupt as soon as
> > any space became available in the FIFO and the SBSA UART driver tried to write
> > more data (upto 16 bytes) in the FIFO expecting that there is enough space
> > available leading to dropped bytes.
> >
> > The SBSA spec [1] does not specify when the TX interrupt should be asserted
> > or de-asserted. Due to lack of clarity on the expected behavior, it is
> > assumed for now that TX interrupt should be asserted only when the FIFO goes
> > half empty.
> >
> > TBD: Once the SBSA spec is updated with the expected behavior, the 
> > implementation
> > will be modified to align with the spec requirement.
> >
> > [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183f/DDI0183.pdf
> >
> > Signed-off-by: Bhupinder Thakur <bhupinder.thakur@xxxxxxxxxx>
> > ---
> > CC: Julien Grall <julien.grall@xxxxxxx>
> > CC: Andre Przywara <andre.przywara@xxxxxxx>
> > CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> (Taking a quick look at this because I remember fighthing with FIFO
> behaviour issues when hacking the Linux driver -- but beware, I'm not a
> Xen guy...)
>
>
> Should this patch be flattened into the patches is fixes?  Keeping
> known-wrong code in the series does not help reviewers (but maybe it's
> the Xen way).
We usually prefer to have patch fold into the patches it fixes. However, 
I specifically ask Bhupinder to do a follow-up because the rest of the 
series is nearly ready.
So we could merge the first 25 patches before the code freeze as the two 
other could be considered as bug fixes. This would allow us to get PL011 
support in Xen 4.10.
Cheers,

--
Julien Grall

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