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

On Fri, Oct 28, 2016 at 01:13:31AM +0200, Alexandre Belloni wrote:
> 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.

A machine without CTS (neither gpio nor hw function) used to work fine
before the breaking commit, right? So this case is part of the
regression and needs a fix?

Anyhow, this probably shouldn't stop the commit entering mainline
because there are probably very few such machines (if any).

So:
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

On Fri, Oct 28, 2016 at 01:13:31AM +0200, Alexandre Belloni wrote:
> 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.

A machine without CTS (neither gpio nor hw function) used to work fine
before the breaking commit, right? So this case is part of the
regression and needs a fix?

Anyhow, this probably shouldn't stop the commit entering mainline
because there are probably very few such machines (if any).

So:
Acked-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K�nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

WARNING: multiple messages have this Message-ID (diff)
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
Date: Fri, 28 Oct 2016 11:51:51 +0200	[thread overview]
Message-ID: <20161028095151.f24lhelfknzrpy6c@pengutronix.de> (raw)
In-Reply-To: <20161027231331.gngekbg22wfvnolr@piout.net>

On Fri, Oct 28, 2016 at 01:13:31AM +0200, Alexandre Belloni wrote:
> 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.

A machine without CTS (neither gpio nor hw function) used to work fine
before the breaking commit, right? So this case is part of the
regression and needs a fix?

Anyhow, this probably shouldn't stop the commit entering mainline
because there are probably very few such machines (if any).

So:
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  reply	other threads:[~2016-10-28  9:51 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
2016-10-27 23:13     ` Alexandre Belloni
2016-10-27 23:13     ` Alexandre Belloni
2016-10-28  9:51     ` Uwe Kleine-König [this message]
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=20161028095151.f24lhelfknzrpy6c@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=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 \
    /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.