It can be useful to override 8250 mctrl lines with gpios, for rts on
rs485 for example, when rts is not mapped correctly to HW RTS pin.
Enable SERIAL_MCTRL_GPIO by default.
Signed-off-by: Giulio Benetti <[email protected]>
---
drivers/tty/serial/8250/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..c7992b94fece 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -7,6 +7,7 @@ config SERIAL_8250
tristate "8250/16550 and compatible serial support"
depends on !S390
select SERIAL_CORE
+ select SERIAL_MCTRL_GPIO if GPIOLIB
---help---
This selects whether you want to include the driver for the standard
serial ports. The standard answer is Y. People who might say N
--
2.17.0
Sometimes mctrl signals can be connected to pins different from HW ones.
User serial_mctrl_gpio helpers to align HW signals(RTS, CTS, etc.) with
gpios-rts, gpios-cts etc.
Signed-off-by: Giulio Benetti <[email protected]>
---
drivers/tty/serial/8250/8250_core.c | 6 ++++++
drivers/tty/serial/8250/8250_port.c | 18 +++++++++++++++---
include/linux/serial_8250.h | 2 ++
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 9342fc2ee7df..c2bc906ffdf4 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -41,6 +41,8 @@
#include "8250.h"
+#include "../serial_mctrl_gpio.h"
+
/*
* Configuration:
* share_irqs - whether we pass IRQF_SHARED to request_irq(). This option
@@ -1036,6 +1038,10 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
if (up->dl_write)
uart->dl_write = up->dl_write;
+ uart->gpios = mctrl_gpio_init(&up->port, 0);
+ if (IS_ERR(uart->gpios))
+ return PTR_ERR(uart->gpios);
+
if (uart->port.type != PORT_8250_CIR) {
if (serial8250_isa_config != NULL)
serial8250_isa_config(0, &uart->port,
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 95833cbc4338..3004aa3ef4e5 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -40,6 +40,8 @@
#include "8250.h"
+#include "../serial_mctrl_gpio.h"
+
/*
* These are definitions for the Exar XR17V35X and XR17(C|D)15X
*/
@@ -567,6 +569,8 @@ static inline void serial8250_em485_rts_after_send(struct uart_8250_port *p)
else
mcr &= ~UART_MCR_RTS;
serial8250_out_MCR(p, mcr);
+
+ mctrl_gpio_set(p->gpios, p->port.mctrl);
}
static enum hrtimer_restart serial8250_em485_handle_start_tx(struct hrtimer *t);
@@ -1591,12 +1595,17 @@ static inline void start_tx_rs485(struct uart_port *port)
mcr = serial8250_in_MCR(up);
if (!!(up->port.rs485.flags & SER_RS485_RTS_ON_SEND) !=
!!(mcr & UART_MCR_RTS)) {
- if (up->port.rs485.flags & SER_RS485_RTS_ON_SEND)
+ if (up->port.rs485.flags & SER_RS485_RTS_ON_SEND) {
mcr |= UART_MCR_RTS;
- else
+ up->port.mctrl |= TIOCM_RTS;
+ } else {
mcr &= ~UART_MCR_RTS;
+ up->port.mctrl &= ~TIOCM_RTS;
+ }
serial8250_out_MCR(up, mcr);
+ mctrl_gpio_set(up->gpios, up->port.mctrl);
+
if (up->port.rs485.delay_rts_before_send > 0) {
em485->active_timer = &em485->start_tx_timer;
start_hrtimer_ms(&em485->start_tx_timer,
@@ -1957,7 +1966,8 @@ unsigned int serial8250_do_get_mctrl(struct uart_port *port)
ret |= TIOCM_DSR;
if (status & UART_MSR_CTS)
ret |= TIOCM_CTS;
- return ret;
+
+ return mctrl_gpio_get(up->gpios, &ret);
}
EXPORT_SYMBOL_GPL(serial8250_do_get_mctrl);
@@ -1987,6 +1997,8 @@ void serial8250_do_set_mctrl(struct uart_port *port, unsigned int mctrl)
mcr = (mcr & up->mcr_mask) | up->mcr_force | up->mcr;
serial8250_out_MCR(up, mcr);
+
+ mctrl_gpio_set(up->gpios, mctrl);
}
EXPORT_SYMBOL_GPL(serial8250_do_set_mctrl);
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index a27ef5f56431..7872f11d4b04 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -134,6 +134,8 @@ struct uart_8250_port {
void (*dl_write)(struct uart_8250_port *, int);
struct uart_8250_em485 *em485;
+
+ struct mctrl_gpios *gpios;
};
static inline struct uart_8250_port *up_to_u8250p(struct uart_port *up)
--
2.17.0
On Fri, 2018-06-01 at 16:11 +0200, Giulio Benetti wrote:
> It can be useful to override 8250 mctrl lines with gpios, for rts on
> rs485 for example, when rts is not mapped correctly to HW RTS pin.
>
> Enable SERIAL_MCTRL_GPIO by default.
>
Unfortunately NAK, see
commit 5db4f7f80d165fc9725f356e99feec409e446baa
Author: Andy Shevchenko <[email protected]>
Date: Tue Aug 16 15:06:54 2016 +0300
Revert "tty/serial/8250: use mctrl_gpio helpers"
for the details.
I would love to see a solution that will satisfy everyone, though I have
only means to test proposals for now.
> Signed-off-by: Giulio Benetti <[email protected]>
> ---
> drivers/tty/serial/8250/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/serial/8250/Kconfig
> b/drivers/tty/serial/8250/Kconfig
> index f005eaf8bc57..c7992b94fece 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -7,6 +7,7 @@ config SERIAL_8250
> tristate "8250/16550 and compatible serial support"
> depends on !S390
> select SERIAL_CORE
> + select SERIAL_MCTRL_GPIO if GPIOLIB
> ---help---
> This selects whether you want to include the driver for the
> standard
> serial ports. The standard answer is Y. People who might
> say N
--
Andy Shevchenko <[email protected]>
Intel Finland Oy
Il 04/06/2018 13:49, Andy Shevchenko ha scritto:
> On Fri, 2018-06-01 at 16:11 +0200, Giulio Benetti wrote:
>> It can be useful to override 8250 mctrl lines with gpios, for rts on
>> rs485 for example, when rts is not mapped correctly to HW RTS pin.
>>
>> Enable SERIAL_MCTRL_GPIO by default.
>>
>
> Unfortunately NAK, see
>
> commit 5db4f7f80d165fc9725f356e99feec409e446baa
> Author: Andy Shevchenko <[email protected]>
> Date: Tue Aug 16 15:06:54 2016 +0300
>
> Revert "tty/serial/8250: use mctrl_gpio helpers"
>
> for the details.
>
> I would love to see a solution that will satisfy everyone, though I have
> only means to test proposals for now.
Thanks for pointing me that.
I would try to solve serial breakage on intel with already extisting
patches dropping this one.
I'm going to try.
I can't understand if it's enough using qemu x86 to reproduce the bug.
If so I'm going to debug and check what makes driver to fail.
Do you think it makes sense? Would it be accepted after bug fixing?
Thanks
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
>
>> Signed-off-by: Giulio Benetti <[email protected]>
>> ---
>> drivers/tty/serial/8250/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/tty/serial/8250/Kconfig
>> b/drivers/tty/serial/8250/Kconfig
>> index f005eaf8bc57..c7992b94fece 100644
>> --- a/drivers/tty/serial/8250/Kconfig
>> +++ b/drivers/tty/serial/8250/Kconfig
>> @@ -7,6 +7,7 @@ config SERIAL_8250
>> tristate "8250/16550 and compatible serial support"
>> depends on !S390
>> select SERIAL_CORE
>> + select SERIAL_MCTRL_GPIO if GPIOLIB
>> ---help---
>> This selects whether you want to include the driver for the
>> standard
>> serial ports. The standard answer is Y. People who might
>> say N
>
On Mon, 2018-06-04 at 20:57 +0200, Giulio Benetti wrote:
> Il 04/06/2018 13:49, Andy Shevchenko ha scritto:
> > On Fri, 2018-06-01 at 16:11 +0200, Giulio Benetti wrote:
> > > It can be useful to override 8250 mctrl lines with gpios, for rts
> > > on
> > > rs485 for example, when rts is not mapped correctly to HW RTS pin.
> > >
> > > Enable SERIAL_MCTRL_GPIO by default.
> > >
> >
> > Unfortunately NAK, see
> >
> > commit 5db4f7f80d165fc9725f356e99feec409e446baa
> > Author: Andy Shevchenko <[email protected]>
> > Date: Tue Aug 16 15:06:54 2016 +0300
> >
> > Revert "tty/serial/8250: use mctrl_gpio helpers"
> >
> > for the details.
> >
> > I would love to see a solution that will satisfy everyone, though I
> > have
> > only means to test proposals for now.
>
> Thanks for pointing me that.
> I would try to solve serial breakage on intel with already extisting
> patches dropping this one.
> I'm going to try.
>
> I can't understand if it's enough using qemu x86 to reproduce the bug.
> If so I'm going to debug and check what makes driver to fail.
You need to provide an ACPI table with UART contains GpioInt() or
GpioIo() resource in it.
Where GPIO number is a number of pin related to UART's RxD.
> Do you think it makes sense? Would it be accepted after bug fixing?
I can test on our hardware. Can't say about the rest, though.
--
Andy Shevchenko <[email protected]>
Intel Finland Oy