[PATCH v5 2/2] serial: mxc: have putc use the TXFIFO
SCHNEIDER Johannes
johannes.schneider at leica-geosystems.com
Thu Nov 3 07:17:22 CET 2022
Hi all,
flushing and waiting... maybe you're onto something: what if one printf races another since it thinks considers its buffer handed to the FIFO as "done" a bit too soon?
might the below variation on "waiting for the fifo" solve the symptoms on imx6?
regards
Johannes
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 4207650503..dfd7670f7e 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -329,8 +329,23 @@ static int mxc_serial_pending(struct udevice *dev, bool input)
return sr2 & USR2_TXDC ? 0 : 1;
}
+static ssize_t mxc_serial_puts(struct udevice *dev, const char *s, size_t len)
+{
+ struct mxc_serial_plat *plat = dev_get_plat(dev);
+ struct mxc_uart *const uart = plat->reg;
+
+ while (*s)
+ mcx_serial_putc(dev, *s++);
+
+ // flush the TXFIFO
+ while(mxc_serial_pending(dev, false));
+
+ return len;
+}
+
static const struct dm_serial_ops mxc_serial_ops = {
.putc = mxc_serial_putc,
+ .puts = mxc_serial_puts,
.pending = mxc_serial_pending,
.getc = mxc_serial_getc,
.setbrg = mxc_serial_setbrg,
________________________________________
From: Fabio Estevam <festevam at gmail.com>
Sent: Wednesday, November 2, 2022 19:37
To: Pali Rohár
Cc: Fabio Estevam; SCHNEIDER Johannes; Tim Harvey; u-boot at lists.denx.de; peng.fan at oss.nxp.com; sbabic at denx.de; trini; GEO-CHHER-bsp-development; Peng Fan
Subject: Re: [PATCH v5 2/2] serial: mxc: have putc use the TXFIFO
This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
On Wed, Nov 2, 2022 at 2:24 PM Pali Rohár <pali at kernel.org> wrote:
> Hello! This log just cleanly shows that UART TX FIFO is either broken or
> something drops its content prior all bytes are properly transmitted.
> Dropping HW TX FIFO is on most UARTs possible by resetting registers or
> reconfiguring buadrate.
>
> I have an idea, cannot some u-boot code calls some mxc function which
> changes parameters of UART and this will cause loosing of FIFO?
>
> For example I see two functions which are doing it. Could you try to add
> code which waits until content of FIFO is transmitted prior changing
> UART parameters?
>
> diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> index 4cf79c1ca24f..9611d9bc8a00 100644
> --- a/drivers/serial/serial_mxc.c
> +++ b/drivers/serial/serial_mxc.c
> @@ -146,6 +146,9 @@ struct mxc_uart {
>
> static void _mxc_serial_init(struct mxc_uart *base, int use_dte)
> {
> + while (!(readl(&base->ts) & UTS_TXEMPTY))
> + ;
> +
> writel(0, &base->cr1);
> writel(0, &base->cr2);
>
> @@ -169,6 +172,9 @@ static void _mxc_serial_setbrg(struct mxc_uart *base, unsigned long clk,
> {
> u32 tmp;
>
> + while (!(readl(&base->ts) & UTS_TXEMPTY))
> + ;
> +
Tried your suggestion, but the print() content I added inside
board_init() is no longer printed.
More information about the U-Boot
mailing list