* [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it @ 2019-05-24 9:48 Stefan Roese 2019-05-24 9:48 ` [PATCH 2/2 v2] tty/serial/8250: use mctrl_gpio helpers Stefan Roese 2019-05-24 10:20 ` [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Mika Westerberg 0 siblings, 2 replies; 8+ messages in thread From: Stefan Roese @ 2019-05-24 9:48 UTC (permalink / raw) To: linux-serial Cc: linux-kernel, Mika Westerberg, Andy Shevchenko, Yegor Yefremov, Greg Kroah-Hartman, Giulio Benetti This patch adds a check for the GPIOs property existence, before the GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio support is added (2nd patch in this patch series) on x86 platforms using ACPI. Here Mika's comments from 2016-08-09: " I noticed that with v4.8-rc1 serial console of some of our Broxton systems does not work properly anymore. I'm able to see output but input does not work. I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 ("tty/serial/8250: use mctrl_gpio helpers"). The reason why it fails is that in ACPI we do not have names for GPIOs (except when _DSD is used) so we use the "idx" to index into _CRS GPIO resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The UART device in Broxton has following (simplified) ACPI description: Device (URT4) { ... Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer) { 0x003A } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer) { 0x003D } }) In this case it finds the first GPIO (0x003A which happens to be RX pin for that UART), turns it into GPIO which then breaks input for the UART device. This also breaks systems with bluetooth connected to UART (those typically have some GPIOs in their _CRS). Any ideas how to fix this? We cannot just drop the _CRS index lookup fallback because that would break many existing machines out there so maybe we can limit this to only DT enabled machines. Or alternatively probe if the property first exists before trying to acquire the GPIOs (using device_property_present()). " This patch implements the fix suggested by Mika in his statement above. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Giulio Benetti <giulio.benetti@micronovasrl.com> --- v2: - Include the problem description and analysis from Mika into the commit text, as suggested by Greg. drivers/tty/serial/serial_mctrl_gpio.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c index 39ed56214cd3..cac50b20a119 100644 --- a/drivers/tty/serial/serial_mctrl_gpio.c +++ b/drivers/tty/serial/serial_mctrl_gpio.c @@ -116,6 +116,13 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx) for (i = 0; i < UART_GPIO_MAX; i++) { enum gpiod_flags flags; + char *gpio_str; + + /* Check if GPIO property exists and continue if not */ + gpio_str = kasprintf(GFP_KERNEL, "%s-gpios", + mctrl_gpios_desc[i].name); + if (!device_property_present(dev, gpio_str)) + continue; if (mctrl_gpios_desc[i].dir_out) flags = GPIOD_OUT_LOW; -- 2.21.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 2/2 v2] tty/serial/8250: use mctrl_gpio helpers 2019-05-24 9:48 [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Stefan Roese @ 2019-05-24 9:48 ` Stefan Roese 2019-05-24 10:20 ` [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Mika Westerberg 1 sibling, 0 replies; 8+ messages in thread From: Stefan Roese @ 2019-05-24 9:48 UTC (permalink / raw) To: linux-serial Cc: linux-kernel, Yegor Yefremov, Mika Westerberg, Andy Shevchenko, Giulio Benetti, Greg Kroah-Hartman From: Yegor Yefremov <yegorslists@googlemail.com> This patch permits the usage for GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI signals. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Stefan Roese <sr@denx.de> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Giulio Benetti <giulio.benetti@micronovasrl.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- v2: - No change Please note that this patch was already applied before [1]. And later reverted [2] because it introduced problems on some x86 based boards (ACPI GPIO related). Here a detailed description of the issue at that time: https://lkml.org/lkml/2016/8/9/357 http://www.spinics.net/lists/linux-serial/msg23071.html This is a re-send of the original patch that was applied at that time. With patch 1/2 from this series this issue should be fixed now (please note that I can't test it on such an x86 platform causing these problems). Andy (or Mika), perhaps it would be possible for you to test this patch again, now with patch 1/2 of this series applied as well? That would be really helpful. Thanks, Stefan [1] 4ef03d328769 ("tty/serial/8250: use mctrl_gpio helpers") [2] 5db4f7f80d16 ("Revert "tty/serial/8250: use mctrl_gpio helpers"") .../devicetree/bindings/serial/8250.txt | 19 ++++++++++ drivers/tty/serial/8250/8250.h | 35 ++++++++++++++++++- drivers/tty/serial/8250/8250_core.c | 9 +++++ drivers/tty/serial/8250/8250_omap.c | 31 +++++++++------- drivers/tty/serial/8250/8250_port.c | 7 +++- drivers/tty/serial/8250/Kconfig | 1 + include/linux/serial_8250.h | 1 + 7 files changed, 88 insertions(+), 15 deletions(-) diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt index 3cba12f855b7..20d351f268ef 100644 --- a/Documentation/devicetree/bindings/serial/8250.txt +++ b/Documentation/devicetree/bindings/serial/8250.txt @@ -53,6 +53,9 @@ Optional properties: programmable TX FIFO thresholds. - resets : phandle + reset specifier pairs - overrun-throttle-ms : how long to pause uart rx when input overrun is encountered. +- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD + line respectively. It will use specified GPIO instead of the peripheral + function pin for the UART feature. If unsure, don't specify this property. Note: * fsl,ns16550: @@ -74,3 +77,19 @@ Example: interrupts = <10>; reg-shift = <2>; }; + +Example for OMAP UART using GPIO-based modem control signals: + + uart4: serial@49042000 { + compatible = "ti,omap3-uart"; + reg = <0x49042000 0x400>; + interrupts = <80>; + ti,hwmods = "uart4"; + clock-frequency = <48000000>; + cts-gpios = <&gpio3 5 GPIO_ACTIVE_LOW>; + rts-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>; + dtr-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; + dsr-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>; + dcd-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; + rng-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>; + }; diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h index ebfb0bd5bef5..e59625bdb007 100644 --- a/drivers/tty/serial/8250/8250.h +++ b/drivers/tty/serial/8250/8250.h @@ -11,6 +11,8 @@ #include <linux/serial_reg.h> #include <linux/dmaengine.h> +#include "../serial_mctrl_gpio.h" + struct uart_8250_dma { int (*tx_dma)(struct uart_8250_port *p); int (*rx_dma)(struct uart_8250_port *p); @@ -141,12 +143,43 @@ void serial8250_em485_destroy(struct uart_8250_port *p); static inline void serial8250_out_MCR(struct uart_8250_port *up, int value) { + int mctrl_gpio = 0; + serial_out(up, UART_MCR, value); + + if (value & UART_MCR_RTS) + mctrl_gpio |= TIOCM_RTS; + if (value & UART_MCR_DTR) + mctrl_gpio |= TIOCM_DTR; + + mctrl_gpio_set(up->gpios, mctrl_gpio); } static inline int serial8250_in_MCR(struct uart_8250_port *up) { - return serial_in(up, UART_MCR); + int mctrl, mctrl_gpio = 0; + + mctrl = serial_in(up, UART_MCR); + + /* save current MCR values */ + if (mctrl & UART_MCR_RTS) + mctrl_gpio |= TIOCM_RTS; + if (mctrl & UART_MCR_DTR) + mctrl_gpio |= TIOCM_DTR; + + mctrl_gpio = mctrl_gpio_get_outputs(up->gpios, &mctrl_gpio); + + if (mctrl_gpio & TIOCM_RTS) + mctrl |= UART_MCR_RTS; + else + mctrl &= ~UART_MCR_RTS; + + if (mctrl_gpio & TIOCM_DTR) + mctrl |= UART_MCR_DTR; + else + mctrl &= ~UART_MCR_DTR; + + return mctrl; } #if defined(__alpha__) && !defined(CONFIG_PCI) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index e441221e04b9..ec0c5448c192 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -982,6 +982,8 @@ int serial8250_register_8250_port(struct uart_8250_port *up) uart = serial8250_find_match_or_unused(&up->port); if (uart && uart->port.type != PORT_8250_CIR) { + struct mctrl_gpios *gpios; + if (uart->port.dev) uart_remove_one_port(&serial8250_reg, &uart->port); @@ -1016,6 +1018,13 @@ int serial8250_register_8250_port(struct uart_8250_port *up) if (up->port.flags & UPF_FIXED_TYPE) uart->port.type = up->port.type; + gpios = mctrl_gpio_init(&uart->port, 0); + if (IS_ERR(gpios)) { + if (PTR_ERR(gpios) != -ENOSYS) + return PTR_ERR(gpios); + } else + uart->gpios = gpios; + serial8250_set_defaults(uart); /* Possibly override default I/O functions. */ diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c index 0a8316632d75..562ac73d9f2f 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -141,18 +141,21 @@ static void omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl) serial8250_do_set_mctrl(port, mctrl); - /* - * Turn off autoRTS if RTS is lowered and restore autoRTS setting - * if RTS is raised - */ - lcr = serial_in(up, UART_LCR); - serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); - if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS)) - priv->efr |= UART_EFR_RTS; - else - priv->efr &= ~UART_EFR_RTS; - serial_out(up, UART_EFR, priv->efr); - serial_out(up, UART_LCR, lcr); + if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(up->gpios, + UART_GPIO_RTS))) { + /* + * Turn off autoRTS if RTS is lowered and restore autoRTS + * setting if RTS is raised + */ + lcr = serial_in(up, UART_LCR); + serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); + if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS)) + priv->efr |= UART_EFR_RTS; + else + priv->efr &= ~UART_EFR_RTS; + serial_out(up, UART_EFR, priv->efr); + serial_out(up, UART_LCR, lcr); + } } /* @@ -453,7 +456,9 @@ static void omap_8250_set_termios(struct uart_port *port, priv->efr = 0; up->port.status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS | UPSTAT_AUTOXOFF); - if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW) { + if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW + && IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(up->gpios, + UART_GPIO_RTS))) { /* Enable AUTOCTS (autoRTS is enabled when RTS is raised) */ up->port.status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS; priv->efr |= UART_EFR_CTS; diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 2304a84eee3b..220a78287d88 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -1662,6 +1662,8 @@ static void serial8250_disable_ms(struct uart_port *port) if (up->bugs & UART_BUG_NOMSR) return; + mctrl_gpio_disable_ms(up->gpios); + up->ier &= ~UART_IER_MSI; serial_port_out(port, UART_IER, up->ier); } @@ -1674,6 +1676,8 @@ static void serial8250_enable_ms(struct uart_port *port) if (up->bugs & UART_BUG_NOMSR) return; + mctrl_gpio_enable_ms(up->gpios); + up->ier |= UART_IER_MSI; serial8250_rpm_get(up); @@ -1959,7 +1963,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); diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig index 296115f6a4d8..509f6a3bb9ff 100644 --- a/drivers/tty/serial/8250/Kconfig +++ b/drivers/tty/serial/8250/Kconfig @@ -8,6 +8,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 diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h index 5a655ba8d273..14cd763baf78 100644 --- a/include/linux/serial_8250.h +++ b/include/linux/serial_8250.h @@ -114,6 +114,7 @@ struct uart_8250_port { * if no_console_suspend */ unsigned char probe; + struct mctrl_gpios *gpios; #define UART_PROBE_RSA (1 << 0) /* -- 2.21.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it 2019-05-24 9:48 [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Stefan Roese 2019-05-24 9:48 ` [PATCH 2/2 v2] tty/serial/8250: use mctrl_gpio helpers Stefan Roese @ 2019-05-24 10:20 ` Mika Westerberg 2019-05-24 11:11 ` Andy Shevchenko 1 sibling, 1 reply; 8+ messages in thread From: Mika Westerberg @ 2019-05-24 10:20 UTC (permalink / raw) To: Stefan Roese Cc: linux-serial, linux-kernel, Andy Shevchenko, Yegor Yefremov, Greg Kroah-Hartman, Giulio Benetti On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote: > This patch adds a check for the GPIOs property existence, before the > GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio > support is added (2nd patch in this patch series) on x86 platforms using > ACPI. > > Here Mika's comments from 2016-08-09: > > " > I noticed that with v4.8-rc1 serial console of some of our Broxton > systems does not work properly anymore. I'm able to see output but input > does not work. > > I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 > ("tty/serial/8250: use mctrl_gpio helpers"). > > The reason why it fails is that in ACPI we do not have names for GPIOs > (except when _DSD is used) so we use the "idx" to index into _CRS GPIO > resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs > calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The > UART device in Broxton has following (simplified) ACPI description: > > Device (URT4) > { > ... > Name (_CRS, ResourceTemplate () { > GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, > "\\_SB.GPO0", 0x00, ResourceConsumer) > { > 0x003A > } > GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, > "\\_SB.GPO0", 0x00, ResourceConsumer) > { > 0x003D > } > }) > > In this case it finds the first GPIO (0x003A which happens to be RX pin > for that UART), turns it into GPIO which then breaks input for the UART > device. This also breaks systems with bluetooth connected to UART (those > typically have some GPIOs in their _CRS). > > Any ideas how to fix this? > > We cannot just drop the _CRS index lookup fallback because that would > break many existing machines out there so maybe we can limit this to > only DT enabled machines. Or alternatively probe if the property first > exists before trying to acquire the GPIOs (using > device_property_present()). > " > > This patch implements the fix suggested by Mika in his statement above. > > Signed-off-by: Stefan Roese <sr@denx.de> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it 2019-05-24 10:20 ` [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Mika Westerberg @ 2019-05-24 11:11 ` Andy Shevchenko 2019-05-24 11:29 ` Stefan Roese 0 siblings, 1 reply; 8+ messages in thread From: Andy Shevchenko @ 2019-05-24 11:11 UTC (permalink / raw) To: Mika Westerberg Cc: Stefan Roese, open list:SERIAL DRIVERS, Linux Kernel Mailing List, Andy Shevchenko, Yegor Yefremov, Greg Kroah-Hartman, Giulio Benetti On Fri, May 24, 2019 at 1:21 PM Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > > On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote: > > This patch adds a check for the GPIOs property existence, before the > > GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio > > support is added (2nd patch in this patch series) on x86 platforms using > > ACPI. > > > > Here Mika's comments from 2016-08-09: > > > > " > > I noticed that with v4.8-rc1 serial console of some of our Broxton > > systems does not work properly anymore. I'm able to see output but input > > does not work. > > > > I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 > > ("tty/serial/8250: use mctrl_gpio helpers"). > > > > The reason why it fails is that in ACPI we do not have names for GPIOs > > (except when _DSD is used) so we use the "idx" to index into _CRS GPIO > > resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs > > calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The > > UART device in Broxton has following (simplified) ACPI description: > > > > Device (URT4) > > { > > ... > > Name (_CRS, ResourceTemplate () { > > GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, > > "\\_SB.GPO0", 0x00, ResourceConsumer) > > { > > 0x003A > > } > > GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, > > "\\_SB.GPO0", 0x00, ResourceConsumer) > > { > > 0x003D > > } > > }) > > > > In this case it finds the first GPIO (0x003A which happens to be RX pin > > for that UART), turns it into GPIO which then breaks input for the UART > > device. This also breaks systems with bluetooth connected to UART (those > > typically have some GPIOs in their _CRS). > > > > Any ideas how to fix this? > > > > We cannot just drop the _CRS index lookup fallback because that would > > break many existing machines out there so maybe we can limit this to > > only DT enabled machines. Or alternatively probe if the property first > > exists before trying to acquire the GPIOs (using > > device_property_present()). > > " > > > > This patch implements the fix suggested by Mika in his statement above. > > We have a board where ASL provides _DSD for CTS and RxD pins. I'm afraid this won't work on it. Basically we need to understand the use of the GPIOs in UART. In our case it's an out-of-band wake up source for UART. Simply requiring GPIOs to be present is not enough. Perhaps property like 'modem-control-gpio-in-use' (this seems a bad name, given for sake of example). > > Signed-off-by: Stefan Roese <sr@denx.de> > > Cc: Mika Westerberg <mika.westerberg@linux.intel.com> > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it 2019-05-24 11:11 ` Andy Shevchenko @ 2019-05-24 11:29 ` Stefan Roese 2019-05-24 12:09 ` Giulio Benetti 2019-05-24 13:46 ` Andy Shevchenko 0 siblings, 2 replies; 8+ messages in thread From: Stefan Roese @ 2019-05-24 11:29 UTC (permalink / raw) To: Andy Shevchenko, Mika Westerberg Cc: open list:SERIAL DRIVERS, Linux Kernel Mailing List, Andy Shevchenko, Yegor Yefremov, Greg Kroah-Hartman, Giulio Benetti On 24.05.19 13:11, Andy Shevchenko wrote: > On Fri, May 24, 2019 at 1:21 PM Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: >> >> On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote: >>> This patch adds a check for the GPIOs property existence, before the >>> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio >>> support is added (2nd patch in this patch series) on x86 platforms using >>> ACPI. >>> >>> Here Mika's comments from 2016-08-09: >>> >>> " >>> I noticed that with v4.8-rc1 serial console of some of our Broxton >>> systems does not work properly anymore. I'm able to see output but input >>> does not work. >>> >>> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 >>> ("tty/serial/8250: use mctrl_gpio helpers"). >>> >>> The reason why it fails is that in ACPI we do not have names for GPIOs >>> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO >>> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs >>> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The >>> UART device in Broxton has following (simplified) ACPI description: >>> >>> Device (URT4) >>> { >>> ... >>> Name (_CRS, ResourceTemplate () { >>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, >>> "\\_SB.GPO0", 0x00, ResourceConsumer) >>> { >>> 0x003A >>> } >>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, >>> "\\_SB.GPO0", 0x00, ResourceConsumer) >>> { >>> 0x003D >>> } >>> }) >>> >>> In this case it finds the first GPIO (0x003A which happens to be RX pin >>> for that UART), turns it into GPIO which then breaks input for the UART >>> device. This also breaks systems with bluetooth connected to UART (those >>> typically have some GPIOs in their _CRS). >>> >>> Any ideas how to fix this? >>> >>> We cannot just drop the _CRS index lookup fallback because that would >>> break many existing machines out there so maybe we can limit this to >>> only DT enabled machines. Or alternatively probe if the property first >>> exists before trying to acquire the GPIOs (using >>> device_property_present()). >>> " >>> >>> This patch implements the fix suggested by Mika in his statement above. >>> > > We have a board where ASL provides _DSD for CTS and RxD pins. > I'm afraid this won't work on it. With "won't work" you mean, that the GPIO can't be used for modem control in this case in the current implementation (with this patchset)? Or do you mean, that the breakage (input does not work on Broxton systems) will not be solved by this patch? If its the former, then I think that solving this issue is something for a new patch, to support modem-control on such platforms as well (if needed). Please note that this patch is not trying to get modem-control working on such ACPI based systems. Its targeted for device-tree enabled platforms, using the 8250 serial driver, here specifically a MIPS MT7688 based board. And just wants to fix the latter issue mentioned above so that the 8250 modem-control support can be accepted in mainline. > Basically we need to understand the use of the GPIOs in UART. In our > case it's an out-of-band wake up source for UART. > Simply requiring GPIOs to be present is not enough. > > Perhaps property like 'modem-control-gpio-in-use' (this seems a bad > name, given for sake of example). Thanks, Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it 2019-05-24 11:29 ` Stefan Roese @ 2019-05-24 12:09 ` Giulio Benetti 2019-05-24 13:46 ` Andy Shevchenko 1 sibling, 0 replies; 8+ messages in thread From: Giulio Benetti @ 2019-05-24 12:09 UTC (permalink / raw) To: Stefan Roese, Andy Shevchenko, Mika Westerberg Cc: open list:SERIAL DRIVERS, Linux Kernel Mailing List, Andy Shevchenko, Yegor Yefremov, Greg Kroah-Hartman Hello Stefan, Il 24/05/2019 13:29, Stefan Roese ha scritto: > On 24.05.19 13:11, Andy Shevchenko wrote: >> On Fri, May 24, 2019 at 1:21 PM Mika Westerberg >> <mika.westerberg@linux.intel.com> wrote: >>> >>> On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote: >>>> This patch adds a check for the GPIOs property existence, before the >>>> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio >>>> support is added (2nd patch in this patch series) on x86 platforms using >>>> ACPI. >>>> >>>> Here Mika's comments from 2016-08-09: >>>> >>>> " >>>> I noticed that with v4.8-rc1 serial console of some of our Broxton >>>> systems does not work properly anymore. I'm able to see output but input >>>> does not work. >>>> >>>> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 >>>> ("tty/serial/8250: use mctrl_gpio helpers"). >>>> >>>> The reason why it fails is that in ACPI we do not have names for GPIOs >>>> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO >>>> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs >>>> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The >>>> UART device in Broxton has following (simplified) ACPI description: >>>> >>>> Device (URT4) >>>> { >>>> ... >>>> Name (_CRS, ResourceTemplate () { >>>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, >>>> "\\_SB.GPO0", 0x00, ResourceConsumer) >>>> { >>>> 0x003A >>>> } >>>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, >>>> "\\_SB.GPO0", 0x00, ResourceConsumer) >>>> { >>>> 0x003D >>>> } >>>> }) >>>> >>>> In this case it finds the first GPIO (0x003A which happens to be RX pin >>>> for that UART), turns it into GPIO which then breaks input for the UART >>>> device. This also breaks systems with bluetooth connected to UART (those >>>> typically have some GPIOs in their _CRS). >>>> >>>> Any ideas how to fix this? >>>> >>>> We cannot just drop the _CRS index lookup fallback because that would >>>> break many existing machines out there so maybe we can limit this to >>>> only DT enabled machines. Or alternatively probe if the property first >>>> exists before trying to acquire the GPIOs (using >>>> device_property_present()). >>>> " >>>> >>>> This patch implements the fix suggested by Mika in his statement above. >>>> >> >> We have a board where ASL provides _DSD for CTS and RxD pins. >> I'm afraid this won't work on it. > > With "won't work" you mean, that the GPIO can't be used for modem > control in this case in the current implementation (with this > patchset)? Or do you mean, that the breakage (input does not work > on Broxton systems) will not be solved by this patch? > > If its the former, then I think that solving this issue is something > for a new patch, to support modem-control on such platforms as well > (if needed). > > Please note that this patch is not trying to get modem-control working > on such ACPI based systems. Its targeted for device-tree enabled > platforms, using the 8250 serial driver, here specifically a MIPS > MT7688 based board. And just wants to fix the latter issue mentioned > above so that the 8250 modem-control support can be accepted in > mainline. Take a look here: https://lkml.org/lkml/2018/6/5/253 It's about waking up 8250 UART. As I remember that is the problem. I wanted to try to fix it but had no time. What it broken as I remember is the capability to wake up linux on uart RX. Hope I've understood right at that time. 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 >> Basically we need to understand the use of the GPIOs in UART. In our >> case it's an out-of-band wake up source for UART. >> Simply requiring GPIOs to be present is not enough. >> >> Perhaps property like 'modem-control-gpio-in-use' (this seems a bad >> name, given for sake of example). > > Thanks, > Stefan > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it 2019-05-24 11:29 ` Stefan Roese 2019-05-24 12:09 ` Giulio Benetti @ 2019-05-24 13:46 ` Andy Shevchenko 2019-05-27 7:05 ` Stefan Roese 1 sibling, 1 reply; 8+ messages in thread From: Andy Shevchenko @ 2019-05-24 13:46 UTC (permalink / raw) To: Stefan Roese Cc: Mika Westerberg, open list:SERIAL DRIVERS, Linux Kernel Mailing List, Yegor Yefremov, Greg Kroah-Hartman, Giulio Benetti On Fri, May 24, 2019 at 01:29:34PM +0200, Stefan Roese wrote: > On 24.05.19 13:11, Andy Shevchenko wrote: > > On Fri, May 24, 2019 at 1:21 PM Mika Westerberg > > <mika.westerberg@linux.intel.com> wrote: > > > > > > On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote: > > > > This patch adds a check for the GPIOs property existence, before the > > > > GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio > > > > support is added (2nd patch in this patch series) on x86 platforms using > > > > ACPI. > > > > > > > > Here Mika's comments from 2016-08-09: > > > > > > > > " > > > > I noticed that with v4.8-rc1 serial console of some of our Broxton > > > > systems does not work properly anymore. I'm able to see output but input > > > > does not work. > > > > > > > > I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 > > > > ("tty/serial/8250: use mctrl_gpio helpers"). > > > > > > > > The reason why it fails is that in ACPI we do not have names for GPIOs > > > > (except when _DSD is used) so we use the "idx" to index into _CRS GPIO > > > > resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs > > > > calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The > > > > UART device in Broxton has following (simplified) ACPI description: > > > > > > > > Device (URT4) > > > > { > > > > ... > > > > Name (_CRS, ResourceTemplate () { > > > > GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, > > > > "\\_SB.GPO0", 0x00, ResourceConsumer) > > > > { > > > > 0x003A > > > > } > > > > GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, > > > > "\\_SB.GPO0", 0x00, ResourceConsumer) > > > > { > > > > 0x003D > > > > } > > > > }) > > > > > > > > In this case it finds the first GPIO (0x003A which happens to be RX pin > > > > for that UART), turns it into GPIO which then breaks input for the UART > > > > device. This also breaks systems with bluetooth connected to UART (those > > > > typically have some GPIOs in their _CRS). > > > > > > > > Any ideas how to fix this? > > > > > > > > We cannot just drop the _CRS index lookup fallback because that would > > > > break many existing machines out there so maybe we can limit this to > > > > only DT enabled machines. Or alternatively probe if the property first > > > > exists before trying to acquire the GPIOs (using > > > > device_property_present()). > > > > " > > > > > > > > This patch implements the fix suggested by Mika in his statement above. > > > > > > > > We have a board where ASL provides _DSD for CTS and RxD pins. > > I'm afraid this won't work on it. > > With "won't work" you mean, that the GPIO can't be used for modem > control in this case in the current implementation (with this > patchset)? Or do you mean, that the breakage (input does not work > on Broxton systems) will not be solved by this patch? It will solve RxD case, due to mctrl doesn't count RxD as a "control" line. Though we have CTS pin defined for the same purpose, which means the hardware flow control won't work on a subset of Broxton boards. > If its the former, then I think that solving this issue is something > for a new patch, to support modem-control on such platforms as well > (if needed). > Please note that this patch is not trying to get modem-control working > on such ACPI based systems. I understand that. At the same time it should not break existing systems. > Its targeted for device-tree enabled > platforms, using the 8250 serial driver, here specifically a MIPS > MT7688 based board. And just wants to fix the latter issue mentioned > above so that the 8250 modem-control support can be accepted in > mainline. As I said already we have to distinguish *the purpose* of these GPIOs. (like CTS). Can we apply this if and only if the device has no ACPI companion device? In this case DT will work as you expect and ACPI won't be broken. > > Basically we need to understand the use of the GPIOs in UART. In our > > case it's an out-of-band wake up source for UART. > > Simply requiring GPIOs to be present is not enough. > > > > Perhaps property like 'modem-control-gpio-in-use' (this seems a bad > > name, given for sake of example). -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it 2019-05-24 13:46 ` Andy Shevchenko @ 2019-05-27 7:05 ` Stefan Roese 0 siblings, 0 replies; 8+ messages in thread From: Stefan Roese @ 2019-05-27 7:05 UTC (permalink / raw) To: Andy Shevchenko Cc: Mika Westerberg, open list:SERIAL DRIVERS, Linux Kernel Mailing List, Yegor Yefremov, Greg Kroah-Hartman, Giulio Benetti On 24.05.19 15:46, Andy Shevchenko wrote: > On Fri, May 24, 2019 at 01:29:34PM +0200, Stefan Roese wrote: >> On 24.05.19 13:11, Andy Shevchenko wrote: >>> On Fri, May 24, 2019 at 1:21 PM Mika Westerberg >>> <mika.westerberg@linux.intel.com> wrote: >>>> >>>> On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote: >>>>> This patch adds a check for the GPIOs property existence, before the >>>>> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio >>>>> support is added (2nd patch in this patch series) on x86 platforms using >>>>> ACPI. >>>>> >>>>> Here Mika's comments from 2016-08-09: >>>>> >>>>> " >>>>> I noticed that with v4.8-rc1 serial console of some of our Broxton >>>>> systems does not work properly anymore. I'm able to see output but input >>>>> does not work. >>>>> >>>>> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 >>>>> ("tty/serial/8250: use mctrl_gpio helpers"). >>>>> >>>>> The reason why it fails is that in ACPI we do not have names for GPIOs >>>>> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO >>>>> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs >>>>> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The >>>>> UART device in Broxton has following (simplified) ACPI description: >>>>> >>>>> Device (URT4) >>>>> { >>>>> ... >>>>> Name (_CRS, ResourceTemplate () { >>>>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, >>>>> "\\_SB.GPO0", 0x00, ResourceConsumer) >>>>> { >>>>> 0x003A >>>>> } >>>>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, >>>>> "\\_SB.GPO0", 0x00, ResourceConsumer) >>>>> { >>>>> 0x003D >>>>> } >>>>> }) >>>>> >>>>> In this case it finds the first GPIO (0x003A which happens to be RX pin >>>>> for that UART), turns it into GPIO which then breaks input for the UART >>>>> device. This also breaks systems with bluetooth connected to UART (those >>>>> typically have some GPIOs in their _CRS). >>>>> >>>>> Any ideas how to fix this? >>>>> >>>>> We cannot just drop the _CRS index lookup fallback because that would >>>>> break many existing machines out there so maybe we can limit this to >>>>> only DT enabled machines. Or alternatively probe if the property first >>>>> exists before trying to acquire the GPIOs (using >>>>> device_property_present()). >>>>> " >>>>> >>>>> This patch implements the fix suggested by Mika in his statement above. >>>>> >>> >>> We have a board where ASL provides _DSD for CTS and RxD pins. >>> I'm afraid this won't work on it. >> >> With "won't work" you mean, that the GPIO can't be used for modem >> control in this case in the current implementation (with this >> patchset)? Or do you mean, that the breakage (input does not work >> on Broxton systems) will not be solved by this patch? > > It will solve RxD case, due to mctrl doesn't count RxD as a "control" line. > > Though we have CTS pin defined for the same purpose, which means the hardware > flow control won't work on a subset of Broxton boards. > >> If its the former, then I think that solving this issue is something >> for a new patch, to support modem-control on such platforms as well >> (if needed). > >> Please note that this patch is not trying to get modem-control working >> on such ACPI based systems. > > I understand that. At the same time it should not break existing systems. > >> Its targeted for device-tree enabled >> platforms, using the 8250 serial driver, here specifically a MIPS >> MT7688 based board. And just wants to fix the latter issue mentioned >> above so that the 8250 modem-control support can be accepted in >> mainline. > > As I said already we have to distinguish *the purpose* of these GPIOs. > (like CTS). > > Can we apply this if and only if the device has no ACPI companion device? > > In this case DT will work as you expect and ACPI won't be broken. So your suggestion is to add a has_acpi_companion() check before mctrl_gpio_init() is called in serial8250_register_8250_port() and then only use the gpio related mctrl, if the GPIO's are really used? I can certainly change patch 2/2 to do this. It would be great though, if you (or someone else) could test this on such a ACPI based platform, as I don't have access to such a board. Thanks, Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-05-27 7:06 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-24 9:48 [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Stefan Roese 2019-05-24 9:48 ` [PATCH 2/2 v2] tty/serial/8250: use mctrl_gpio helpers Stefan Roese 2019-05-24 10:20 ` [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Mika Westerberg 2019-05-24 11:11 ` Andy Shevchenko 2019-05-24 11:29 ` Stefan Roese 2019-05-24 12:09 ` Giulio Benetti 2019-05-24 13:46 ` Andy Shevchenko 2019-05-27 7:05 ` Stefan Roese
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.