aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/tty/serial
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'linux-stable/linux-3.0.y' into ↵Ziyan2015-10-259-47/+98
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | p-android-omap-3.0-dev-espresso Conflicts: Makefile arch/arm/include/asm/hardware/cache-l2x0.h arch/arm/kernel/smp.c arch/arm/mach-omap2/board-4430sdp.c arch/arm/mach-omap2/board-omap4panda.c arch/arm/mach-omap2/opp.c arch/ia64/include/asm/futex.h drivers/bluetooth/ath3k.c drivers/bluetooth/btusb.c drivers/firmware/efivars.c drivers/gpu/drm/i915/intel_lvds.c drivers/gpu/drm/radeon/radeon_atombios.c drivers/gpu/drm/radeon/radeon_irq_kms.c drivers/hwmon/fam15h_power.c drivers/mfd/twl6030-irq.c drivers/mmc/core/sdio.c drivers/net/tun.c drivers/net/usb/ipheth.c drivers/net/usb/usbnet.c drivers/usb/core/hub.c drivers/usb/host/xhci-mem.c drivers/usb/host/xhci.h drivers/usb/musb/omap2430.c drivers/usb/serial/ftdi_sio.c drivers/usb/serial/ftdi_sio_ids.h drivers/usb/serial/option.c drivers/usb/serial/qcserial.c drivers/usb/serial/ti_usb_3410_5052.c drivers/usb/serial/ti_usb_3410_5052.h drivers/video/omap2/dss/hdmi.c fs/splice.c include/asm-generic/pgtable.h include/net/sch_generic.h kernel/cgroup.c kernel/futex.c kernel/time/timekeeping.c net/ipv4/route.c net/ipv4/syncookies.c net/ipv4/tcp_ipv4.c net/wireless/util.c security/commoncap.c sound/soc/soc-dapm.c
| * serial/mxs-auart: increase time to wait for transmitter to become idleUwe Kleine-König2013-08-111-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 upstream. Without this patch the driver waits ~1 ms for the UART to become idle. At 115200n8 this time is (theoretically) enough to transfer 11.5 characters (= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size of 16 characters the clock is gated too early. The problem is worse for lower baud rates. This only happens to really shut down the transmitter in the middle of a transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but was at least once (because the bootloader doesn't disable the transmitter). So increase the timeout to 20 ms which should be enough for 9600n8, too. Moreover skip gating the clock if the timeout is elapsed. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial/mxs-auart: fix race condition in interrupt handlerUwe Kleine-König2013-08-111-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 upstream. The handler needs to ack the pending events before actually handling them. Otherwise a new event might come in after it it considered non-pending or handled and is acked then without being handled. So this event is only noticed when the next interrupt happens. Without this patch an i.MX28 based machine running an rt-patched kernel regularly hangs during boot. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * pch_uart: fix a deadlock when pch_uart as consoleLiang Li2013-07-031-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 384e301e3519599b000c1a2ecd938b533fc15d85 upstream. When we use pch_uart as system console like 'console=ttyPCH0,115200', then 'send break' to it. We'll encounter the deadlock on a cpu/core, with interrupts disabled on the core. When we happen to have all irqs affinity to cpu0 then the deadlock on cpu0 actually deadlock whole system. In pch_uart_interrupt, we have spin_lock_irqsave(&priv->lock, flags) then call pch_uart_err_ir when break is received. Then the call to dev_err would actually call to pch_console_write then we'll run into another spin_lock(&priv->lock), with interrupts disabled. So in the call sequence lead by pch_uart_interrupt, we should be carefully to call functions that will 'print message to console' only in case the uart port is not being used as serial console. Signed-off-by: Liang Li <liang.li@windriver.com> Cc: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial_core.c: add put_device() after device_find_child()Federico Vaga2013-05-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5a65dcc04cda41f4122aacc37a5a348454645399 upstream. The serial core uses device_find_child() but does not drop the reference to the retrieved child after using it. This patch add the missing put_device(). What I have done to test this issue. I used a machine with an AMBA PL011 serial driver. I tested the patch on next-20120408 because the last branch [next-20120415] does not boot on this board. For test purpose, I added some pr_info() messages to print the refcount after device_find_child() (lines: 1937,2009), and after put_device() (lines: 1947, 2021). Boot the machine *without* put_device(). Then: echo reboot > /sys/power/disk echo disk > /sys/power/state [ 87.058575] uart_suspend_port:1937 refcount 4 [ 87.058582] uart_suspend_port:1947 refcount 4 [ 87.098083] uart_resume_port:2009refcount 5 [ 87.098088] uart_resume_port:2021 refcount 5 echo disk > /sys/power/state [ 103.055574] uart_suspend_port:1937 refcount 6 [ 103.055580] uart_suspend_port:1947 refcount 6 [ 103.095322] uart_resume_port:2009 refcount 7 [ 103.095327] uart_resume_port:2021 refcount 7 echo disk > /sys/power/state [ 252.459580] uart_suspend_port:1937 refcount 8 [ 252.459586] uart_suspend_port:1947 refcount 8 [ 252.499611] uart_resume_port:2009 refcount 9 [ 252.499616] uart_resume_port:2021 refcount 9 The refcount continuously increased. Boot the machine *with* this patch. Then: echo reboot > /sys/power/disk echo disk > /sys/power/state [ 159.333559] uart_suspend_port:1937 refcount 4 [ 159.333566] uart_suspend_port:1947 refcount 3 [ 159.372751] uart_resume_port:2009 refcount 4 [ 159.372755] uart_resume_port:2021 refcount 3 echo disk > /sys/power/state [ 185.713614] uart_suspend_port:1937 refcount 4 [ 185.713621] uart_suspend_port:1947 refcount 3 [ 185.752935] uart_resume_port:2009 refcount 4 [ 185.752940] uart_resume_port:2021 refcount 3 echo disk > /sys/power/state [ 207.458584] uart_suspend_port:1937 refcount 4 [ 207.458591] uart_suspend_port:1947 refcount 3 [ 207.498598] uart_resume_port:2009 refcount 4 [ 207.498605] uart_resume_port:2021 refcount 3 The refcount correctly handled. Signed-off-by: Federico Vaga <federico.vaga@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * sunsu: Fix panic in case of nonexistent port at "console=ttySY" cmdline optionTkhai Kirill2013-03-281-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit cb29529ea0030e60ef1bbbf8399a43d397a51526 ] If a machine has X (X < 4) sunsu ports and cmdline option "console=ttySY" is passed, where X < Y <= 4, than the following panic happens: Unable to handle kernel NULL pointer dereference TPC: <sunsu_console_setup+0x78/0xe0> RPC: <sunsu_console_setup+0x74/0xe0> I7: <register_console+0x378/0x3e0> Call Trace: [0000000000453a38] register_console+0x378/0x3e0 [0000000000576fa0] uart_add_one_port+0x2e0/0x340 [000000000057af40] su_probe+0x160/0x2e0 [00000000005b8a4c] platform_drv_probe+0xc/0x20 [00000000005b6c2c] driver_probe_device+0x12c/0x220 [00000000005b6da8] __driver_attach+0x88/0xa0 [00000000005b4df4] bus_for_each_dev+0x54/0xa0 [00000000005b5a54] bus_add_driver+0x154/0x260 [00000000005b7190] driver_register+0x50/0x180 [00000000006d250c] sunsu_init+0x18c/0x1e0 [00000000006c2668] do_one_initcall+0xe8/0x160 [00000000006c282c] kernel_init_freeable+0x12c/0x1e0 [0000000000603764] kernel_init+0x4/0x100 [0000000000405f64] ret_from_syscall+0x1c/0x2c [0000000000000000] (null) 1)Fix the panic; 2)Increment registered port number every successful probe. Signed-off-by: Kirill Tkhai <tkhai@yandex.ru> CC: David Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * tty: serial: fix typo "ARCH_S5P6450"Paul Bolle2013-03-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 827aa0d36d486f359808c8fb931cf7a71011a09d upstream. This could have been either ARCH_S5P64X0 or CPU_S5P6450. Looking at commit 2555e663b367b8d555e76023f4de3f6338c28d6c ("ARM: S5P64X0: Add UART serial support for S5P6450") - which added this typo - makes clear this should be CPU_S5P6450. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250, increase PASS_LIMITJiri Slaby2013-01-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e7328ae1848966181a7ac47e8ae6cddbd2cf55f3 upstream. With virtual machines like qemu, it's pretty common to see "too much work for irq4" messages nowadays. This happens when a bunch of output is printed on the emulated serial console. This is caused by too low PASS_LIMIT. When ISR loops more than the limit, it spits the message. I've been using a kernel with doubled the limit and I couldn't see no problems. Maybe it's time to get rid of the message now? Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Ram Gupta <ram.gupta5@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial:ifx6x60:Delete SPI timer when shut down portchao bi2013-01-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 014b9b4ce84281ccb3d723c792bed19815f3571a upstream. When shut down SPI port, it's possible that MRDY has been asserted and a SPI timer was activated waiting for SRDY assert, in the case, it needs to delete this timer. Signed-off-by: Chen Jun <jun.d.chen@intel.com> Signed-off-by: channing <chao.bi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: set correct baud_base for EXSYS EX-41092 Dual 16950Flavio Leitner2012-10-071-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | commit 26e8220adb0aec43b7acafa0f1431760eee28522 upstream. Apparently the same card model has two IDs, so this patch complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2 adding the missing one. Signed-off-by: Flavio Leitner <fbl@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: pl011: handle corruption at high clock speedsLinus Walleij2012-10-071-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c5dd553b9fd069892c9e2de734f4f604e280fa7a upstream. This works around a few glitches in the ST version of the PL011 serial driver when using very high baud rates, as we do in the Ux500: 3, 3.25, 4 and 4.05 Mbps. Problem Observed/rootcause: When using high baud-rates, and the baudrate*8 is getting close to the provided clock frequency (so a division factor close to 1), when using bursts of characters (so they are abutted), then it seems as if there is not enough time to detect the beginning of the start-bit which is a timing reference for the entire character, and thus the sampling moment of character bits is moving towards the end of each bit, instead of the middle. Fix: Increase slightly the RX baud rate of the UART above the theoretical baudrate by 5%. This will definitely give more margin time to the UART_RX to correctly sample the data at the middle of the bit period. Also fix the ages old copy-paste error in the very stressed comment, it's referencing the registers used in the PL010 driver rather than the PL011 ones. Signed-off-by: Guillaume Jaunet <guillaume.jaunet@stericsson.com> Signed-off-by: Christophe Arnal <christophe.arnal@stericsson.com> Signed-off-by: Matthias Locher <matthias.locher@stericsson.com> Signed-off-by: Rajanikanth HV <rajanikanth.hv@stericsson.com> Cc: Bibek Basu <bibek.basu@stericsson.com> Cc: Par-Gunnar Hjalmdahl <par-gunnar.hjalmdahl@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * pch_uart: Fix parity setting issueTomoya MORINAGA2012-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 38bd2a1ac736901d1cf4971c78ef952ba92ef78b upstream. Parity Setting value is reverse. E.G. In case of setting ODD parity, EVEN value is set. This patch inverts "if" condition. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * pch_uart: Fix rx error interrupt setting issueTomoya MORINAGA2012-10-021-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 9539dfb7ac1c84522fe1f79bb7dac2990f3de44a upstream. Rx Error interrupt(E.G. parity error) is not enabled. So, when parity error occurs, error interrupt is not occurred. As a result, the received data is not dropped. This patch adds enable/disable rx error interrupt code. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * pch_uart: Fix missing break for 16 byte fifoAlan Cox2012-10-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 9bc03743fff0770dc5a5324ba92e67cc377f16ca upstream. Otherwise we fall back to the wrong value. Reported-by: <dcb314@hotmail.com> Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44091 Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * tty: Allow uart_register/unregister/registerAlan Cox2012-06-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | commit 1e66cded334e6cea596c72f6f650eec351b1e959 upstream. This is legitimate but because we don't clear the drv->state pointer in the unregister code causes a bogus BUG(). Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880 Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Add missing call to uart_update_timeout()Lothar Waßmann2012-06-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | commit 8b979f7c6bf13a57e7b6002f1175312a44773960 upstream. This patch fixes a problem reported here: http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auart Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * pch_uart: Fix dma channel unallocated issueTomoya MORINAGA2012-04-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit af6d17cdc8c89aeb3101f0d27cd32fc0592b40b2 upstream. This driver anticipates pch_uart_verify_port() is not called during installation. However, actually pch_uart_verify_port() is called during installation. As a result, memory access violation occurs like below. 0. initial value: use_dma=0 1. starup() - dma channel is not allocated because use_dma=0 2. pch_uart_verify_port() - Set use_dma=1 3. UART processing acts DMA mode because use_dma=1 - memory access violation occurs! This patch fixes the issue. Solution: Whenever pch_uart_verify_port() is called and then dma channel is not allocated, the channel should be allocated. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * ARM: clps711x: serial driver hungs are a result of call disable_irq within ISRAlexander Shiyan2012-04-271-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | commit 7a6fbc9a887193a1e9f8658703881c528040afbc upstream. Since 2.6.30-rc1 clps711x serial driver hungs system. This is a result of call disable_irq from ISR. synchronize_irq waits for end of interrupt and goes to infinite loop. This patch fix this problem. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * 8250_pci: Fix kernel panic when pch_uart is disabledTomoya MORINAGA2012-04-221-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 64d91cfaade2155ad048fe3b65238a052e29dde4 upstream. Currently, ".setup" function is not set. As a result, when detecting our IOH's uart device without pch_uart, kernel panic occurs at the following of pciserial_init_ports(). for (i = 0; i < nr_ports; i++) { if (quirk->setup(priv, board, &serial_port, i)) break; So, this patch adds the ".setup" function. We can use pci_default_setup because our IOH's uart is compatible with 16550. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * pch_uart: Set PCIe bus number using probe parameterTomoya MORINAGA2012-04-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 6c4b47d243112e98811ce0da7bbb32cc3857dd1a upstream. Currently, PCIe bus number is set as fixed value "2". However, PCIe bus number is not always "2". This patch sets bus number using probe() parameter. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: PL011: move interrupt clearingLinus Walleij2012-04-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c3d8b76f61586714cdc5f219ba45592a54caaa55 upstream. Commit 360f748b204275229f8398cb2f9f53955db1503b "serial: PL011: clear pending interrupts" attempts to clear interrupts by writing to a yet-unassigned memory address. This fixes the issue. The breaking patch is marked for stable so should be carried along with the other patch. Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Nicolas Pitre <nico@fluxnic.net> Reported-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: PL011: clear pending interruptsLinus Walleij2012-04-221-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 9b96fbacda34079dea0638ee1e92c56286f6114a upstream. Chanho Min reported that when the boot loader transfers control to the kernel, there may be pending interrupts causing the UART to lock up in an eternal loop trying to pick tokens from the FIFO (since the RX interrupt flag indicates there are tokens) while in practice there are no tokens - in fact there is only a pending IRQ flag. This patch address the issue with a combination of two patches suggested by Russell King that clears and mask all interrupts at probe() and clears any pending error and RX interrupts at port startup time. We suspect the spurious interrupts are a side-effect of switching the UART from FIFO to non-FIFO mode. Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Reported-by: Chanho Min <chanho0207@gmail.com> Suggested-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Jong-Sung Kim <neidhard.kim@lge.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * tty: serial: altera_uart: Check for NULL platform_data in probe.Yuriy Kozlov2012-04-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | commit acede70d6561f2d042d9dbb153d9a3469479c0ed upstream. Follow altera_jtag_uart. This fixes a crash if there is a mistake in the DTS. Signed-off-by: Yuriy Kozlov <ykozlov@ptcusa.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: sh-sci: fix a race of DMA submit_tx on transferYoshii Takashi2012-04-021-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 49d4bcaddca977fffdea8b0b71f6e5da96dac78e upstream. When DMA is enabled, sh-sci transfer begins with uart_start() sci_start_tx() if (cookie_tx < 0) schedule_work() Then, starts DMA when wq scheduled, -- (A) process_one_work() work_fn_rx() cookie_tx = desc->submit_tx() And finishes when DMA transfer ends, -- (B) sci_dma_tx_complete() async_tx_ack() cookie_tx = -EINVAL (possible another schedule_work()) This A to B sequence is not reentrant, since controlling variables (for example, cookie_tx above) are not queues nor lists. So, they must be invoked as A B A B..., otherwise results in kernel crash. To ensure the sequence, sci_start_tx() seems to test if cookie_tx < 0 (represents "not used") to call schedule_work(). But cookie_tx will not be set (to a cookie, also means "used") until in the middle of work queue scheduled function work_fn_tx(). This gap between the test and set allows the breakage of the sequence under the very frequently call of uart_start(). Another gap between async_tx_ack() and another schedule_work() results in the same issue, too. This patch introduces a new condition "cookie_tx == 0" just to mark it is "busy" and assign it within spin-locked region to fill the gaps. Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com> Reviewed-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | tty: omap-serial: Disabling DMA on suspend pathVitaly Chernooky2013-01-161-0/+43
| | | | | | | | | | | | | | | | | | In case of bug UART can't suspend with TX DMA enabled. So here is implemented WA: TX DMA is disabled on runtime suspend path and re-enabled on runtime resume path. Change-Id: Iabc726ca93a5e354eb53efdacedf3261d4e02763 Signed-off-by: Vitaly Chernooky <vitaly.chernooky@ti.com>
* | tty: omap-serial: Enable IDLE MODE on runtime suspendVitaly Chernooky2013-01-161-0/+9
| | | | | | | | | | | | | | | | | | Commit f905c6a0fa5961f6101dbfff837c24c1fdbd2592 forbid idle for uart on runtime resume path if dma is enabled. This patch allow idle on runtime suspend path. Change-Id: If28a79695ad29c07f634ed3ef71f9c9842f27188 Signed-off-by: Vitaly Chernooky <vitaly.chernooky@ti.com>
* | OMAP4: DPLL cascading: Removed deadlock during DPLL cascading transitionIvan Khoronzhuk2012-07-251-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need take a console lock due to change uart frequency. We cannot do it under omap_dvfs_lock because it can lead to deadlock in situation when some thread has taken the console lock and trying to scale waiting for the omap_dvfs_lock that has been taken already by DPLL cascading transition. Example: +--------------------------------------------+--------------------------------+ | thread 1 | thread 2 | +--------------------------------------------+--------------------------------+ | ->omap4_dpll_cascading_blocker_release() { | | | ... | | | mutex_lock(dvfs_lock) | | | ... -> | | | | -> ... | | | console_lock() | | | omap_device_scale() { | | | ... | | | mutex_lock(dvfs_lock) -> | | -> ... | | | console_lock() // deadlock | | +--------------------------------------------+--------------------------------+ Change-Id: I90f7c66ef9d490a4552e94adddf2e2eb79c58b99 Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
* | OMAP4: DPLL cascading: Recalibrate Baud Rates for UARTs when the DPLL freq ↵Ruchika Kharwar2012-06-181-1/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | changes This patch attached the callbacks to DPLL framework to recalib. the baud rates of all the UART's base on the functional clock chnages in the DPLL cascading Low Power mode. [Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>: Ported and adapted to p-android-omap-3.0] Change-Id: If60b3287934f8d780b72b3aa68cbeccd52f99658 Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
* | OMAP4: DPLL cascading: applying hold/release API to serial driverAndrii Tseglytskyi2012-06-181-0/+57
| | | | | | | | | | | | | | | | Serial driver can block DPLL cascading only form non-atomic context, if any external device uses UART. Change-Id: I56d31a296b8a644cb2cf066b4aa7b22d2c07027a Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
* | Merge latest changes from google kernel/common.gitRoman Shaposhnikov2012-06-136-19/+46
| | | | | | | | | | | | | | Kernel version updated to 3.0.31 Change-Id: Ifbd7150801f3beeec9cbaa566f249d8019ef9348 Signed-off-by: Roman Shaposhnikov <x0166637@ti.com>
* | serial_core: used uninitialized termios when port-tty is unsetIvan Khoronzhuk2012-04-131-4/+7
| | | | | | | | | | | | | | | | | | | | There is no reason to pass the termios struct to the uport->ops->set_termios() when it is filled with zeros. It leads to corruption of uart registers. Change-Id: I2cc2c07c3ada6caf35b93d69ac9949b99ca145a5 Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
* | Merge branch 'android-omap-3.0' into p-android-omap-3.0Dan Murphy2012-02-161-17/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/mach-omap2/Kconfig arch/arm/mach-omap2/clock44xx_data.c arch/arm/mach-omap2/omap_twl.c drivers/gpu/pvr/ion.c drivers/gpu/pvr/ion.h drivers/gpu/pvr/mm.c drivers/gpu/pvr/omap4/syslocal.h drivers/gpu/pvr/sgxfeaturedefs.h drivers/mmc/host/omap_hsmmc.c drivers/usb/gadget/android.c drivers/video/hdmi_ti_4xxx_ip.c drivers/video/omap2/dss/dispc.c drivers/video/omap2/dss/hdmi.c fs/proc/base.c include/video/hdmi_ti_4xxx_ip.h sound/soc/codecs/twl6040.c sound/soc/omap/sdp4430.c Change-Id: Ia1edb1885eff7554aead12780898502df08b7c83 Signed-off-by: Dan Murphy <dmurphy@ti.com>
* | serial: Fix wakeup init logic to speed up startupSimon Glass2012-02-081-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The synchronize_rcu() call resulting from making every serial driver wake-up capable (commit b3b708fa) slows boot down on my Tegra2x system (with CONFIG_PREEMPT disabled). But this is avoidable since it is the device_set_wakeup_enable() and then subsequence disable which causes the delay. We might as well just make the device wakeup capable but not actually enable it for wakeup until needed. Effectively the current code does this: device_set_wakeup_capable(dev, 1); device_set_wakeup_enable(dev, 1); device_set_wakeup_enable(dev, 0); We can just drop the last two lines. Before this change my boot log says: [ 0.227062] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 0.702928] serial8250.0: ttyS0 at MMIO 0x70006040 (irq = 69) is a Tegra after: [ 0.227264] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 0.227983] serial8250.0: ttyS0 at MMIO 0x70006040 (irq = 69) is a Tegra for saving of 450ms. Change-Id: I1bab007560d888b9fc341efc25bb9cd332be16df Suggested-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Huzefa Kankroliwala <huzefank@ti.com>
* | Merge branch 'linux-3.0.19' into p-android-omap-3.0Dan Murphy2012-02-062-0/+15
|\ \ | |/ | | | | Signed-off-by: Dan Murphy <dmurphy@ti.com>
| * jsm: Fixed EEH recovery errorLucas Kannebley Tavares2012-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 26aa38cafae0dbef3b2fe75ea487c83313c36d45 upstream. There was an error on the jsm driver that would cause it to be unable to recover after a second error is detected. At the first error, the device recovers properly: [72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0 [72521.485695] EEH: This PCI device has failed 1 times in the last hour: ... [72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm [72532.105689] jsm: Port 3 added However, at the second error, it cascades until EEH disables the device: [72631.229549] Call Trace: ... [72641.725687] jsm: Port 3 added [72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0 [72641.725698] EEH: This PCI device has failed 3 times in the last hour: It was caused because the PCI state was not being saved after the first restore. Therefore, at the second recovery the PCI state would not be restored. Signed-off-by: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com> Signed-off-by: Breno Leitao <brenohl@br.ibm.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: amba-pl011: lock console writes against interruptsRabin Vincent2012-02-031-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ef605fdb33883d687cff5ba75095a91b313b4966 upstream. Protect against pl011_console_write() and the interrupt for the console UART running concurrently on different CPUs. Otherwise the console_write could spin for a long time waiting for the UART to become not busy, while the other CPU continuously services UART interrupts and keeps the UART busy. The checks for sysrq and oops_in_progress are taken from 8250.c. Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com> Reviewed-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Reviewed-by: Bibek Basu <bibek.basu@stericsson.com> Reviewed-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge branch 'linux-3.0.18' into p-android-omap-3.0Dan Murphy2012-02-0210-116/+73
|\ \ | |/ | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/mach-omap2/smartreflex.c drivers/i2c/busses/i2c-omap.c drivers/usb/host/ehci.h drivers/usb/musb/musb_core.c fs/proc/base.c Signed-off-by: Dan Murphy <dmurphy@ti.com>
| * atmel_serial: fix spinlock lockup in RS485 codeClaudio Scordino2012-01-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit dbf1115d3f8c7052788aa4e6e46abd27f3b3eeba upstream. Patch to fix a spinlock lockup in the driver that sometimes happens when the tasklet starts. Signed-off-by: Claudio Scordino <claudio@evidence.eu.com> Signed-off-by: Dave Bender <codehero@gmail.com> Tested-by: Dave Bender <codehero@gmail.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * pch_uart: Support new device LAPIS Semiconductor ML7831 IOHTomoya MORINAGA2011-11-262-7/+15
| | | | | | | | | | | | | | | | | | | | | | commit 8249f743f732ccbc3056428945ab1d9bd36d46bf upstream. ML7831 is companion chip for Intel Atom E6xx series. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * pch_uart: Fix DMA resource leak issueTomoya MORINAGA2011-11-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 90f04c2926cfb5bf74533b0a7766bc896f6a0c0e upstream. Changing UART mode PIO->DMA->PIO->DMA like below, pch_uart driver can't get DMA channel resource. setserial /dev/ttyPCH0 ^low_latency setserial /dev/ttyPCH0 low_latency CAUSE: Changing mode using setserial command, ".startup" function which gets DMA channel is called before ".verify_port" function which sets dma-flag(use_dma/use_dma_flag) as 1. PIO->DMA .startup: Since dma-flag is 0, DMA channel is not requested. .verify_port: dma-flag is set as 1. .shutdown: N/A DMA->PIO .startup: Since dma-flag is 1, DMA channel is requested. .verify_port: dma-flag is set as 0. .shutdown: Since dma-flag is 0, DMA channel is not released. This means DMA channel resource leak occurs. Next time, this driver can't get DMA channel resource forever. MODIFICATION: Currently, when release DMA channel resource, this driver checks dma-flag. However, this specification occurs the above issue. This driver must check whether dma_request_channel is executed or not. The values are saved in private data variable "chan_tx/chan_tx". These variables mean if the value is NULL, DMA channel is not requested, if not NULL, DMA channel is requested. This patch fixes the issue. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * pch_uart: Fix hw-flow control issueTomoya MORINAGA2011-11-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit a1d7cfe29f13cf45f8094929864b9c66bf0cd91b upstream. Using hardware flow control, currently, register of the control-bit(AFE) is not set. This patch fixes the issue. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * jsm: remove buggy write queueThadeu Lima de Souza Cascardo2011-11-114-103/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 9d898966c4a07e4a5092215b5a2829d0ef02baa2 upstream. jsm uses a write queue that copies from uart_core circular buffer. This copying however has some bugs, like not wrapping the head counter. Since this write queue is also a circular buffer, the consumer function is ready to use the uart_core circular buffer directly. This buggy copying function was making some bytes be dropped when transmitting to a raw tty, doing something like this. [root@hostname ~]$ cat /dev/ttyn1 > cascardo/dump & [1] 2658 [root@hostname ~]$ cat /proc/tty/drivers > /dev/ttyn0 [root@hostname ~]$ cat /proc/tty/drivers /dev/tty /dev/tty 5 0 system:/dev/tty /dev/console /dev/console 5 1 system:console /dev/ptmx /dev/ptmx 5 2 system /dev/vc/0 /dev/vc/0 4 0 system:vtmaster jsm /dev/ttyn 250 0-31 serial serial /dev/ttyS 4 64-95 serial hvc /dev/hvc 229 0-7 system pty_slave /dev/pts 136 0-1048575 pty:slave pty_master /dev/ptm 128 0-1048575 pty:master unknown /dev/tty 4 1-63 console [root@hostname ~]$ cat cascardo/dump /dev/tty /dev/tty 5 0 system:/dev/tty /dev/console /dev/console 5 1 system:console /dev/ptmx /dev/ptmx 5 2 system /dev/vc/0 /dev/vc/0 4 0 system:vtmaste[root@hostname ~]$ This patch drops the driver write queue entirely, using the circular buffer from uart_core only. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * serial-core: power up uart port early before we do set_termios when resumingNing Jiang2011-11-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 94abc56f4d90f289ea32a0a11d3577fcd8cb28fb upstream. The following patch removed uart_change_pm() in uart_resume_port(): commit 5933a161abcb8d83a2c145177f48027c3c0a8995 Author: Yin Kangkai <kangkai.yin@linux.intel.com> serial-core: reset the console speed on resume It will break the pxa serial driver when the system resumes from suspend mode as it will try to set baud rate divider register in set_termios but with clock off. The register value can not be set correctly on some platform if the clock is disabled. The pxa driver will check the value and report the following warning: ------------[ cut here ]------------ WARNING: at drivers/tty/serial/pxa.c:545 serial_pxa_set_termios+0x1dc/0x250() Modules linked in: [<c0281f30>] (unwind_backtrace+0x0/0xf0) from [<c029341c>] (warn_slowpath_common+0x4c/0x64) [<c029341c>] (warn_slowpath_common+0x4c/0x64) from [<c029344c>] (warn_slowpath_null+0x18/0x1c) [<c029344c>] (warn_slowpath_null+0x18/0x1c) from [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) from [<c044a840>] (uart_resume_port+0x128/0x2dc) [<c044a840>] (uart_resume_port+0x128/0x2dc) from [<c044bbe0>] (serial_pxa_resume+0x18/0x24) [<c044bbe0>] (serial_pxa_resume+0x18/0x24) from [<c0454d34>] (platform_pm_resume+0x40/0x4c) [<c0454d34>] (platform_pm_resume+0x40/0x4c) from [<c0457ebc>] (pm_op+0x68/0xb4) [<c0457ebc>] (pm_op+0x68/0xb4) from [<c0458368>] (device_resume+0xb0/0xec) [<c0458368>] (device_resume+0xb0/0xec) from [<c04584c8>] (dpm_resume+0xe0/0x194) [<c04584c8>] (dpm_resume+0xe0/0x194) from [<c0458588>] (dpm_resume_end+0xc/0x18) [<c0458588>] (dpm_resume_end+0xc/0x18) from [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) from [<c02c5278>] (enter_state+0xac/0xdc) [<c02c5278>] (enter_state+0xac/0xdc) from [<c02c48ec>] (state_store+0xa0/0xbc) [<c02c48ec>] (state_store+0xa0/0xbc) from [<c0408f7c>] (kobj_attr_store+0x18/0x1c) [<c0408f7c>] (kobj_attr_store+0x18/0x1c) from [<c034a6a4>] (sysfs_write_file+0x108/0x140) [<c034a6a4>] (sysfs_write_file+0x108/0x140) from [<c02fb798>] (vfs_write+0xac/0x134) [<c02fb798>] (vfs_write+0xac/0x134) from [<c02fb8cc>] (sys_write+0x3c/0x68) [<c02fb8cc>] (sys_write+0x3c/0x68) from [<c027c700>] (ret_fast_syscall+0x0/0x2c) ---[ end trace 88289eceb4675b04 ]--- This patch fix the problem by adding the power on opertion back for uart console when console_suspend_enabled is true. Signed-off-by: Ning Jiang <ning.jiang@marvell.com> Tested-by: Mayank Rana <mrana@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * serial: pxa: work around for errata #20Marcus Folkesson2011-11-111-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | commit e44aabd649c80e8be16ede3ed3cbff6fb2561ca9 upstream. Errata E20: UART: Character Timeout interrupt remains set under certain software conditions. Implication: The software servicing the UART can be trapped in an infinite loop. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * cris: fix a build error in drivers/tty/serial/crisv10.cWANG Cong2011-11-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2f7861de111bb8e33e6ab9f9607583c6fbc00132 upstream. This patch fixes the following build error: drivers/tty/serial/crisv10.c:4453: error: 'if_ser0' undeclared (first use in this function): 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig drivers/tty/serial/crisv10.c:4453: error: (Each undeclared identifier is reported only once: 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig drivers/tty/serial/crisv10.c:4453: error: for each function it appears in.): 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig "if_ser0" is a typo, it should be "if_serial_0". Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | omap: uart: scr register restoreruchika kharwar2011-12-141-1/+1
| | | | | | | | | | | | | | | | | | Since the scr register is used in either cases i.e. DMA and non DMA. The scr register needs restoration in either case as well. Change-Id: I850c518beb8062303bad1c1a1386bcefc60f008b Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
* | omap: uart: wer restorationruchika kharwar2011-12-141-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The WER value for a uart port is restored properly in either case Case 1: The port is started, the device enters off mode and resumes. In this case wer is restored with the intended board defined value. Case 2: The port is started, shutdown, the device enters off mode and resumes. In this case wer is restored with zero. This prevents events from being registered in the uart hardware which will not be handled by a port that is not started in software. Change-Id: I5dd426b2cdb8925404f6ba7fc83569b49bda1695 Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
* | OMAP4: UART: scr register usage addedruchika kharwar2011-11-231-5/+4
| | | | | | | | | | | | | | | | | | The SCR register is set to enable TX interrupts only when the FIFO is empty. This prevents a large number of spurious interrupts. Change-Id: I730a1ccb56c7d43dbae45bcd5226587d8d29863f Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
* | Revert "tty: serial: omap-serial: fix tx fifo writes"Leed Aguilar2011-11-231-11/+7
| | | | | | | | | | | | | | | | Fill the TX FIFO with 16 bytes instead of 64 bytes to avoid FIFO overruns. This reverts commit 56b0c634c4ca2dc8da7a159cc8db68c9d3652f82. Signed-off-by: Leed Aguilar <leed.aguilar@ti.com>
* | OMAP4: UART: Revert TX fifo level checkingLeed Aguilar2011-11-231-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverting the following patch since TX fifo data size will be changed from 64 bytes to 16 bytes: OMAP4: UART: HACK: Eliminated TX fifo level checking Reverting the following patch to remove "HACK" from the patch subject OMAP4: UART: HACK: scr register usage added Change-Id: I120faa4365ad85c94033b873b248d8cc88844f68 Signed-off-by: Leed Aguilar <leed.aguilar@ti.com>
generated by cgit v1.1 at 2025-08-16 09:52:55 +0000