On Fri, 2015-11-20 at 12:16PM -0500, Peter Hurley wrote:

On 11/20/2015 11:58 AM, S?ren Brinkmann wrote:

quoted

On Fri, 2015-11-20 at 11:30AM -0500, Peter Hurley wrote:

quoted

On 11/20/2015 10:28 AM, S?ren Brinkmann wrote:

quoted

On Fri, 2015-11-20 at 07:13AM -0500, Peter Hurley wrote:

quoted

On 11/19/2015 03:02 PM, Soren Brinkmann wrote:

quoted

start_tx must start transmitting characters. Regardless of the state of
the circular buffer, always enable the transmitter hardware.

Why?

Does cdns_uart_stop_tx() actually stop the transmitter so that
data remains in the transmitter?

Well, I saw my system freezing and the cause seemed to be that the UART
receiver and/or transmitters were disabled while the system was trying
to print. Hence, I started questioning all locations touching the
transmitter/receiver enable. I read the docs in
https://www.kernel.org/doc/Documentation/serial/driver, which simply
says "Start transmitting characters." for start_tx(). Hence, I thought,
this function is probably supposed to just do that and start the
transmitter. I'll test whether this patch can be dropped.

I don't think that patch would fix any freeze problems, but restarting
the transmitter even if the circ buffer is empty may be necessary to
push out remaining data when the port is restarted after being stopped.

IOW, something like

	if (uart_tx_stopped(port))
		return;

	....


	if (uart_circ_empty(&port->state->xmit)
		return;

Thanks! I'll change the patch accordingly.

quoted

Below is a (work-in-progress) serial driver validation test for flow
control handling (it may need some tuning for slow line speeds).
Usual caveats apply. Takes ~40secs @ 115200.

I'll try to get that running on my system.

The test below should pass too, but I know it won't because this xilinx
driver isn't handling x_char at all.

Aside: does this h/w have rts driver/cts receiver?

I would have to look up the details. But, IIRC, the HW has all the
modem/flow control signals. But on our SoCs those signals are only
available when routing the UART through the FPGA part, which makes it a
rather unlikely configuration since most platforms want the UART as a
low level debug port that should not depend on any FPGA bistreams.
Hence, I suspect it might just be a limitation of the driver.

	S?ren