* Re: [PATCH v3] serial: imx: warn user when using unsupported configuration
From: Uwe Kleine-König @ 2018-04-19 16:26 UTC (permalink / raw)
To: Stefan Agner; +Cc: gregkh, lukas, jslaby, linux-serial, linux-kernel
In-Reply-To: <20180419153916.21898-1-stefan@agner.ch>
Hello Stefan,
On Thu, Apr 19, 2018 at 05:39:16PM +0200, Stefan Agner wrote:
> When using half-duplex mode (which disables receiver during txing)
> the RTS signal cannot be driven low during transmission when using
> i.MX UART RTS/CTS control. This seems to be a limitation of the
> i.MX UART IP: The RTS (CTS_B) signal is controlled by the receiver.
> When the receiver is disabled, the signal stays in UART logic idle
> state which is high...
>
> If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
> transmission. Since this is the default state of the RTS (CTS_B)
> signal when the receiver is off, half-duplex mode in this
> configuration works fine.
>
> However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
> cannot be generated when the receiver is turned off.
>
> Print an error if the user selects this unsupported configuration
> (both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
> configure the closest working configuration (set the
> SER_RS485_RX_DURING_TX flag).
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 53/61] tty: serial: simplify getting .drvdata
From: Uwe Kleine-König @ 2018-04-19 16:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-kernel, linux-renesas-soc, kernel-janitors,
Greg Kroah-Hartman, Jiri Slaby, Patrice Chotard, Michal Simek,
linux-serial, linux-arm-kernel
In-Reply-To: <20180419140641.27926-54-wsa+renesas@sang-engineering.com>
Hello Wolfram,
On Thu, Apr 19, 2018 at 04:06:23PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/tty/serial/imx.c | 18 ++++++------------
for serial/imx.c:
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks Wolfram for going through this
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3] serial: imx: warn user when using unsupported configuration
From: Stefan Agner @ 2018-04-19 15:39 UTC (permalink / raw)
To: gregkh, u.kleine-koenig
Cc: lukas, jslaby, linux-serial, linux-kernel, Stefan Agner
When using half-duplex mode (which disables receiver during txing)
the RTS signal cannot be driven low during transmission when using
i.MX UART RTS/CTS control. This seems to be a limitation of the
i.MX UART IP: The RTS (CTS_B) signal is controlled by the receiver.
When the receiver is disabled, the signal stays in UART logic idle
state which is high...
If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
transmission. Since this is the default state of the RTS (CTS_B)
signal when the receiver is off, half-duplex mode in this
configuration works fine.
However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
cannot be generated when the receiver is turned off.
Print an error if the user selects this unsupported configuration
(both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
configure the closest working configuration (set the
SER_RS485_RX_DURING_TX flag).
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/tty/serial/imx.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 91f3a1a5cb7f..65d7a2bfb6d2 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1833,6 +1833,11 @@ static int imx_uart_rs485_config(struct uart_port *port,
rs485conf->flags &= ~SER_RS485_ENABLED;
if (rs485conf->flags & SER_RS485_ENABLED) {
+ /* Enable receiver if low-active RTS signal is requested */
+ if (sport->have_rtscts && !sport->have_rtsgpio &&
+ !(rs485conf->flags & SER_RS485_RTS_ON_SEND))
+ rs485conf->flags |= SER_RS485_RX_DURING_TX;
+
/* disable transmitter */
ucr2 = imx_uart_readl(sport, UCR2);
if (rs485conf->flags & SER_RS485_RTS_AFTER_SEND)
@@ -2265,6 +2270,18 @@ static int imx_uart_probe(struct platform_device *pdev)
(!sport->have_rtscts && !sport->have_rtsgpio))
dev_err(&pdev->dev, "no RTS control, disabling rs485\n");
+ /*
+ * If using the i.MX UART RTS/CTS control then the RTS (CTS_B)
+ * signal cannot be set low during transmission in case the
+ * receiver is off (limitation of the i.MX UART IP).
+ */
+ if (sport->port.rs485.flags & SER_RS485_ENABLED &&
+ sport->have_rtscts && !sport->have_rtsgpio &&
+ (!(sport->port.rs485.flags & SER_RS485_RTS_ON_SEND) &&
+ !(sport->port.rs485.flags & SER_RS485_RX_DURING_TX)))
+ dev_err(&pdev->dev,
+ "low-active RTS not possible when receiver is off, enabling receiver\n");
+
imx_uart_rs485_config(&sport->port, &sport->port.rs485);
/* Disable interrupts before requesting them */
--
2.17.0
^ permalink raw reply related
* [PATCH] serial: 8250_of: Add IO space support
From: John Garry @ 2018-04-19 15:37 UTC (permalink / raw)
To: gregkh, jslaby, joel, p.zabel, arnd, fcooper, sergei.shtylyov,
yamada.masahiro, khoroshilov
Cc: linux-serial, linux-kernel, andriy.shevchenko, linuxarm,
John Garry
Currently the 8250_of driver only supports MEM IO type
accesses.
Some development boards (Huawei D03, specifically) require
IO space access for 8250-compatible OF driver support, so
add it.
The modification is quite simple: just set the port iotype
and associated flags depending on the device address
resource type.
Signed-off-by: John Garry <john.garry@huawei.com>
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index 9835b1c..a7ffaf6 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -92,13 +92,43 @@ static int of_platform_serial_setup(struct platform_device *ofdev,
goto err_unprepare;
}
+ port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_FIXED_PORT |
+ UPF_FIXED_TYPE;
spin_lock_init(&port->lock);
- port->mapbase = resource.start;
- port->mapsize = resource_size(&resource);
- /* Check for shifted address mapping */
- if (of_property_read_u32(np, "reg-offset", &prop) == 0)
- port->mapbase += prop;
+ if ((resource.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO) {
+ port->iotype = UPIO_PORT;
+ port->iobase = resource.start;
+ } else {
+ port->mapbase = resource.start;
+ port->mapsize = resource_size(&resource);
+
+ /* Check for shifted address mapping */
+ if (of_property_read_u32(np, "reg-offset", &prop) == 0)
+ port->mapbase += prop;
+
+ port->iotype = UPIO_MEM;
+ if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
+ switch (prop) {
+ case 1:
+ port->iotype = UPIO_MEM;
+ break;
+ case 2:
+ port->iotype = UPIO_MEM16;
+ break;
+ case 4:
+ port->iotype = of_device_is_big_endian(np) ?
+ UPIO_MEM32BE : UPIO_MEM32;
+ break;
+ default:
+ dev_warn(&ofdev->dev, "unsupported reg-io-width (%d)\n",
+ prop);
+ ret = -EINVAL;
+ goto err_dispose;
+ }
+ }
+ port->flags |= UPF_IOREMAP;
+ }
/* Check for registers offset within the devices address range */
if (of_property_read_u32(np, "reg-shift", &prop) == 0)
@@ -114,26 +144,6 @@ static int of_platform_serial_setup(struct platform_device *ofdev,
port->line = ret;
port->irq = irq_of_parse_and_map(np, 0);
- port->iotype = UPIO_MEM;
- if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
- switch (prop) {
- case 1:
- port->iotype = UPIO_MEM;
- break;
- case 2:
- port->iotype = UPIO_MEM16;
- break;
- case 4:
- port->iotype = of_device_is_big_endian(np) ?
- UPIO_MEM32BE : UPIO_MEM32;
- break;
- default:
- dev_warn(&ofdev->dev, "unsupported reg-io-width (%d)\n",
- prop);
- ret = -EINVAL;
- goto err_dispose;
- }
- }
info->rst = devm_reset_control_get_optional_shared(&ofdev->dev, NULL);
if (IS_ERR(info->rst)) {
@@ -147,8 +157,6 @@ static int of_platform_serial_setup(struct platform_device *ofdev,
port->type = type;
port->uartclk = clk;
- port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
- | UPF_FIXED_PORT | UPF_FIXED_TYPE;
if (of_property_read_bool(np, "no-loopback-test"))
port->flags |= UPF_SKIP_TEST;
--
1.9.1
^ permalink raw reply related
* [PATCH 53/61] tty: serial: simplify getting .drvdata
From: Wolfram Sang @ 2018-04-19 14:06 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, kernel-janitors, Wolfram Sang,
Greg Kroah-Hartman, Jiri Slaby, Patrice Chotard, Michal Simek,
linux-serial, linux-arm-kernel
In-Reply-To: <20180419140641.27926-1-wsa+renesas@sang-engineering.com>
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy. Please apply individually.
drivers/tty/serial/imx.c | 18 ++++++------------
drivers/tty/serial/qcom_geni_serial.c | 6 ++----
drivers/tty/serial/st-asc.c | 6 ++----
drivers/tty/serial/xilinx_uartps.c | 6 ++----
4 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 91f3a1a5cb7f..f370c1cf4f27 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2408,8 +2408,7 @@ static void imx_uart_enable_wakeup(struct imx_port *sport, bool on)
static int imx_uart_suspend_noirq(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct imx_port *sport = platform_get_drvdata(pdev);
+ struct imx_port *sport = dev_get_drvdata(dev);
imx_uart_save_context(sport);
@@ -2420,8 +2419,7 @@ static int imx_uart_suspend_noirq(struct device *dev)
static int imx_uart_resume_noirq(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct imx_port *sport = platform_get_drvdata(pdev);
+ struct imx_port *sport = dev_get_drvdata(dev);
int ret;
ret = clk_enable(sport->clk_ipg);
@@ -2435,8 +2433,7 @@ static int imx_uart_resume_noirq(struct device *dev)
static int imx_uart_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct imx_port *sport = platform_get_drvdata(pdev);
+ struct imx_port *sport = dev_get_drvdata(dev);
int ret;
uart_suspend_port(&imx_uart_uart_driver, &sport->port);
@@ -2454,8 +2451,7 @@ static int imx_uart_suspend(struct device *dev)
static int imx_uart_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct imx_port *sport = platform_get_drvdata(pdev);
+ struct imx_port *sport = dev_get_drvdata(dev);
/* disable wakeup from i.MX UART */
imx_uart_enable_wakeup(sport, false);
@@ -2470,8 +2466,7 @@ static int imx_uart_resume(struct device *dev)
static int imx_uart_freeze(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct imx_port *sport = platform_get_drvdata(pdev);
+ struct imx_port *sport = dev_get_drvdata(dev);
uart_suspend_port(&imx_uart_uart_driver, &sport->port);
@@ -2480,8 +2475,7 @@ static int imx_uart_freeze(struct device *dev)
static int imx_uart_thaw(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct imx_port *sport = platform_get_drvdata(pdev);
+ struct imx_port *sport = dev_get_drvdata(dev);
uart_resume_port(&imx_uart_uart_driver, &sport->port);
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 65ff669373d4..66558d42d980 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -1085,8 +1085,7 @@ static int qcom_geni_serial_remove(struct platform_device *pdev)
static int __maybe_unused qcom_geni_serial_sys_suspend_noirq(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct qcom_geni_serial_port *port = platform_get_drvdata(pdev);
+ struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = &port->uport;
uart_suspend_port(uport->private_data, uport);
@@ -1095,8 +1094,7 @@ static int __maybe_unused qcom_geni_serial_sys_suspend_noirq(struct device *dev)
static int __maybe_unused qcom_geni_serial_sys_resume_noirq(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct qcom_geni_serial_port *port = platform_get_drvdata(pdev);
+ struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = &port->uport;
if (console_suspend_enabled && uport->suspended) {
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 5f9f01fac6dd..7971997cdead 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -842,16 +842,14 @@ static int asc_serial_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int asc_serial_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct uart_port *port = platform_get_drvdata(pdev);
+ struct uart_port *port = dev_get_drvdata(dev);
return uart_suspend_port(&asc_uart_driver, port);
}
static int asc_serial_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct uart_port *port = platform_get_drvdata(pdev);
+ struct uart_port *port = dev_get_drvdata(dev);
return uart_resume_port(&asc_uart_driver, port);
}
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index abcb4d09a2d8..3ec4efbf25a9 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1430,8 +1430,7 @@ static int cdns_uart_resume(struct device *device)
#endif /* ! CONFIG_PM_SLEEP */
static int __maybe_unused cdns_runtime_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct uart_port *port = platform_get_drvdata(pdev);
+ struct uart_port *port = dev_get_drvdata(dev);
struct cdns_uart *cdns_uart = port->private_data;
clk_disable(cdns_uart->uartclk);
@@ -1441,8 +1440,7 @@ static int __maybe_unused cdns_runtime_suspend(struct device *dev)
static int __maybe_unused cdns_runtime_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct uart_port *port = platform_get_drvdata(pdev);
+ struct uart_port *port = dev_get_drvdata(dev);
struct cdns_uart *cdns_uart = port->private_data;
clk_enable(cdns_uart->pclk);
--
2.11.0
^ permalink raw reply related
* [PATCH 00/61] tree-wide: simplify getting .drvdata
From: Wolfram Sang @ 2018-04-19 14:05 UTC (permalink / raw)
To: linux-kernel
Cc: linux-ide, alsa-devel, linux-iio, kernel-janitors, linux-fbdev,
dri-devel, platform-driver-x86, Wolfram Sang, linux-mtd,
linux-clk, ac100, devel, linux-samsung-soc, linux-rockchip,
linux-serial, linux-input, linux-media, linux-pwm, linux-watchdog,
linux-pm, linux-arm-msm, acpi4asus-user, greybus-dev,
linux-mediatek, linux-tegra, linux-omap, linux-soc,
linux-arm-kernel
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
I send this out as one patch per directory per subsystem. I think they should
be applied individually. If you prefer a broken out series per subsystem, I can
provide this as well. Just mail me.
A branch (tested by buildbot; only with all commits squashed into one commit
before) can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata
Open for other comments, suggestions, too, of course.
Here is the cocci-script I created (after <n> iterations by manually checking
samples):
@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
- struct platform_device *pdev = to_platform_device(d);
|
- struct platform_device *pdev;
...
- pdev = to_platform_device(d);
)
<... when != pdev
- &pdev->dev
+ d
...>
ptr =
- platform_get_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- &pdev->dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (61):
ARM: plat-samsung: simplify getting .drvdata
ata: simplify getting .drvdata
auxdisplay: simplify getting .drvdata
bus: simplify getting .drvdata
clk: samsung: simplify getting .drvdata
crypto: simplify getting .drvdata
dma: simplify getting .drvdata
dmaengine: dw: simplify getting .drvdata
dmaengine: qcom: simplify getting .drvdata
gpio: simplify getting .drvdata
gpu: drm: msm: simplify getting .drvdata
gpu: drm: msm: adreno: simplify getting .drvdata
gpu: drm: msm: disp: mdp5: simplify getting .drvdata
gpu: drm: msm: dsi: simplify getting .drvdata
gpu: drm: omapdrm: displays: simplify getting .drvdata
gpu: drm: vc4: simplify getting .drvdata
hid: simplify getting .drvdata
iio: common: cros_ec_sensors: simplify getting .drvdata
iio: common: hid-sensors: simplify getting .drvdata
input: keyboard: simplify getting .drvdata
input: misc: simplify getting .drvdata
input: mouse: simplify getting .drvdata
input: touchscreen: simplify getting .drvdata
iommu: simplify getting .drvdata
media: platform: am437x: simplify getting .drvdata
media: platform: exynos4-is: simplify getting .drvdata
media: platform: s5p-mfc: simplify getting .drvdata
mmc: host: simplify getting .drvdata
mtd: devices: simplify getting .drvdata
mtd: nand: onenand: simplify getting .drvdata
net: dsa: simplify getting .drvdata
net: ethernet: cadence: simplify getting .drvdata
net: ethernet: davicom: simplify getting .drvdata
net: ethernet: smsc: simplify getting .drvdata
net: ethernet: ti: simplify getting .drvdata
net: ethernet: wiznet: simplify getting .drvdata
perf: simplify getting .drvdata
pinctrl: simplify getting .drvdata
pinctrl: intel: simplify getting .drvdata
platform: x86: simplify getting .drvdata
power: supply: simplify getting .drvdata
ptp: simplify getting .drvdata
pwm: simplify getting .drvdata
rtc: simplify getting .drvdata
slimbus: simplify getting .drvdata
spi: simplify getting .drvdata
staging: greybus: simplify getting .drvdata
staging: iio: adc: simplify getting .drvdata
staging: nvec: simplify getting .drvdata
thermal: simplify getting .drvdata
thermal: int340x_thermal: simplify getting .drvdata
thermal: st: simplify getting .drvdata
tty: serial: simplify getting .drvdata
uio: simplify getting .drvdata
usb: mtu3: simplify getting .drvdata
usb: phy: simplify getting .drvdata
video: fbdev: simplify getting .drvdata
video: fbdev: omap2: omapfb: displays: simplify getting .drvdata
watchdog: simplify getting .drvdata
net: dsa: simplify getting .drvdata
ASoC: atmel: simplify getting .drvdata
arch/arm/plat-samsung/adc.c | 3 +-
drivers/ata/pata_samsung_cf.c | 8 ++---
drivers/auxdisplay/arm-charlcd.c | 6 ++--
drivers/bus/brcmstb_gisb.c | 12 +++----
drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++--
drivers/crypto/exynos-rng.c | 6 ++--
drivers/crypto/picoxcell_crypto.c | 6 ++--
drivers/dma/at_hdmac.c | 9 ++---
drivers/dma/at_xdmac.c | 9 ++---
drivers/dma/dw/platform.c | 6 ++--
drivers/dma/fsldma.c | 6 ++--
drivers/dma/idma64.c | 6 ++--
drivers/dma/qcom/hidma.c | 3 +-
drivers/dma/qcom/hidma_mgmt_sys.c | 6 ++--
drivers/dma/ste_dma40.c | 12 +++----
drivers/dma/txx9dmac.c | 8 ++---
drivers/gpio/gpio-dwapb.c | 6 ++--
drivers/gpio/gpio-lynxpoint.c | 3 +-
drivers/gpio/gpio-omap.c | 12 +++----
drivers/gpio/gpio-tegra.c | 6 ++--
drivers/gpio/gpio-zynq.c | 6 ++--
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 ++--
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++--
drivers/gpu/drm/msm/msm_drv.c | 3 +-
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 18 ++++------
drivers/gpu/drm/vc4/vc4_drv.c | 3 +-
drivers/hid/hid-sensor-custom.c | 12 +++----
.../common/cros_ec_sensors/cros_ec_sensors_core.c | 6 ++--
.../iio/common/hid-sensors/hid-sensor-trigger.c | 9 ++---
drivers/input/keyboard/ep93xx_keypad.c | 10 +++---
drivers/input/keyboard/imx_keypad.c | 10 +++---
drivers/input/keyboard/lpc32xx-keys.c | 6 ++--
drivers/input/keyboard/matrix_keypad.c | 10 +++---
drivers/input/keyboard/omap4-keypad.c | 10 +++---
drivers/input/keyboard/pmic8xxx-keypad.c | 6 ++--
drivers/input/keyboard/pxa27x_keypad.c | 10 +++---
drivers/input/keyboard/samsung-keypad.c | 12 +++----
drivers/input/keyboard/snvs_pwrkey.c | 10 +++---
drivers/input/keyboard/spear-keyboard.c | 10 +++---
drivers/input/keyboard/st-keyscan.c | 6 ++--
drivers/input/keyboard/tegra-kbc.c | 10 +++---
drivers/input/misc/max77693-haptic.c | 6 ++--
drivers/input/misc/max8997_haptic.c | 3 +-
drivers/input/misc/palmas-pwrbutton.c | 6 ++--
drivers/input/misc/regulator-haptic.c | 6 ++--
drivers/input/misc/twl4030-vibra.c | 3 +-
drivers/input/misc/twl6040-vibra.c | 3 +-
drivers/input/mouse/navpoint.c | 6 ++--
drivers/input/touchscreen/imx6ul_tsc.c | 6 ++--
drivers/iommu/qcom_iommu.c | 6 ++--
drivers/media/platform/am437x/am437x-vpfe.c | 6 ++--
drivers/media/platform/exynos4-is/media-dev.c | 6 ++--
drivers/media/platform/exynos4-is/mipi-csis.c | 6 ++--
drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 ++--
drivers/mmc/host/davinci_mmc.c | 6 ++--
drivers/mmc/host/sdhci-of-arasan.c | 6 ++--
drivers/mmc/host/wmt-sdmmc.c | 6 ++--
drivers/mtd/devices/docg3.c | 3 +-
drivers/mtd/nand/onenand/samsung.c | 6 ++--
drivers/net/dsa/bcm_sf2.c | 6 ++--
drivers/net/dsa/qca8k.c | 6 ++--
drivers/net/ethernet/cadence/macb_main.c | 6 ++--
drivers/net/ethernet/davicom/dm9000.c | 6 ++--
drivers/net/ethernet/smsc/smc91x.c | 3 +-
drivers/net/ethernet/ti/cpsw.c | 6 ++--
drivers/net/ethernet/ti/davinci_emac.c | 6 ++--
drivers/net/ethernet/wiznet/w5300.c | 6 ++--
drivers/perf/arm_spe_pmu.c | 6 ++--
drivers/pinctrl/intel/pinctrl-baytrail.c | 6 ++--
drivers/pinctrl/intel/pinctrl-cherryview.c | 6 ++--
drivers/pinctrl/intel/pinctrl-intel.c | 6 ++--
drivers/pinctrl/pinctrl-amd.c | 6 ++--
drivers/pinctrl/pinctrl-at91-pio4.c | 6 ++--
drivers/platform/x86/asus-laptop.c | 3 +-
drivers/platform/x86/asus-wmi.c | 3 +-
drivers/platform/x86/samsung-laptop.c | 3 +-
drivers/power/supply/gpio-charger.c | 3 +-
drivers/ptp/ptp_dte.c | 6 ++--
drivers/pwm/pwm-atmel-tcb.c | 6 ++--
drivers/pwm/pwm-rcar.c | 3 +-
drivers/rtc/rtc-bq4802.c | 6 ++--
drivers/rtc/rtc-ds1216.c | 6 ++--
drivers/rtc/rtc-ds1511.c | 9 ++---
drivers/rtc/rtc-ds1553.c | 15 +++-----
drivers/rtc/rtc-ds1685.c | 21 ++++-------
drivers/rtc/rtc-ds1742.c | 6 ++--
drivers/rtc/rtc-lpc32xx.c | 16 ++++-----
drivers/rtc/rtc-m48t59.c | 41 +++++++++-------------
drivers/rtc/rtc-mv.c | 3 +-
drivers/rtc/rtc-mxc.c | 21 ++++-------
drivers/rtc/rtc-pcap.c | 15 +++-----
drivers/rtc/rtc-sh.c | 15 +++-----
drivers/rtc/rtc-stk17ta8.c | 15 +++-----
drivers/rtc/rtc-test.c | 3 +-
drivers/rtc/rtc-zynqmp.c | 10 +++---
drivers/slimbus/qcom-ctrl.c | 6 ++--
drivers/spi/spi-cadence.c | 6 ++--
drivers/spi/spi-zynqmp-gqspi.c | 6 ++--
drivers/staging/greybus/arche-platform.c | 3 +-
drivers/staging/iio/adc/ad7606_par.c | 6 ++--
drivers/staging/nvec/nvec.c | 6 ++--
drivers/thermal/int340x_thermal/int3400_thermal.c | 9 ++---
drivers/thermal/rockchip_thermal.c | 8 ++---
drivers/thermal/spear_thermal.c | 8 ++---
drivers/thermal/st/st_thermal.c | 6 ++--
drivers/thermal/zx2967_thermal.c | 6 ++--
drivers/tty/serial/imx.c | 18 ++++------
drivers/tty/serial/qcom_geni_serial.c | 6 ++--
drivers/tty/serial/st-asc.c | 6 ++--
drivers/tty/serial/xilinx_uartps.c | 6 ++--
drivers/uio/uio_fsl_elbc_gpcm.c | 6 ++--
drivers/usb/mtu3/mtu3_plat.c | 6 ++--
drivers/usb/phy/phy-am335x.c | 6 ++--
drivers/video/fbdev/auo_k190x.c | 12 +++----
.../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 18 ++++------
drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 ++--
drivers/video/fbdev/sh_mobile_meram.c | 6 ++--
drivers/watchdog/cadence_wdt.c | 6 ++--
drivers/watchdog/of_xilinx_wdt.c | 6 ++--
drivers/watchdog/wdat_wdt.c | 6 ++--
net/dsa/legacy.c | 6 ++--
sound/soc/atmel/atmel_ssc_dai.c | 6 ++--
123 files changed, 319 insertions(+), 607 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH v3 13/20] mmc: Remove depends on HAS_DMA in case of platform dependency
From: Ulf Hansson @ 2018-04-19 13:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Wolfram Sang,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
Linux Fbdev development list, Bjorn Andersson, Eric Anholt,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, Stefan Wahren, Boris Brezillon, Herbert Xu,
Richard Weinberger, Jassi Brar, Marek Vasut,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Matias Bjorling,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ohad Ben-Cohen, driverdevel,
Alan Tull
In-Reply-To: <1523987360-18760-14-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
On 17 April 2018 at 19:49, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> Reviewed-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Acked-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Thanks, applied for next!
Kind regrds
Uffe
> ---
> v3:
> - Add Acked-by,
> - Rebase to v4.17-rc1,
>
> v2:
> - Add Reviewed-by, Acked-by,
> - Drop RFC state,
> - Split per subsystem.
> ---
> drivers/mmc/host/Kconfig | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 9589f9c9046f14b1..3978d0418958bf6b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
> tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller support"
> depends on ARCH_MESON || COMPILE_TEST
> depends on COMMON_CLK
> - depends on HAS_DMA
> depends on OF
> help
> This selects support for the SD/MMC Host Controller on
> @@ -401,7 +400,6 @@ config MMC_OMAP
>
> config MMC_OMAP_HS
> tristate "TI OMAP High Speed Multimedia Card Interface support"
> - depends on HAS_DMA
> depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
> help
> This selects the TI OMAP High Speed Multimedia card Interface.
> @@ -511,7 +509,6 @@ config MMC_DAVINCI
>
> config MMC_GOLDFISH
> tristate "goldfish qemu Multimedia Card Interface support"
> - depends on HAS_DMA
> depends on GOLDFISH || COMPILE_TEST
> help
> This selects the Goldfish Multimedia card Interface emulation
> @@ -605,7 +602,7 @@ config MMC_SDHI
>
> config MMC_SDHI_SYS_DMAC
> tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
> - depends on MMC_SDHI && HAS_DMA
> + depends on MMC_SDHI
> default MMC_SDHI if (SUPERH || ARM)
> help
> This provides DMA support for SDHI SD/SDIO controllers
> @@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
> config MMC_SDHI_INTERNAL_DMAC
> tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
> depends on ARM64 || COMPILE_TEST
> - depends on MMC_SDHI && HAS_DMA
> + depends on MMC_SDHI
> default MMC_SDHI if ARM64
> help
> This provides DMA support for SDHI SD/SDIO controllers
> @@ -669,7 +666,6 @@ config MMC_CAVIUM_THUNDERX
>
> config MMC_DW
> tristate "Synopsys DesignWare Memory Card Interface"
> - depends on HAS_DMA
> depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
> help
> This selects support for the Synopsys DesignWare Mobile Storage IP
> @@ -748,7 +744,6 @@ config MMC_DW_ZX
>
> config MMC_SH_MMCIF
> tristate "SuperH Internal MMCIF support"
> - depends on HAS_DMA
> depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
> help
> This selects the MMC Host Interface controller (MMCIF) found in various
> @@ -868,7 +863,6 @@ config MMC_TOSHIBA_PCI
> config MMC_BCM2835
> tristate "Broadcom BCM2835 SDHOST MMC Controller support"
> depends on ARCH_BCM2835 || COMPILE_TEST
> - depends on HAS_DMA
> help
> This selects the BCM2835 SDHOST MMC controller. If you have
> a BCM2835 platform with SD or MMC devices, say Y or M here.
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] Check for an error when the clock is enabled.
From: Stefan Potyra @ 2018-04-19 13:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, linux-kernel
Cc: ldv-project, sil2review
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 0814e8d5da2b sc16is7xx: enable the clock
Signed-off-by: Stefan Potyra <Stefan.Potyra@elektrobit.com>
---
drivers/tty/serial/sc16is7xx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 65792a3539d0..243c96025053 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1168,7 +1168,10 @@ static int sc16is7xx_probe(struct device *dev,
else
return PTR_ERR(s->clk);
} else {
- clk_prepare_enable(s->clk);
+ ret = clk_prepare_enable(s->clk);
+ if (ret)
+ return ret;
+
freq = clk_get_rate(s->clk);
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2] serial: imx: warn user when using unsupported configuration
From: Stefan Agner @ 2018-04-18 15:30 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: gregkh, lukas, jslaby, linux-serial, linux-kernel
In-Reply-To: <20180418145341.xwsah7spyfazcb63@pengutronix.de>
On 18.04.2018 16:53, Uwe Kleine-König wrote:
> On Wed, Apr 18, 2018 at 04:06:38PM +0200, Stefan Agner wrote:
>> When using half-duplex mode (which disables receiver during txing)
>> the RTS signal cannot be driven low during transmission. This seems
>> to be a limitation of the i.MX UART IP: The RTS (CTS_B) signal is
>> controlled by the receiver. When the receiver is disabled, the
>> signal stays in UART logic idle state which is high...
>>
>> If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
>> transmission. Since this is the default state of the RTS (CTS_B)
>> signal when the receiver is off, half-duplex mode in this
>> configuration works fine.
>>
>> However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
>> cannot be generated when the receiver is turned off.
>>
>> Print an error if the user selects this unsupported configuration
>> (both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
>> configure the closest working configuration (set the
>> SER_RS485_RX_DURING_TX flag).
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>> Changes since v1:
>> - Consistently check for sport->have_rtscts && !(rs485conf->flags &
>> SER_RS485_RTS_ON_SEND)
>> - Don't break printed message
>>
>> drivers/tty/serial/imx.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> index 91f3a1a5cb7f..1c1080fc8084 100644
>> --- a/drivers/tty/serial/imx.c
>> +++ b/drivers/tty/serial/imx.c
>> @@ -1833,6 +1833,11 @@ static int imx_uart_rs485_config(struct uart_port *port,
>> rs485conf->flags &= ~SER_RS485_ENABLED;
>>
>> if (rs485conf->flags & SER_RS485_ENABLED) {
>> + /* Enable receiver if low-active RTS signal is requested */
>> + if (sport->have_rtscts &&
>> + !(rs485conf->flags & SER_RS485_RTS_ON_SEND))
>> + rs485conf->flags |= SER_RS485_RX_DURING_TX;
>> +
>
> I wonder what should happen, if the device tree has both
>
> uart-has-rtscts;
> rts-gpios = <...>;
Hm, it seems that the code controls both in that case.
>
> . I think the right thing would be to check for
>
> sport->have_rtscts && !sport->have_rtsgpio
I agree, since it controls both one can use the GPIO to have a working
half duplex with low-active RTS configuration.
Will send v3.
--
Stefan
^ permalink raw reply
* Re: [PATCH v2] serial: imx: warn user when using unsupported configuration
From: Uwe Kleine-König @ 2018-04-18 14:53 UTC (permalink / raw)
To: Stefan Agner; +Cc: gregkh, lukas, jslaby, linux-serial, linux-kernel
In-Reply-To: <20180418140638.19331-1-stefan@agner.ch>
On Wed, Apr 18, 2018 at 04:06:38PM +0200, Stefan Agner wrote:
> When using half-duplex mode (which disables receiver during txing)
> the RTS signal cannot be driven low during transmission. This seems
> to be a limitation of the i.MX UART IP: The RTS (CTS_B) signal is
> controlled by the receiver. When the receiver is disabled, the
> signal stays in UART logic idle state which is high...
>
> If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
> transmission. Since this is the default state of the RTS (CTS_B)
> signal when the receiver is off, half-duplex mode in this
> configuration works fine.
>
> However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
> cannot be generated when the receiver is turned off.
>
> Print an error if the user selects this unsupported configuration
> (both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
> configure the closest working configuration (set the
> SER_RS485_RX_DURING_TX flag).
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> Changes since v1:
> - Consistently check for sport->have_rtscts && !(rs485conf->flags &
> SER_RS485_RTS_ON_SEND)
> - Don't break printed message
>
> drivers/tty/serial/imx.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 91f3a1a5cb7f..1c1080fc8084 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1833,6 +1833,11 @@ static int imx_uart_rs485_config(struct uart_port *port,
> rs485conf->flags &= ~SER_RS485_ENABLED;
>
> if (rs485conf->flags & SER_RS485_ENABLED) {
> + /* Enable receiver if low-active RTS signal is requested */
> + if (sport->have_rtscts &&
> + !(rs485conf->flags & SER_RS485_RTS_ON_SEND))
> + rs485conf->flags |= SER_RS485_RX_DURING_TX;
> +
I wonder what should happen, if the device tree has both
uart-has-rtscts;
rts-gpios = <...>;
. I think the right thing would be to check for
sport->have_rtscts && !sport->have_rtsgpio
.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2] serial: imx: warn user when using unsupported configuration
From: Stefan Agner @ 2018-04-18 14:06 UTC (permalink / raw)
To: gregkh, u.kleine-koenig
Cc: lukas, jslaby, linux-serial, linux-kernel, Stefan Agner
When using half-duplex mode (which disables receiver during txing)
the RTS signal cannot be driven low during transmission. This seems
to be a limitation of the i.MX UART IP: The RTS (CTS_B) signal is
controlled by the receiver. When the receiver is disabled, the
signal stays in UART logic idle state which is high...
If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
transmission. Since this is the default state of the RTS (CTS_B)
signal when the receiver is off, half-duplex mode in this
configuration works fine.
However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
cannot be generated when the receiver is turned off.
Print an error if the user selects this unsupported configuration
(both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
configure the closest working configuration (set the
SER_RS485_RX_DURING_TX flag).
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Changes since v1:
- Consistently check for sport->have_rtscts && !(rs485conf->flags &
SER_RS485_RTS_ON_SEND)
- Don't break printed message
drivers/tty/serial/imx.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 91f3a1a5cb7f..1c1080fc8084 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1833,6 +1833,11 @@ static int imx_uart_rs485_config(struct uart_port *port,
rs485conf->flags &= ~SER_RS485_ENABLED;
if (rs485conf->flags & SER_RS485_ENABLED) {
+ /* Enable receiver if low-active RTS signal is requested */
+ if (sport->have_rtscts &&
+ !(rs485conf->flags & SER_RS485_RTS_ON_SEND))
+ rs485conf->flags |= SER_RS485_RX_DURING_TX;
+
/* disable transmitter */
ucr2 = imx_uart_readl(sport, UCR2);
if (rs485conf->flags & SER_RS485_RTS_AFTER_SEND)
@@ -2265,6 +2270,16 @@ static int imx_uart_probe(struct platform_device *pdev)
(!sport->have_rtscts && !sport->have_rtsgpio))
dev_err(&pdev->dev, "no RTS control, disabling rs485\n");
+ /*
+ * The RTS (CTS_B) signal cannot be set low during transmission
+ * in case the receiver is off (limitation of the i.MX UART IP).
+ */
+ if (sport->port.rs485.flags & SER_RS485_ENABLED && sport->have_rtscts &&
+ (!(sport->port.rs485.flags & SER_RS485_RTS_ON_SEND) &&
+ !(sport->port.rs485.flags & SER_RS485_RX_DURING_TX)))
+ dev_err(&pdev->dev,
+ "low-active RTS not possible when receiver is off, enabling receiver\n");
+
imx_uart_rs485_config(&sport->port, &sport->port.rs485);
/* Disable interrupts before requesting them */
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] serial: imx: warn user when using unsupported configuration
From: Uwe Kleine-König @ 2018-04-18 13:46 UTC (permalink / raw)
To: Stefan Agner; +Cc: gregkh, lukas, jslaby, linux-serial, linux-kernel
In-Reply-To: <20180418133217.14568-1-stefan@agner.ch>
Hello Stefan,
On Wed, Apr 18, 2018 at 03:32:17PM +0200, Stefan Agner wrote:
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 91f3a1a5cb7f..1ba7e98ddc76 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1833,6 +1833,10 @@ static int imx_uart_rs485_config(struct uart_port *port,
> rs485conf->flags &= ~SER_RS485_ENABLED;
>
> if (rs485conf->flags & SER_RS485_ENABLED) {
> + /* Enable receiver if low-active RTS signal is requested */
> + if (rs485conf->flags & SER_RS485_RTS_AFTER_SEND)
> + rs485conf->flags |= SER_RS485_RX_DURING_TX;
> +
this is wrong if RTS is driven by a GPIO.
> /* disable transmitter */
> ucr2 = imx_uart_readl(sport, UCR2);
> if (rs485conf->flags & SER_RS485_RTS_AFTER_SEND)
> @@ -2265,6 +2269,17 @@ static int imx_uart_probe(struct platform_device *pdev)
> (!sport->have_rtscts && !sport->have_rtsgpio))
> dev_err(&pdev->dev, "no RTS control, disabling rs485\n");
>
> + /*
> + * The RTS (CTS_B) signal cannot be set low during transmission
> + * in case the receiver is off (limitation of the i.MX UART IP).
> + */
> + if (sport->port.rs485.flags & SER_RS485_ENABLED && sport->have_rtscts &&
> + (!(sport->port.rs485.flags & SER_RS485_RTS_ON_SEND) &&
> + !(sport->port.rs485.flags & SER_RS485_RX_DURING_TX)))
> + dev_err(&pdev->dev,
> + "low-active RTS not possible when receiver is off, "
> + "enabling receiver\n");
If you have the choice between breaking a user visible string and a code
line >80 chars, please pick the latter.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] serial: imx: warn user when using unsupported configuration
From: Stefan Agner @ 2018-04-18 13:32 UTC (permalink / raw)
To: gregkh, u.kleine-koenig
Cc: lukas, jslaby, linux-serial, linux-kernel, Stefan Agner
When using half-duplex mode (which disables receiver during txing)
the RTS signal cannot be driven low during transmission. This seems
to be a limitation of the i.MX UART IP: The RTS (CTS_B) signal is
controlled by the receiver. When the receiver is disabled, the
signal stays in UART logic idle state which is high...
If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
transmission. Since this is the default state of the RTS (CTS_B)
signal when the receiver is off, half-duplex mode in this
configuration works fine.
However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
cannot be generated when the receiver is turned off.
Print an error if the user selects this unsupported configuration
(both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
configure the closest working configuration (set the
SER_RS485_RX_DURING_TX flag).
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/tty/serial/imx.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 91f3a1a5cb7f..1ba7e98ddc76 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1833,6 +1833,10 @@ static int imx_uart_rs485_config(struct uart_port *port,
rs485conf->flags &= ~SER_RS485_ENABLED;
if (rs485conf->flags & SER_RS485_ENABLED) {
+ /* Enable receiver if low-active RTS signal is requested */
+ if (rs485conf->flags & SER_RS485_RTS_AFTER_SEND)
+ rs485conf->flags |= SER_RS485_RX_DURING_TX;
+
/* disable transmitter */
ucr2 = imx_uart_readl(sport, UCR2);
if (rs485conf->flags & SER_RS485_RTS_AFTER_SEND)
@@ -2265,6 +2269,17 @@ static int imx_uart_probe(struct platform_device *pdev)
(!sport->have_rtscts && !sport->have_rtsgpio))
dev_err(&pdev->dev, "no RTS control, disabling rs485\n");
+ /*
+ * The RTS (CTS_B) signal cannot be set low during transmission
+ * in case the receiver is off (limitation of the i.MX UART IP).
+ */
+ if (sport->port.rs485.flags & SER_RS485_ENABLED && sport->have_rtscts &&
+ (!(sport->port.rs485.flags & SER_RS485_RTS_ON_SEND) &&
+ !(sport->port.rs485.flags & SER_RS485_RX_DURING_TX)))
+ dev_err(&pdev->dev,
+ "low-active RTS not possible when receiver is off, "
+ "enabling receiver\n");
+
imx_uart_rs485_config(&sport->port, &sport->port.rs485);
/* Disable interrupts before requesting them */
--
2.17.0
^ permalink raw reply related
* Re: 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-18 12:47 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi
Cc: Vignesh R, Tony Lindgren, Greg Kroah-Hartman, linux-serial,
Linux OMAP Mailing List, linux-arm-kernel
In-Reply-To: <20180418110033.GO10990@n2100.armlinux.org.uk>
On Wed, Apr 18, 2018 at 12:00:33PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> > >>
> > >>
> > >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> > >> >
> > >> >
> > >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > >> >>> Hi,
> > >> >>>
> > >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> > >> >>> with the serial console on the OMAP4430 SDP board. During boot,
> > >> >>> everything seems fine, the problem appears to be userspace output.
> > >> >>>
> > >> >>> For example, if I edit a file, then quit vi:
> > >> >>>
> > >> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> > >> >>
> > >> >> I don't think I've seen that one. What I've seen few times is
> > >> >> typing a key on the serial console echoing back the previous
> > >> >> character typed while the new character won't get displayed
> > >> >> until hitting keyboard again. Only rebooting the device seems
> > >> >> to solve this. This is with 4430 ES2.3 revision.
> > >> >>
> > >> >> I wonder if we're missing some parts of errata i202 handling
> > >> >> in omap_8250_mdr1_errataset()?
> > >> >>
> > >>
> > >> I wonder if the extra read of MDR1 register at the beginning of
> > >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> > >> errata i202 says access to MDR1 can cause data corruption.
> > >> Assuming both reads and writes can cause glitch then, that read
> > >> is not following advisory:
> > >>
> > >> I don't have SDP board so, could you verify if below diff helps:
> > >>
> > >>
> > >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> > >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> > >> --- a/drivers/tty/serial/8250/8250_omap.c
> > >> +++ b/drivers/tty/serial/8250/8250_omap.c
> > >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> > >> struct omap8250_priv *priv)
> > >> {
> > >> u8 timeout = 255;
> > >> - u8 old_mdr1;
> > >> -
> > >> - old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> > >> - if (old_mdr1 == priv->mdr1)
> > >> - return;
> > >>
> > >> serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> > >> udelay(2);
> > >
> > > That doesn't appear to help.
> > >
> > > Looking at the bitstream and comparing what should have been sent with
> > > what was sent, there appears to be some correlation between the two.
> > > It looks like the FTDI is not properly synchronised to the bitstream
> > > coming from the OMAP4430.
> > >
> > > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> > > improve the issue, but not completely solve it.
> >
> > Are you sure about clock error above some tollerance?
>
> No idea at the moment. Looking at the bitstream with a scope is the
> next step, but it's not easy to do that with just two hands. I also
> need to find some way to trigger it reliably.
>
> Another cause could be that the UART pin is being held high/low for
> some reason (maybe a pinmux problem.)
>
> Another interesting observation is that if I login over the network and
> then do:
>
> while :; do :; done &
> while :; do :; done &
>
> to occupy both CPUs, and then do:
>
> dmesg | less
>
> on the console, the problem goes away. If I only do one while loop,
> the problem is present, but the corruption looks like it happens at a
> different point in the serial stream.
>
> This would seem to point the blame away from clocks or pinmux, and back
> to power management issues.
>
> I've also tried mimicking the less output with a stand-alone program,
> and that doesn't exhibit the problem - I've tried with various initial
> delays between program start and first output, but this doesn't seem
> to have much effect. So it seems to need rather precise timing.
>
> stracing less does change where the corruption happens in the output,
> which also suggests a timing related cause.
Okay, I think I'm getting somewhere... `less' does an ioctl(, TCSETS, )
after outputting a screenful in order to change c_iflag and c_lflag.
The differences are:
c_iflag 0x1500 -> 0x1000
c_lflag 0x083b -> 0x0831
Other settings are kept the same.
The iflag changes are IXON | ICRNL, and the lflag changes are
ECHO | ICANON. Reproducing those changes in my test program shows
the same corruption.
Removing the lflag changes makes no difference. Removing the ICRNL
also makes no difference - the problem is still there. Removing
the IXON change and the problem vanishes.
Given that the serial driver rewrites the entire UART configuration
on a termios change that affects any hardware settings, this is
rather expected to happen.
So, the question becomes whether userspace is acting correctly - and
I'd say no. Looking at _real_ `less' (iow, not the busybox version
that I seem to have on the OMAP4430) it doesn't do this fiddling with
termios settings just before waiting for input. Moreover, I can't see
_any_ reason for `less' of any kind to be fiddling with IXON.
There is the remaining question about the proper behaviour of setting
termios modes while there is a transmit operation in progress - I know
of several programs that do this. A TCSETS operation is defined to
occur "immediately" by the spec, but is it reasonable to change the
modes mid-transmission of a character (which _will_ corrupt the
character), or should they be changed at a character boundary (or at
whatever character boundary the hardware is capable of.)
I note that if DMA is enabled, 8250_omap delays a TCSETS operation
until DMA has completed, so I suspect that the problem I'm seeing
will go away if I enable DMA.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-18 12:17 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi
Cc: Vignesh R, Tony Lindgren, Greg Kroah-Hartman, linux-serial,
Linux OMAP Mailing List, linux-arm-kernel
In-Reply-To: <CAOf5uwkybbUTnwvdAz9gDGo00oTgTirwJDjwqsLFWEukh70aEQ@mail.gmail.com>
On Wed, Apr 18, 2018 at 01:45:12PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Wed, Apr 18, 2018 at 1:00 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> >> Hi
> >>
> >> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> >> <linux@armlinux.org.uk> wrote:
> >> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> >> >>
> >> >>
> >> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> >> >> >
> >> >> >
> >> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >> >> >>> with the serial console on the OMAP4430 SDP board. During boot,
> >> >> >>> everything seems fine, the problem appears to be userspace output.
> >> >> >>>
> >> >> >>> For example, if I edit a file, then quit vi:
> >> >> >>>
> >> >> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> >> >> >>
> >> >> >> I don't think I've seen that one. What I've seen few times is
> >> >> >> typing a key on the serial console echoing back the previous
> >> >> >> character typed while the new character won't get displayed
> >> >> >> until hitting keyboard again. Only rebooting the device seems
> >> >> >> to solve this. This is with 4430 ES2.3 revision.
> >> >> >>
> >> >> >> I wonder if we're missing some parts of errata i202 handling
> >> >> >> in omap_8250_mdr1_errataset()?
> >> >> >>
> >> >>
> >> >> I wonder if the extra read of MDR1 register at the beginning of
> >> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> >> >> errata i202 says access to MDR1 can cause data corruption.
> >> >> Assuming both reads and writes can cause glitch then, that read
> >> >> is not following advisory:
> >> >>
> >> >> I don't have SDP board so, could you verify if below diff helps:
> >> >>
> >> >>
> >> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> >> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> >> >> --- a/drivers/tty/serial/8250/8250_omap.c
> >> >> +++ b/drivers/tty/serial/8250/8250_omap.c
> >> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> >> >> struct omap8250_priv *priv)
> >> >> {
> >> >> u8 timeout = 255;
> >> >> - u8 old_mdr1;
> >> >> -
> >> >> - old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> >> >> - if (old_mdr1 == priv->mdr1)
> >> >> - return;
> >> >>
> >> >> serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> >> >> udelay(2);
> >> >
> >> > That doesn't appear to help.
> >> >
> >> > Looking at the bitstream and comparing what should have been sent with
> >> > what was sent, there appears to be some correlation between the two.
> >> > It looks like the FTDI is not properly synchronised to the bitstream
> >> > coming from the OMAP4430.
> >> >
> >> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> >> > improve the issue, but not completely solve it.
> >>
> >> Are you sure about clock error above some tollerance?
> >
> > No idea at the moment. Looking at the bitstream with a scope is the
> > next step, but it's not easy to do that with just two hands. I also
> > need to find some way to trigger it reliably.
> >
> > Another cause could be that the UART pin is being held high/low for
> > some reason (maybe a pinmux problem.)
> >
> > Another interesting observation is that if I login over the network and
> > then do:
> >
> > while :; do :; done &
> > while :; do :; done &
> >
>
> You can disable it. Anyway when uart from Ti go in idle mode that can loose
> the first char on receiving
That may be, but what happens on the OMAP receive side is not relevant.
This issue is about the OMAP4430 transmit side.
> > to occupy both CPUs, and then do:
> >
> > dmesg | less
> >
> > on the console, the problem goes away. If I only do one while loop,
> > the problem is present, but the corruption looks like it happens at a
> > different point in the serial stream.
> >
> > This would seem to point the blame away from clocks or pinmux, and back
> > to power management issues.
> >
>
> Do you have statistics from the uart under proc?
You mean on the OMAP4430?
# cat /proc/tty/driver/OMAP-SERIAL
serinfo:1.0 driver revision:
0: uart:OMAP UART0 mmio:0x4806A000 irq:32 tx:0 rx:0
1: uart:OMAP UART1 mmio:0x4806C000 irq:33 tx:0 rx:0
2: uart:OMAP UART2 mmio:0x48020000 irq:34 tx:638807 rx:5406 RTS|CTS|DTR
3: uart:OMAP UART3 mmio:0x4806E000 irq:35 tx:0 rx:0
Of course, there won't be anything of interest there because I'm
talking about the *transmit* side on the OMAP4430 and there's no
way to detect or monitor errors in the transmit side.
The ftdi-sio driver on the host machine, which would be involved in
the receive, doesn't keep statistics and make them available through
/proc. (Another reason why I hate usb-serial based development
boards.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Michael Nazzareno Trimarchi @ 2018-04-18 11:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Vignesh R, Tony Lindgren, Greg Kroah-Hartman, linux-serial,
Linux OMAP Mailing List, linux-arm-kernel
In-Reply-To: <20180418110033.GO10990@n2100.armlinux.org.uk>
Hi
On Wed, Apr 18, 2018 at 1:00 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
>> >>
>> >>
>> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
>> >> >
>> >> >
>> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>> >> >>> Hi,
>> >> >>>
>> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
>> >> >>> with the serial console on the OMAP4430 SDP board. During boot,
>> >> >>> everything seems fine, the problem appears to be userspace output.
>> >> >>>
>> >> >>> For example, if I edit a file, then quit vi:
>> >> >>>
>> >> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
>> >> >>
>> >> >> I don't think I've seen that one. What I've seen few times is
>> >> >> typing a key on the serial console echoing back the previous
>> >> >> character typed while the new character won't get displayed
>> >> >> until hitting keyboard again. Only rebooting the device seems
>> >> >> to solve this. This is with 4430 ES2.3 revision.
>> >> >>
>> >> >> I wonder if we're missing some parts of errata i202 handling
>> >> >> in omap_8250_mdr1_errataset()?
>> >> >>
>> >>
>> >> I wonder if the extra read of MDR1 register at the beginning of
>> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
>> >> errata i202 says access to MDR1 can cause data corruption.
>> >> Assuming both reads and writes can cause glitch then, that read
>> >> is not following advisory:
>> >>
>> >> I don't have SDP board so, could you verify if below diff helps:
>> >>
>> >>
>> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
>> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
>> >> --- a/drivers/tty/serial/8250/8250_omap.c
>> >> +++ b/drivers/tty/serial/8250/8250_omap.c
>> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>> >> struct omap8250_priv *priv)
>> >> {
>> >> u8 timeout = 255;
>> >> - u8 old_mdr1;
>> >> -
>> >> - old_mdr1 = serial_in(up, UART_OMAP_MDR1);
>> >> - if (old_mdr1 == priv->mdr1)
>> >> - return;
>> >>
>> >> serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>> >> udelay(2);
>> >
>> > That doesn't appear to help.
>> >
>> > Looking at the bitstream and comparing what should have been sent with
>> > what was sent, there appears to be some correlation between the two.
>> > It looks like the FTDI is not properly synchronised to the bitstream
>> > coming from the OMAP4430.
>> >
>> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
>> > improve the issue, but not completely solve it.
>>
>> Are you sure about clock error above some tollerance?
>
> No idea at the moment. Looking at the bitstream with a scope is the
> next step, but it's not easy to do that with just two hands. I also
> need to find some way to trigger it reliably.
>
> Another cause could be that the UART pin is being held high/low for
> some reason (maybe a pinmux problem.)
>
> Another interesting observation is that if I login over the network and
> then do:
>
> while :; do :; done &
> while :; do :; done &
>
You can disable it. Anyway when uart from Ti go in idle mode that can loose
the first char on receiving
> to occupy both CPUs, and then do:
>
> dmesg | less
>
> on the console, the problem goes away. If I only do one while loop,
> the problem is present, but the corruption looks like it happens at a
> different point in the serial stream.
>
> This would seem to point the blame away from clocks or pinmux, and back
> to power management issues.
>
Do you have statistics from the uart under proc?
Michael
> I've also tried mimicking the less output with a stand-alone program,
> and that doesn't exhibit the problem - I've tried with various initial
> delays between program start and first output, but this doesn't seem
> to have much effect. So it seems to need rather precise timing.
>
> stracing less does change where the corruption happens in the output,
> which also suggests a timing related cause.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-18 11:00 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi
Cc: Vignesh R, Tony Lindgren, Greg Kroah-Hartman, linux-serial,
Linux OMAP Mailing List, linux-arm-kernel
In-Reply-To: <CAOf5uw=+MeWs+6A-zuy+yq2fZJmoe8hoLPcY1NVi9nvDMOLd7g@mail.gmail.com>
On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> >>
> >>
> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> >> >
> >> >
> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >> >>> Hi,
> >> >>>
> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >> >>> with the serial console on the OMAP4430 SDP board. During boot,
> >> >>> everything seems fine, the problem appears to be userspace output.
> >> >>>
> >> >>> For example, if I edit a file, then quit vi:
> >> >>>
> >> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> >> >>
> >> >> I don't think I've seen that one. What I've seen few times is
> >> >> typing a key on the serial console echoing back the previous
> >> >> character typed while the new character won't get displayed
> >> >> until hitting keyboard again. Only rebooting the device seems
> >> >> to solve this. This is with 4430 ES2.3 revision.
> >> >>
> >> >> I wonder if we're missing some parts of errata i202 handling
> >> >> in omap_8250_mdr1_errataset()?
> >> >>
> >>
> >> I wonder if the extra read of MDR1 register at the beginning of
> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> >> errata i202 says access to MDR1 can cause data corruption.
> >> Assuming both reads and writes can cause glitch then, that read
> >> is not following advisory:
> >>
> >> I don't have SDP board so, could you verify if below diff helps:
> >>
> >>
> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> >> --- a/drivers/tty/serial/8250/8250_omap.c
> >> +++ b/drivers/tty/serial/8250/8250_omap.c
> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> >> struct omap8250_priv *priv)
> >> {
> >> u8 timeout = 255;
> >> - u8 old_mdr1;
> >> -
> >> - old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> >> - if (old_mdr1 == priv->mdr1)
> >> - return;
> >>
> >> serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> >> udelay(2);
> >
> > That doesn't appear to help.
> >
> > Looking at the bitstream and comparing what should have been sent with
> > what was sent, there appears to be some correlation between the two.
> > It looks like the FTDI is not properly synchronised to the bitstream
> > coming from the OMAP4430.
> >
> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> > improve the issue, but not completely solve it.
>
> Are you sure about clock error above some tollerance?
No idea at the moment. Looking at the bitstream with a scope is the
next step, but it's not easy to do that with just two hands. I also
need to find some way to trigger it reliably.
Another cause could be that the UART pin is being held high/low for
some reason (maybe a pinmux problem.)
Another interesting observation is that if I login over the network and
then do:
while :; do :; done &
while :; do :; done &
to occupy both CPUs, and then do:
dmesg | less
on the console, the problem goes away. If I only do one while loop,
the problem is present, but the corruption looks like it happens at a
different point in the serial stream.
This would seem to point the blame away from clocks or pinmux, and back
to power management issues.
I've also tried mimicking the less output with a stand-alone program,
and that doesn't exhibit the problem - I've tried with various initial
delays between program start and first output, but this doesn't seem
to have much effect. So it seems to need rather precise timing.
stracing less does change where the corruption happens in the output,
which also suggests a timing related cause.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Michael Nazzareno Trimarchi @ 2018-04-18 10:27 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Vignesh R, Tony Lindgren, Greg Kroah-Hartman, linux-serial,
Linux OMAP Mailing List, linux-arm-kernel
In-Reply-To: <20180418095950.GN10990@n2100.armlinux.org.uk>
Hi
On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
>>
>>
>> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
>> >
>> >
>> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>> >>> Hi,
>> >>>
>> >>> I'm not entirely sure what's going on, but I see corrupted characters
>> >>> with the serial console on the OMAP4430 SDP board. During boot,
>> >>> everything seems fine, the problem appears to be userspace output.
>> >>>
>> >>> For example, if I edit a file, then quit vi:
>> >>>
>> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
>> >>
>> >> I don't think I've seen that one. What I've seen few times is
>> >> typing a key on the serial console echoing back the previous
>> >> character typed while the new character won't get displayed
>> >> until hitting keyboard again. Only rebooting the device seems
>> >> to solve this. This is with 4430 ES2.3 revision.
>> >>
>> >> I wonder if we're missing some parts of errata i202 handling
>> >> in omap_8250_mdr1_errataset()?
>> >>
>>
>> I wonder if the extra read of MDR1 register at the beginning of
>> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
>> errata i202 says access to MDR1 can cause data corruption.
>> Assuming both reads and writes can cause glitch then, that read
>> is not following advisory:
>>
>> I don't have SDP board so, could you verify if below diff helps:
>>
>>
>> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
>> index 6aaa84355fd1..8ab9d0a1b1eb 100644
>> --- a/drivers/tty/serial/8250/8250_omap.c
>> +++ b/drivers/tty/serial/8250/8250_omap.c
>> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>> struct omap8250_priv *priv)
>> {
>> u8 timeout = 255;
>> - u8 old_mdr1;
>> -
>> - old_mdr1 = serial_in(up, UART_OMAP_MDR1);
>> - if (old_mdr1 == priv->mdr1)
>> - return;
>>
>> serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>> udelay(2);
>
> That doesn't appear to help.
>
> Looking at the bitstream and comparing what should have been sent with
> what was sent, there appears to be some correlation between the two.
> It looks like the FTDI is not properly synchronised to the bitstream
> coming from the OMAP4430.
>
> Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> improve the issue, but not completely solve it.
Are you sure about clock error above some tollerance?
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-18 9:59 UTC (permalink / raw)
To: Vignesh R
Cc: Tony Lindgren, Greg Kroah-Hartman, linux-omap, linux-serial,
linux-arm-kernel
In-Reply-To: <da3be56b-29d3-72f3-5eba-d6a38ae500d0@ti.com>
On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
>
>
> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> >
> >
> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >>> Hi,
> >>>
> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >>> with the serial console on the OMAP4430 SDP board. During boot,
> >>> everything seems fine, the problem appears to be userspace output.
> >>>
> >>> For example, if I edit a file, then quit vi:
> >>>
> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> >>
> >> I don't think I've seen that one. What I've seen few times is
> >> typing a key on the serial console echoing back the previous
> >> character typed while the new character won't get displayed
> >> until hitting keyboard again. Only rebooting the device seems
> >> to solve this. This is with 4430 ES2.3 revision.
> >>
> >> I wonder if we're missing some parts of errata i202 handling
> >> in omap_8250_mdr1_errataset()?
> >>
>
> I wonder if the extra read of MDR1 register at the beginning of
> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> errata i202 says access to MDR1 can cause data corruption.
> Assuming both reads and writes can cause glitch then, that read
> is not following advisory:
>
> I don't have SDP board so, could you verify if below diff helps:
>
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> struct omap8250_priv *priv)
> {
> u8 timeout = 255;
> - u8 old_mdr1;
> -
> - old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> - if (old_mdr1 == priv->mdr1)
> - return;
>
> serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> udelay(2);
That doesn't appear to help.
Looking at the bitstream and comparing what should have been sent with
what was sent, there appears to be some correlation between the two.
It looks like the FTDI is not properly synchronised to the bitstream
coming from the OMAP4430.
Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
improve the issue, but not completely solve it.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Vignesh R @ 2018-04-18 9:11 UTC (permalink / raw)
To: Tony Lindgren, Russell King - ARM Linux
Cc: Greg Kroah-Hartman, linux-omap, linux-serial, linux-arm-kernel
In-Reply-To: <413b774b-d19f-3221-44d5-7992d3b8757f@ti.com>
On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
>
>
> On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>>> Hi,
>>>
>>> I'm not entirely sure what's going on, but I see corrupted characters
>>> with the serial console on the OMAP4430 SDP board. During boot,
>>> everything seems fine, the problem appears to be userspace output.
>>>
>>> For example, if I edit a file, then quit vi:
>>>
>>> :q■■%■■B■■Z■root@omap-4430sdp:~#
>>
>> I don't think I've seen that one. What I've seen few times is
>> typing a key on the serial console echoing back the previous
>> character typed while the new character won't get displayed
>> until hitting keyboard again. Only rebooting the device seems
>> to solve this. This is with 4430 ES2.3 revision.
>>
>> I wonder if we're missing some parts of errata i202 handling
>> in omap_8250_mdr1_errataset()?
>>
I wonder if the extra read of MDR1 register at the beginning of
omap_8250_mdr1_errataset() compared to omap-serial is the issue.
errata i202 says access to MDR1 can cause data corruption.
Assuming both reads and writes can cause glitch then, that read
is not following advisory:
I don't have SDP board so, could you verify if below diff helps:
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 6aaa84355fd1..8ab9d0a1b1eb 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
struct omap8250_priv *priv)
{
u8 timeout = 255;
- u8 old_mdr1;
-
- old_mdr1 = serial_in(up, UART_OMAP_MDR1);
- if (old_mdr1 == priv->mdr1)
- return;
serial_out(up, UART_OMAP_MDR1, priv->mdr1);
udelay(2);
--
Regards
Vignesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-18 8:18 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-omap, Vignesh R, linux-arm-kernel,
linux-serial
In-Reply-To: <20180418005748.GE5671@atomide.com>
On Tue, Apr 17, 2018 at 05:57:48PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180417 22:12]:
> > On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> > > * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > > > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > > > unless I write some data to the port first. It does not seem
> > > > > to be related to the rts/cts lines being wired as I've tested
> > > > > muxing them out of the way.
> > > >
> > > > If this instance of UART is using DMA then it might be due an errata
> > > > worked around in AM33/AM43/DRA7:
> > > > https://patchwork.kernel.org/patch/6784331/
> > >
> > > It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> > > seem to help with the reset. Also disabling DMA does not seem
> > > to help. So far the only way to clear it seems to be to write
> > > a character (TX) on the device. Then things work just fine
> > > even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> > > this more at some point.
> >
> > Classic case of thread hijack. So, Tony's idle problem gets more
> > attention on _my_ thread than _my_ issue about TX corruption, yea,
> > that's fair... Come on guys, what about my problem, which is the
> > subject of this thread?
>
> Just trying to brainstorm what all can go wrong still :) OK so
> it's not DMA then.
>
> > I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.
>
> Is this happening also with v4.16 or with v4.17-rc1?
4.16
> So you just edit something in vi and and on exit it happens?
> Not happening here for me..
Or run less, eg, dmesg | less or less /some/file. It doesn't happen
with cat though.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH v3 07/20] i2c: Remove depends on HAS_DMA in case of platform dependency
From: Wolfram Sang @ 2018-04-18 7:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Bjorn Andersson, Eric Anholt,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, Stefan Wahren, Boris Brezillon, Herbert Xu,
Richard Weinberger, Jassi Brar, Marek Vasut,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Matias Bjorling,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ohad Ben-Cohen,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Alan Tull,
Bartlomiej Zolnierkiewicz, linux-k
In-Reply-To: <1523987360-18760-8-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 838 bytes --]
On Tue, Apr 17, 2018 at 07:49:07PM +0200, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> Reviewed-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Applied to for-current, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Tony Lindgren @ 2018-04-18 0:57 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Greg Kroah-Hartman, linux-omap, Vignesh R, linux-arm-kernel,
linux-serial
In-Reply-To: <20180417221029.GL10990@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [180417 22:12]:
> On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> > * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > > unless I write some data to the port first. It does not seem
> > > > to be related to the rts/cts lines being wired as I've tested
> > > > muxing them out of the way.
> > >
> > > If this instance of UART is using DMA then it might be due an errata
> > > worked around in AM33/AM43/DRA7:
> > > https://patchwork.kernel.org/patch/6784331/
> >
> > It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> > seem to help with the reset. Also disabling DMA does not seem
> > to help. So far the only way to clear it seems to be to write
> > a character (TX) on the device. Then things work just fine
> > even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> > this more at some point.
>
> Classic case of thread hijack. So, Tony's idle problem gets more
> attention on _my_ thread than _my_ issue about TX corruption, yea,
> that's fair... Come on guys, what about my problem, which is the
> subject of this thread?
Just trying to brainstorm what all can go wrong still :) OK so
it's not DMA then.
> I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.
Is this happening also with v4.16 or with v4.17-rc1?
So you just edit something in vi and and on exit it happens?
Not happening here for me..
Regards,
Tony
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-17 22:10 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-omap, Vignesh R, linux-arm-kernel,
linux-serial
In-Reply-To: <20180417173134.GD5671@atomide.com>
On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > unless I write some data to the port first. It does not seem
> > > to be related to the rts/cts lines being wired as I've tested
> > > muxing them out of the way.
> >
> > If this instance of UART is using DMA then it might be due an errata
> > worked around in AM33/AM43/DRA7:
> > https://patchwork.kernel.org/patch/6784331/
>
> It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> seem to help with the reset. Also disabling DMA does not seem
> to help. So far the only way to clear it seems to be to write
> a character (TX) on the device. Then things work just fine
> even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> this more at some point.
Classic case of thread hijack. So, Tony's idle problem gets more
attention on _my_ thread than _my_ issue about TX corruption, yea,
that's fair... Come on guys, what about my problem, which is the
subject of this thread?
I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v3 20/20] usb: Remove depends on HAS_DMA in case of platform dependency
From: Geert Uytterhoeven @ 2018-04-17 17:49 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Robin Murphy, Felipe Balbi,
Greg Kroah-Hartman, Andrew Morton, Mark Brown, Liam Girdwood,
Tejun Heo, Herbert Xu, David S . Miller,
Bartlomiej Zolnierkiewicz, Stefan Richter, Alan Tull,
Moritz Fischer, Wolfram Sang, Jonathan Cameron, Joerg Roedel,
Matias Bjorling, Jassi Brar, Mauro Carvalho Chehab, Ulf Hansson,
David Woodhouse
Cc: devel, alsa-devel, linux-media, linux-iio, netdev, linux-fpga,
linux-usb, linux-mmc, linux-fbdev, linux-spi, linux-block,
linux-ide, iommu, linux-mtd, linux-crypto, linux-serial,
Geert Uytterhoeven, linux-remoteproc, linux1394-devel,
linux-kernel, linux-i2c
In-Reply-To: <1523987360-18760-1-git-send-email-geert@linux-m68k.org>
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> [drivers/usb/gadget/]
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v3:
- Add Acked-by,
- Rebase to v4.17-rc1,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/usb/gadget/udc/Kconfig | 4 ++--
drivers/usb/mtu3/Kconfig | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee9395..9c3b4f86965e80c7 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -179,7 +179,7 @@ config USB_R8A66597
config USB_RENESAS_USBHS_UDC
tristate 'Renesas USBHS controller'
- depends on USB_RENESAS_USBHS && HAS_DMA
+ depends on USB_RENESAS_USBHS
help
Renesas USBHS is a discrete USB host and peripheral controller chip
that supports both full and high speed USB 2.0 data transfers.
@@ -192,7 +192,7 @@ config USB_RENESAS_USBHS_UDC
config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
- depends on EXTCON && HAS_DMA
+ depends on EXTCON
help
Renesas USB3.0 Peripheral controller is a USB peripheral controller
that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd61947beea51e..c0c0eb88e5eafc74 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
- depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+ depends on EXTCON && (USB || USB_GADGET)
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox