lkml.org 
[lkml]   [2015]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATH RESEND v2 03/10] tty: xuartps: Always enable transmitter in start_tx
    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


    \
     
     \ /
      Last update: 2015-11-20 18:41    [W:5.284 / U:0.380 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site