[PATCH v4 4/5] serial: 8250_dw: configure the Allwinner H616 UART
James Hilliard
james.hilliard1 at gmail.com
Thu Oct 29 12:08:03 PDT 2026
On Wed, Oct 28, 2026 at 5:05 AM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
>
> On Tue, Oct 27, 2026 at 05:05:32PM -0600, James Hilliard wrote:
> > H616 has 256-byte transmit and receive FIFOs, but its optional DesignWare
> > component parameter register reads as zero. Generic 16550 probing leaves
> > the port using the 16-byte FIFO configuration and its trigger-level table.
> >
> > Keep PORT_16550A and describe H616's fixed 256-byte FIFO depth in platform
> > data. Use common Allwinner setup helpers to configure the transmit load
> > and receive trigger table from that depth.
> >
> > Derive the receive thresholds from the documented 1-byte, quarter-full,
> > half-full and FIFO-depth-minus-two mapping. On H616 these are 1, 64, 128
> > and 254 bytes; the normal 16550A half-full FCR setting selects 128 bytes.
> >
> > Build the threshold table during setup and use the shared 8250 conversion
> > helper to select the nearest lower threshold for sysfs writes.
> >
> > Serialize trigger changes with termios and hold a runtime PM reference
> > while programming FCR, preserving the FIFO contents. Propagate runtime
> > resume errors before changing either the FCR shadow or the hardware.
> >
> > Advertise automatic flow control so CRTSCTS enables MCR.AFCE. The
> > DesignWare termios path selects hardware CTS handling, so the capability
> > must be present for the corresponding hardware control to be enabled.
> >
> > Select the fixed configuration through the platform setup callback.
> > H616 has debug-divisor and RS485 control registers at the offsets used to
> > detect DesignWare hardware RS485 and fractional-divisor support. Avoid
> > those probes and retain the BUSY-safe integer divisor hook and software
> > RS485 handling.
> >
> > Use the existing SKIP_SET_RATE quirk to keep the UART clock enabled during
> > termios changes. Its clock is a gate on the shared APB2 source, rather than
> > an independent baud-rate generator.
>
> ...
>
> > + unsigned int fifo_size;
>
> This is should come from DT (based on the property or compatible),
On some Allwinner SoC's fifo size can come from the FIFO Clock
Control register[0].
>
> ...
>
> > u8 no_int_count;
> > + u8 rxtrig_bytes[UART_FCR_R_TRIG_MAX_STATE];
>
> Why do you need it here? Can it be provided via driver_data?
>
> ...
>
> > +/* The trigger is the masked, unshifted FCR receive trigger field. */
> > +static unsigned int dw8250_sunxi_rxtrig_bytes(struct uart_port *p, unsigned int trigger)
> > +{
> > + switch (trigger) {
> > + case UART_FCR_TRIGGER_1:
> > + return 1;
> > + case UART_FCR_TRIGGER_4:
> > + return p->fifosize / 4;
> > + case UART_FCR_TRIGGER_8:
> > + return p->fifosize / 2;
> > + default:
> > + return p->fifosize - 2;
> > + }
> > +}
>
> You don't need this, just provide a set of numbers directly.
In v5 I added FCC based fifo-size discovery for A523[0] which does
need to compute these values dynamically.
[0] https://lore.kernel.org/all/20261029-submit-h616-uart-fifo-v1-v5-7-53b433aebbf8@gmail.com/
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
More information about the linux-arm-kernel
mailing list