All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Genoud <richard.genoud@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.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 11:26:26 +0200	[thread overview]
Message-ID: <CACQ1gAhX-WCY3EqxBQ1=MJVsR0G5S21C8KxmO7=x9yW4H6P=xA@mail.gmail.com> (raw)
In-Reply-To: <20161027180229.5faqrvxa2a4pos7i@pengutronix.de>

2016-10-27 20:02 GMT+02:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> 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?
I used that to filter-out the case where CTS is a GPIO.
Now, for the machines that don't use CTS neither as GPIO nor using the
hardware function, it's a whole different story, beyond the scope of this patch.
And like you said, a DT property could be useful to handle this case.
( It's a little bit like if there was an RS232 cable with just TX/RX/GND, but
this will be way harder to detect :) )
Anyway, patches are welcome to handle that, but I don't think it belongs
in this one.

>> +             } else {
>> +                     ...
>>               }
>
> Best regards
> Uwe
>

regards,
Richard

WARNING: multiple messages have this Message-ID (diff)
From: richard.genoud@gmail.com (Richard Genoud)
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:26:26 +0200	[thread overview]
Message-ID: <CACQ1gAhX-WCY3EqxBQ1=MJVsR0G5S21C8KxmO7=x9yW4H6P=xA@mail.gmail.com> (raw)
In-Reply-To: <20161027180229.5faqrvxa2a4pos7i@pengutronix.de>

2016-10-27 20:02 GMT+02:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> 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?
I used that to filter-out the case where CTS is a GPIO.
Now, for the machines that don't use CTS neither as GPIO nor using the
hardware function, it's a whole different story, beyond the scope of this patch.
And like you said, a DT property could be useful to handle this case.
( It's a little bit like if there was an RS232 cable with just TX/RX/GND, but
this will be way harder to detect :) )
Anyway, patches are welcome to handle that, but I don't think it belongs
in this one.

>> +             } else {
>> +                     ...
>>               }
>
> Best regards
> Uwe
>

regards,
Richard

  parent reply	other threads:[~2016-10-28  9:26 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
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 [this message]
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='CACQ1gAhX-WCY3EqxBQ1=MJVsR0G5S21C8KxmO7=x9yW4H6P=xA@mail.gmail.com' \
    --to=richard.genoud@gmail.com \
    --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=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.