On Fri, 2015-11-20 at 12:16PM -0500, Peter Hurley wrote: > On 11/20/2015 11:58 AM, Sören Brinkmann wrote: > > On Fri, 2015-11-20 at 11:30AM -0500, Peter Hurley wrote: > >> On 11/20/2015 10:28 AM, Sören Brinkmann wrote: > >>> On Fri, 2015-11-20 at 07:13AM -0500, Peter Hurley wrote: > >>>> On 11/19/2015 03:02 PM, Soren Brinkmann wrote: > >>>>> 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. > > > >> > >> > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
