On Sat, Apr 30, 2022 at 09:40:24AM +0200, Anton Lindqvist wrote: > On Sun, Mar 13, 2022 at 04:17:07PM +0100, Mark Kettenis wrote: > > > Date: Fri, 11 Mar 2022 07:53:13 +0100 > > > From: Anton Lindqvist <an...@basename.se> > > > > > > On Tue, Mar 08, 2022 at 01:44:47PM +0000, Visa Hankala wrote: > > > > On Tue, Mar 08, 2022 at 08:04:36AM +0100, Anton Lindqvist wrote: > > > > > On Mon, Mar 07, 2022 at 07:36:35AM +0000, Visa Hankala wrote: > > > > > > I still think that checking TXFF and using the same code for both > > > > > > SBSA and true PL011 UARTs would be the best choice. This would avoid > > > > > > fragmenting the code and improve robustness by relying on > > > > > > functionality > > > > > > that is common to the different controller variants. > > > > > > > > > > Fair enough, new diff. > > > > > > > > Maybe the comments should omit the FIFO space description and just > > > > mention the lack of the level control register in the SBSA UART > > > > register interface. > > > > > > I ended up tweaking the comments before committing. Thanks for all the > > > feedback. > > > > > > > Hi Anton, > > > > This diff seems to break things. When I boot my rpi4 it now prints: > > > > pluart0 at simplebus0: rev 0, 16 byte fifo > > pluart0: console > > bcmbsc0 at simplebus0 > > iic0 at bcmbsc0 > > > > so it appears that a carriage return character is lost here. > > > > Later on output stops at: > > > > reordering libraries: done. > > > > and only when I reboot the machine the login prompt appears, but with > > some wierd respawning: > > > > OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console) > > > > login: init: getty repeating too quickly on port /dev/console, sleeping > > init: getty repeating too quickly on port /dev/console, sleeping > > > > OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console) > > > > login: > > OpenBSD/arm64 (rutter.sibelius.xs4all.nl) (console) > > > > login: > > > > If you don't have a quick fix for this, may I suggest reverting the > > commit? We're heading towards release and we don't want the serial > > console on the rpi4 to be broken. > > Circling back to this: what happens is that no tx interrupt is raised > when sending less data than the configured interrupt fifo level, causing > the tty to end up in a forever busy state. Clearing the busy flag after > a successful transmission of all queued data solves the problem.
Are you sure about the behaviour of the interrupt? One possible problem is that pluart_intr() uses the raw, unmasked, interrupt status to clear interrupts. Your previous patch always disabled the Tx interrupt whenever the raw status indicated a Tx FIFO level event. This new patch might very well be correct. However, it feels strange if the hardware raises the Tx interrupt only at one specific level of FIFO state change. It would be nice to know if a comstart()-style arrangement of interrupt masking worked in pluart_start().
