linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Lukas Wunner <lukas@wunner.de>
Cc: gregkh@linuxfoundation.org, jslaby@suse.com,
	andriy.shevchenko@linux.intel.com, matwey.kornilov@gmail.com,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	christoph.muellner@theobroma-systems.com,
	giulio.benetti@micronovasrl.com
Subject: Re: [PATCH v2 4/7] serial: 8250: Handle implementations not having TEMT interrupt using em485
Date: Mon, 18 May 2020 00:01:20 +0200	[thread overview]
Message-ID: <2596761.4mVKVPr5sX@diego> (raw)
In-Reply-To: <20200502134927.6sb7f3na3ff3rpoa@wunner.de>

Hi Lukas,

Am Samstag, 2. Mai 2020, 15:49:27 CEST schrieb Lukas Wunner:
> On Thu, Mar 26, 2020 at 12:14:19AM +0100, Heiko Stuebner wrote:
> > @@ -1529,11 +1535,22 @@ static inline void __stop_tx(struct uart_8250_port *p)
> >  		/*
> >  		 * To provide required timeing and allow FIFO transfer,
> >  		 * __stop_tx_rs485() must be called only when both FIFO and
> > -		 * shift register are empty. It is for device driver to enable
> > -		 * interrupt on TEMT.
> > +		 * shift register are empty. If 8250 port supports it,
> > +		 * it is for device driver to enable interrupt on TEMT.
> > +		 * Otherwise must loop-read until TEMT and THRE flags are set.
> >  		 */
> > -		if ((lsr & BOTH_EMPTY) != BOTH_EMPTY)
> > -			return;
> > +		if (p->capabilities & UART_CAP_TEMT) {
> > +			if ((lsr & BOTH_EMPTY) != BOTH_EMPTY)
> > +				return;
> > +		} else {
> > +			int lsr;
> > +
> > +			if (readx_poll_timeout(__get_lsr, p, lsr,
> > +					(lsr & BOTH_EMPTY) == BOTH_EMPTY,
> > +					0, 10000) < 0)
> > +				pr_warn("%s: timeout waiting for fifos to empty\n",
> > +					p->port.name);
> > +		}
> 
> Do you actually need to check for the timeout?  How could this happen?
> Only if some other part of the driver would disable the transmitter
> I guess, which would be a bug.

Checking for a timeout was strongly suggested in v1 ;-)


> Also, note that __stop_tx() may be called from hardirq context via
> serial8250_tx_chars().  If the baudrate is low, you may spin for a
> fairly long time in IRQ context.  E.g. with 9600 8N1, it takes about
> 1 msec for one char to transmit.

I did play around with different baud rates and data amounts today
and even ran into the timeout with the current 10ms when doing a
"dmesg > /dev/ttyS3" ... combined with the hardirq issue you mentioned
I think I found a slightly better variant to do this ... by catching the first
100us in the interrupt handler and otherwise re-using the existing
stop-timer infrastructure to move this out of the actual __stop_tx function.

I've sent a v3 based on your new series just now ... if you find time
please have a look :-)

Thanks
Heiko



  parent reply	other threads:[~2020-05-17 22:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 23:14 [PATCH RFC v2 0/7] serial: 8250: Add rs485 emulation to 8250_dw Heiko Stuebner
2020-03-25 23:14 ` [PATCH DON'T APPLY v2 1/7] serial: Allow uart_get_rs485_mode() to return errno Heiko Stuebner
2020-03-25 23:14 ` [PATCH DON'T APPLY v2 2/7] dt-bindings: serial: Add binding for rs485 bus termination GPIO Heiko Stuebner
2020-03-25 23:14 ` [PATCH DON'T APPLY v2 3/7] serial: 8250: Support " Heiko Stuebner
2020-03-30 14:51   ` Andy Shevchenko
2020-03-25 23:14 ` [PATCH v2 4/7] serial: 8250: Handle implementations not having TEMT interrupt using em485 Heiko Stuebner
2020-03-25 23:47   ` Giulio Benetti
2020-03-26  0:05     ` Heiko Stübner
2020-03-26  2:02       ` Giulio Benetti
2020-05-17 15:04         ` Heiko Stübner
2020-05-17 17:28           ` Giulio Benetti
2020-03-30 14:52   ` Andy Shevchenko
2020-05-02 13:49   ` Lukas Wunner
2020-05-05 16:38     ` Maarten Brock
2020-05-17 22:01     ` Heiko Stübner [this message]
2020-03-25 23:14 ` [PATCH v2 5/7] dt-bindings: serial: Add binding for rs485 receiver enable GPIO Heiko Stuebner
2020-03-30 14:54   ` Andy Shevchenko
2020-05-02 13:51   ` Lukas Wunner
2020-03-25 23:14 ` [PATCH v2 6/7] serial: 8250: Support separate rs485 rx-enable GPIO Heiko Stuebner
2020-03-30 14:56   ` Andy Shevchenko
2020-05-16 20:14   ` Lukas Wunner
2020-03-25 23:14 ` [PATCH v2 7/7] serial: 8250_dw: add em485 support Heiko Stuebner
2020-05-06 15:25   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2596761.4mVKVPr5sX@diego \
    --to=heiko@sntech.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=christoph.muellner@theobroma-systems.com \
    --cc=giulio.benetti@micronovasrl.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=matwey.kornilov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).