On Sat, Mar 7, 2020 at 2:13 AM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote:
>
> On Tue, 03 Mar 2020 00:41:40 PST (-0800), vincent.chen@xxxxxxxxxx wrote:
> > Add CONSOLE_POLL support for future KGDB porting.
> >
> > Signed-off-by: Vincent Chen <vincent.chen@xxxxxxxxxx>
> > ---
> > drivers/tty/serial/sifive.c | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/tty/serial/sifive.c b/drivers/tty/serial/sifive.c
> > index d5f81b98e4d7..acdbaca4de36 100644
> > --- a/drivers/tty/serial/sifive.c
> > +++ b/drivers/tty/serial/sifive.c
> > @@ -818,6 +818,29 @@ static int __init sifive_serial_console_setup(struct console *co, char *options)
> > return uart_set_options(&ssp->port, co, baud, parity, bits, flow);
> > }
> >
> > +#ifdef CONFIG_CONSOLE_POLL
> > +static int sifive_serial_poll_get_char(struct uart_port *port)
> > +{
> > + struct sifive_serial_port *ssp = port_to_sifive_serial_port(port);
> > + char is_empty, ch;
> > +
> > + ch = __ssp_receive_char(ssp, &is_empty);
> > + if (is_empty)
> > + return NO_POLL_CHAR;
> > +
> > + return ch;
> > +}
> > +
> > +static void sifive_serial_poll_put_char(struct uart_port *port,
> > + unsigned char c)
> > +{
> > + struct sifive_serial_port *ssp = port_to_sifive_serial_port(port);
> > +
> > + sifive_serial_console_putchar(port, c);
> > + __ssp_wait_for_xmitr(ssp);
>
> So we still have that TX watermark bug in the SiFive UARTs. If this function
> is supposed to wait until the word is actually out on the line then this isn't
> sufficient, but if it's just supposed to wait until the next write won't block
> then this is fine.
>
> I'm not really a serial person, so mabye someone else knows? For those
> unfamiliar with the issue, there's a pretty good description in the patch to
> fix it
>
> https://github.com/sifive/sifive-blocks/pull/90
>
I read the description is this patch and it is very clear to
understand the issue.
Thanks for your sharing.
In this case, the __ssp_wait_for_xmitr() is used to prevent the word in the
TX FIFO buffer from being corrupted by the next write. Therefore, I
think it might
be sufficient to check thetxdata.full bit.
Thanks for your comment.
