All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Richard Genoud <richard.genoud@gmail.com>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"#4 . 4+" <stable@vger.kernel.org>
Subject: Re: [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
Date: Fri, 28 Oct 2016 01:13:31 +0200	[thread overview]
Message-ID: <20161027231331.gngekbg22wfvnolr@piout.net> (raw)
In-Reply-To: <20161027180229.5faqrvxa2a4pos7i@pengutronix.de>

On 27/10/2016 at 20:02:29 +0200, Uwe Kleine-König wrote :
> Hello Richard,
> 
> On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote:
> > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > index fd8aa1f4ba78..168b10cad47b 100644
> > --- a/drivers/tty/serial/atmel_serial.c
> > +++ b/drivers/tty/serial/atmel_serial.c
> > @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> >  		mode |= ATMEL_US_USMODE_RS485;
> >  	} else if (termios->c_cflag & CRTSCTS) {
> >  		/* RS232 with hardware handshake (RTS/CTS) */
> > -		if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> > -			dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> > -			termios->c_cflag &= ~CRTSCTS;
> > -		} else {
> > +		if (atmel_use_fifo(port) &&
> > +		    !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> > +			/*
> > +			 * with ATMEL_US_USMODE_HWHS set, the controller will
> > +			 * be able to drive the RTS pin high/low when the RX
> > +			 * FIFO is above RXFTHRES/below RXFTHRES2.
> > +			 * It will also disable the transmitter when the CTS
> > +			 * pin is high.
> > +			 * This mode is not activated if CTS pin is a GPIO
> > +			 * because in this case, the transmitter is always
> > +			 * disabled (there must be an internal pull-up
> > +			 * responsible for this behaviour).
> > +			 * If the RTS pin is a GPIO, the controller won't be
> > +			 * able to drive it according to the FIFO thresholds,
> > +			 * but it will be handled by the driver.
> > +			 */
> >  			mode |= ATMEL_US_USMODE_HWHS;
> 
> You use
> 
> 	!mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)
> 
> as indicator that the cts mode of the respective pin is used. Is this
> reliable? (It's not if there are machines that don't use CTS, neither as
> gpio nor using the hardware function.) Maybe this needs a dt property to
> indicate that there is no (hw)handshaking available?
> 

We had a call today were we agreed that this should be added in a future
patch. Let's fix the regression for now.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Richard Genoud <richard.genoud@gmail.com>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"#4 . 4+" <stable@vger.kernel.org>
Subject: Re: [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
Date: Fri, 28 Oct 2016 01:13:31 +0200	[thread overview]
Message-ID: <20161027231331.gngekbg22wfvnolr@piout.net> (raw)
In-Reply-To: <20161027180229.5faqrvxa2a4pos7i@pengutronix.de>

On 27/10/2016 at 20:02:29 +0200, Uwe Kleine-K�nig wrote :
> Hello Richard,
> 
> On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote:
> > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > index fd8aa1f4ba78..168b10cad47b 100644
> > --- a/drivers/tty/serial/atmel_serial.c
> > +++ b/drivers/tty/serial/atmel_serial.c
> > @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> >  		mode |= ATMEL_US_USMODE_RS485;
> >  	} else if (termios->c_cflag & CRTSCTS) {
> >  		/* RS232 with hardware handshake (RTS/CTS) */
> > -		if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> > -			dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> > -			termios->c_cflag &= ~CRTSCTS;
> > -		} else {
> > +		if (atmel_use_fifo(port) &&
> > +		    !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> > +			/*
> > +			 * with ATMEL_US_USMODE_HWHS set, the controller will
> > +			 * be able to drive the RTS pin high/low when the RX
> > +			 * FIFO is above RXFTHRES/below RXFTHRES2.
> > +			 * It will also disable the transmitter when the CTS
> > +			 * pin is high.
> > +			 * This mode is not activated if CTS pin is a GPIO
> > +			 * because in this case, the transmitter is always
> > +			 * disabled (there must be an internal pull-up
> > +			 * responsible for this behaviour).
> > +			 * If the RTS pin is a GPIO, the controller won't be
> > +			 * able to drive it according to the FIFO thresholds,
> > +			 * but it will be handled by the driver.
> > +			 */
> >  			mode |= ATMEL_US_USMODE_HWHS;
> 
> You use
> 
> 	!mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)
> 
> as indicator that the cts mode of the respective pin is used. Is this
> reliable? (It's not if there are machines that don't use CTS, neither as
> gpio nor using the hardware function.) Maybe this needs a dt property to
> indicate that there is no (hw)handshaking available?
> 

We had a call today were we agreed that this should be added in a future
patch. Let's fix the regression for now.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: alexandre.belloni@free-electrons.com (Alexandre Belloni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
Date: Fri, 28 Oct 2016 01:13:31 +0200	[thread overview]
Message-ID: <20161027231331.gngekbg22wfvnolr@piout.net> (raw)
In-Reply-To: <20161027180229.5faqrvxa2a4pos7i@pengutronix.de>

On 27/10/2016 at 20:02:29 +0200, Uwe Kleine-K?nig wrote :
> Hello Richard,
> 
> On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote:
> > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > index fd8aa1f4ba78..168b10cad47b 100644
> > --- a/drivers/tty/serial/atmel_serial.c
> > +++ b/drivers/tty/serial/atmel_serial.c
> > @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> >  		mode |= ATMEL_US_USMODE_RS485;
> >  	} else if (termios->c_cflag & CRTSCTS) {
> >  		/* RS232 with hardware handshake (RTS/CTS) */
> > -		if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> > -			dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> > -			termios->c_cflag &= ~CRTSCTS;
> > -		} else {
> > +		if (atmel_use_fifo(port) &&
> > +		    !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> > +			/*
> > +			 * with ATMEL_US_USMODE_HWHS set, the controller will
> > +			 * be able to drive the RTS pin high/low when the RX
> > +			 * FIFO is above RXFTHRES/below RXFTHRES2.
> > +			 * It will also disable the transmitter when the CTS
> > +			 * pin is high.
> > +			 * This mode is not activated if CTS pin is a GPIO
> > +			 * because in this case, the transmitter is always
> > +			 * disabled (there must be an internal pull-up
> > +			 * responsible for this behaviour).
> > +			 * If the RTS pin is a GPIO, the controller won't be
> > +			 * able to drive it according to the FIFO thresholds,
> > +			 * but it will be handled by the driver.
> > +			 */
> >  			mode |= ATMEL_US_USMODE_HWHS;
> 
> You use
> 
> 	!mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)
> 
> as indicator that the cts mode of the respective pin is used. Is this
> reliable? (It's not if there are machines that don't use CTS, neither as
> gpio nor using the hardware function.) Maybe this needs a dt property to
> indicate that there is no (hw)handshaking available?
> 

We had a call today were we agreed that this should be added in a future
patch. Let's fix the regression for now.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2016-10-27 23:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-27 16:04 [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms Richard Genoud
2016-10-27 16:04 ` Richard Genoud
2016-10-27 16:08 ` Nicolas Ferre
2016-10-27 16:08   ` Nicolas Ferre
2016-10-27 16:08   ` Nicolas Ferre
2016-10-27 16:08   ` Nicolas Ferre
2016-10-27 18:02 ` Uwe Kleine-König
2016-10-27 18:02   ` Uwe Kleine-König
2016-10-27 18:02   ` Uwe Kleine-König
2016-10-27 23:13   ` Alexandre Belloni [this message]
2016-10-27 23:13     ` Alexandre Belloni
2016-10-27 23:13     ` Alexandre Belloni
2016-10-28  9:51     ` Uwe Kleine-König
2016-10-28  9:51       ` Uwe Kleine-König
2016-10-28  9:51       ` Uwe Kleine-König
2016-10-28 10:56       ` Richard Genoud
2016-10-28 10:56         ` Richard Genoud
2016-10-28 10:56         ` Richard Genoud
2016-10-28 12:11         ` Greg Kroah-Hartman
2016-10-28 12:11           ` Greg Kroah-Hartman
2016-10-28 12:11           ` Greg Kroah-Hartman
2016-10-28  9:26   ` Richard Genoud
2016-10-28  9:26     ` Richard Genoud
2016-10-28  9:26     ` Richard Genoud
2016-10-28  9:40 ` Cyrille Pitchen
2016-10-28  9:40   ` Cyrille Pitchen
2016-10-28  9:40   ` Cyrille Pitchen
2016-10-28  9:40   ` Cyrille Pitchen

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=20161027231331.gngekbg22wfvnolr@piout.net \
    --to=alexandre.belloni@free-electrons.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=nicolas.ferre@atmel.com \
    --cc=richard.genoud@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.