[PATCH v4 4/5] serial: 8250_dw: configure the Allwinner H616 UART

[Ilpo Järvinen]

On Wed, 28 Oct 2026, Andy Shevchenko 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),
> 
> ...
> 
> >  	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.

That was my first thought as well, but James explained that he wanted to 
reuse this for HW different fifosize which makes sense.

And these formulas are given in DW spec so I suppose we could actually 
infer these for all DW UARTs, not just these ones being added now, using 
the same formulas. (A future work item.)

-- 
 i.