- 25 2月, 2012 5 次提交
-
-
由 Chanho Min 提交于
In DMA-operated uart, I found that rx data can be taken by the UART interrupts during the DMA irq handler. pl011_int is occurred just before it goes inside spin_lock_irq. When it returns to the callback, DMA buffer already has been flushed. Then, pl011_dma_rx_chars gets invalid data. So I add check for the residue as the patch bellow. Signed-off-by: NChanho Min <chanho.min@lge.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Denis 'GNUtoo' Carikli 提交于
Without that fix machines having a s3c2442 CPU have something like that in dmesg: samsung-uart s3c2440-uart.0: could not find driver data samsung-uart s3c2440-uart.1: could not find driver data samsung-uart s3c2440-uart.2: could not find driver data And serial is never initialized. The previous log was obtained trough early printk on the gta02 machine. Signed-off-by: NDenis 'GNUtoo' Carikli <GNUtoo@no-log.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Stephen Rothwell 提交于
Fixes these build errors: ERROR: ".udbg_printf" [drivers/tty/ehv_bytechan.ko] undefined! ERROR: ".register_early_udbg_console" [drivers/tty/ehv_bytechan.ko] undefined! ERROR: "udbg_putc" [drivers/tty/ehv_bytechan.ko] undefined! Cc: Timur Tabi <timur@freescale.com> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Masanari Iida 提交于
Correct spelling "receieve" to "receive" in drivers/tty/serial/sn_console.c Signed-off-by: NMasanari Iida <standby24x7@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Danny Kukawka 提交于
drivers/tty/serial/mux.c included 'linux/tty.h' twice, remove the duplicate. Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 2月, 2012 1 次提交
-
-
由 Paul Gortmaker 提交于
There are multiple users of this file from different source paths now, and rather than have ../ paths in include statements, just move the file to the linux header dir. Suggested-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 2月, 2012 10 次提交
-
-
由 Paul Walmsley 提交于
The receive FIFO wakeup latency estimate in the omap-serial driver is three orders of magnitude too small. This effectively prevents the MPU from going to a low-power state when CONFIG_CPU_IDLE=y. This is a major power management regression and masks some other FIFO-related bugs in the driver. Fix by correcting the most egregious problem in the RX wakeup latency estimate. There are several other flaws in the estimator; these will be fixed by a separate patch series intended for 3.4. The difference in low-power states with this patch can be observed via debugfs in pm_debug/count. This estimate does not have any effect when CONFIG_CPU_IDLE=n. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Alan Cox <alan@linux.intel.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Paul Walmsley 提交于
Prevent OMAP UARTs from going idle while they are still transferring data in PIO mode. This works around an oversight in the OMAP UART hardware present in OMAP34xx and earlier: an idle UART won't send a wakeup when the TX FIFO threshold is reached. This causes long delays during data transmission when the MPU powerdomain enters a low-power mode. The MPU interrupt controller is not able to respond to interrupts when it's in a low-power state, so the TX buffer is not refilled until another wakeup event occurs. This fix changes the erratum i291 DMA idle workaround. Rather than toggling between force-idle and no-idle, it will toggle between smart-idle and no-idle. The important part of the workaround is the no-idle part, so this shouldn't result in any change in behavior. This fix should work on all OMAP UARTs. Future patches intended for the 3.4 merge window will make this workaround conditional on a "feature" flag, and will use the OMAP36xx+ TX event wakeup support. Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291 workaround, which led to the development of this approach. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Paul Walmsley 提交于
In the (default) PIO mode, use a one-byte RX FIFO threshold. The OMAP UART IP blocks do not appear to be capable of waking the system under an RX timeout condition. Since the previous RX FIFO threshold was 16 bytes, this meant that omap-serial.c did not become aware of any received data until all those bytes arrived or until another UART interrupt occurred. This made the serial console and presumably other serial applications (GPS, serial Bluetooth) unusable or extremely slow. A 1-byte RX FIFO threshold also allows the MPU to enter a low-power consumption state while waiting for the FIFO to fill. This can be verified using the serial console by comparing the behavior when "0123456789abcde" is pasted in from another window, with the behavior when "0123456789abcdef" is pasted in. Since the former string is less than sixteen bytes long, the string is not echoed for some time, while the latter string is echoed immediately. DMA operation is unaffected by this patch. Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for some additional information on the standard behavior of the RX timeout event, which was used to improve this commit description. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Govindraj Raja <govindraj.r@ti.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Russell King <linux@arm.linux.org.uk> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Tobias Klauser 提交于
This allows altera_uart to be used for KGDB debugging over serial line. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Tobias Klauser 提交于
The function has no users inside the tree and the nios2 (out-of-mainline) port doesn't use it either (anymore). Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Anton Vorontsov 提交于
There's a real possibility of killing kernel threads that might have issued use_mm(), so kthread's mm might become non-NULL. This patch fixes the issue by checking for PF_KTHREAD (just as get_task_mm()). Suggested-by: NOleg Nesterov <oleg@redhat.com> Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org> Acked-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Anton Vorontsov 提交于
sysrq should grab the tasklist lock, otherwise calling force_sig() is not safe, as it might race with exiting task, which ->sighand might be set to NULL already. Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org> Acked-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Feng Tang 提交于
pch_uart_hal_request() has parameters which it never uses, also it is very short, so merge it with its caller to make code cleaner. No functional changes at all. Signed-off-by: NFeng Tang <feng.tang@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Feng Tang 提交于
The short get_msr() has some unnecessary code and only used once, so merge it with its caller to make code cleaner. No functional change at all. Signed-off-by: NFeng Tang <feng.tang@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Feng Tang 提交于
This driver will be use as interfaces for multiple kinds of devices like Bluetooth/GPS etc, this debug hook will make driver debugging much easier. Signed-off-by: NFeng Tang <feng.tang@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 09 2月, 2012 1 次提交
-
-
由 Paul Gortmaker 提交于
Commit 9bef3d41 "serial: group all the 8250 related code together" inadvertently swept up the m32r driver in the move, because it had comments mentioning 8250 registers within it. However these are only there by nature of the driver being based off the 8250 source code -- the hardware itself does not actually have any relation to the original 8250 style UARTs. Reported-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 2月, 2012 2 次提交
-
-
由 Samuel Thibault 提交于
KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland with a 64bit kernel if the font width is not 8. This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes con_font_get return EIO in such case. This flag should *not* be set for KDFONTOP, since it's actually the whole point of this flag (see comment in con_font_set for instance). Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: NArnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Arthur Taylor <art@ified.ca> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Jiri Olsa <jolsa@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Cong Wang 提交于
On sparc, there is a build failure: drivers/tty/serial/8250/8250.c:48:21: error: suncore.h: No such file or directory drivers/tty/serial/8250/8250.c:3275: error: implicit declaration of function 'sunserial_register_minors' drivers/tty/serial/8250/8250.c:3305: error: implicit declaration of function 'sunserial_unregister_minors' this is due to commit 9bef3d41 (serial: group all the 8250 related code together) moved these files into 8250/ subdirectory, but forgot to change the reference to drivers/tty/serial/suncore.h. Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 2月, 2012 10 次提交
-
-
由 Kukjin Kim 提交于
Cc: Thomas Abraham <thomas.abraham@linaro.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Kukjin Kim 提交于
This should be added for EXYNOS4212 and EXYNOS4412 SoCs. Cc: Thomas Abraham <thomas.abraham@linaro.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Samuel Thibault 提交于
KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland with a 64bit kernel if the font width is not 8. This is because the compatibility layer introduced by e9216651 ("tty: handle VT specific compat ioctls in vt driver") forces the addition of the KD_FONT_FLAG_OLD flag, which makes con_font_get return EIO in such case. This flag should *not* be set for KDFONTOP, since it's actually the whole point of this flag (see comment in con_font_set for instance). Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Arthur Taylor <art@ified.ca> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Jiri Olsa <jolsa@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
devpts operations are protected by inode mutexes and dentry refcounting. There is no need to hold BTM. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
The code looks like: if (tty->driver->subtype == PTY_TYPE_MASTER) { ... if (tty->driver == ptm_driver) But the second if is superfluous because only the ptm_driver is of PTY_TYPE_MASTER subtype. Also we can remove the #if now because devpts_pty_kill is defined as an empty function for non-CONFIG_UNIX98_PTYS configs. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
Use the helper in the rest of the tty drivers. This is a simple replacement. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
There are currently many cut&paste copies of what tty_driver_install_tty does when custom ->install method is not provided. Let's get rid of the copies and create a helper with this setup code. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Cc: Havard Skinnemoen <hskinnemoen@google.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Paul Walmsley 提交于
The receive FIFO wakeup latency estimate in the omap-serial driver is three orders of magnitude too small. This effectively prevents the MPU from going to a low-power state when CONFIG_CPU_IDLE=y. This is a major power management regression and masks some other FIFO-related bugs in the driver. Fix by correcting the most egregious problem in the RX wakeup latency estimate. There are several other flaws in the estimator; these will be fixed by a separate patch series intended for 3.4. The difference in low-power states with this patch can be observed via debugfs in pm_debug/count. This estimate does not have any effect when CONFIG_CPU_IDLE=n. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Alan Cox <alan@linux.intel.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Paul Walmsley 提交于
Prevent OMAP UARTs from going idle while they are still transferring data in PIO mode. This works around an oversight in the OMAP UART hardware present in OMAP34xx and earlier: an idle UART won't send a wakeup when the TX FIFO threshold is reached. This causes long delays during data transmission when the MPU powerdomain enters a low-power mode. The MPU interrupt controller is not able to respond to interrupts when it's in a low-power state, so the TX buffer is not refilled until another wakeup event occurs. This fix changes the erratum i291 DMA idle workaround. Rather than toggling between force-idle and no-idle, it will toggle between smart-idle and no-idle. The important part of the workaround is the no-idle part, so this shouldn't result in any change in behavior. This fix should work on all OMAP UARTs. Future patches intended for the 3.4 merge window will make this workaround conditional on a "feature" flag, and will use the OMAP36xx+ TX event wakeup support. Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291 workaround, which led to the development of this approach. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Paul Walmsley 提交于
In the (default) PIO mode, use a one-byte RX FIFO threshold. The OMAP UART IP blocks do not appear to be capable of waking the system under an RX timeout condition. Since the previous RX FIFO threshold was 16 bytes, this meant that omap-serial.c did not become aware of any received data until all those bytes arrived or until another UART interrupt occurred. This made the serial console and presumably other serial applications (GPS, serial Bluetooth) unusable or extremely slow. A 1-byte RX FIFO threshold also allows the MPU to enter a low-power consumption state while waiting for the FIFO to fill. This can be verified using the serial console by comparing the behavior when "0123456789abcde" is pasted in from another window, with the behavior when "0123456789abcdef" is pasted in. Since the former string is less than sixteen bytes long, the string is not echoed for some time, while the latter string is echoed immediately. DMA operation is unaffected by this patch. Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for some additional information on the standard behavior of the RX timeout event, which was used to improve this commit description. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Govindraj Raja <govindraj.r@ti.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Russell King <linux@arm.linux.org.uk> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 27 1月, 2012 5 次提交
-
-
由 Alan Cox 提交于
We transform the offenders into a test of irq <= 0 which will be ok while the ARM people get their platform sorted. Once that is done (or in a while if they don't do it anyway) then we will change them all to !irq checks. For arch specific drivers that are already using NO_IRQ = 0 we just test against zero so we don't need to re-review them later. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Uwe Kleine-König 提交于
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
All production devices operate in the Oaktrail configuration with legacy PC elements present and an ACPI BIOS. Continue stripping out the Moorestown elements from the tree leaving Medfield. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This reverts commit 0a697b22 as Paul wants to rework it. Cc: Paul Walmsley <paul@pwsan.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Govindraj Raja <govindraj.r@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This reverts commit 43cf7c0b as Paul wants to redo it. Cc: Paul Walmsley <paul@pwsan.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Govindraj Raja <govindraj.r@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 25 1月, 2012 6 次提交
-
-
由 Simon Glass 提交于
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. Suggested-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Rabin Vincent 提交于
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. Cc: stable <stable@vger.kernel.org> Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com> Reviewed-by: NSrinidhi Kasagar <srinidhi.kasagar@stericsson.com> Reviewed-by: NBibek Basu <bibek.basu@stericsson.com> Reviewed-by: NShreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Shreshtha Kumar Sahu 提交于
In present driver, shutdown clears RTS and DTR in CR register. But the documentation "Documentation/serial/driver" suggests not to disable RTS and DTR in shutdown(). Also RTS and DTR is preserved between shutdown and startup calls, i.e. these are restored in startup if they were enabled while doing shutdown. So that if RTS and DTR are set using pl011_set_mctrl then it should continue even after shutdown->startup sequence. For throttling/unthrottling user should call pl011_set_mctrl. Signed-off-by: NShreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Paul Walmsley 提交于
It seems that when the transmit FIFO threshold is reached on OMAP UARTs, it does not result in a PRCM wakeup. This appears to be a silicon bug. This means that if the MPU powerdomain is in a low-power state, the MPU will not be awakened to refill the FIFO until the next interrupt from another device. The best solution, at least for the short term, would be for the OMAP serial driver to call a OMAP subarchitecture function to prevent the MPU powerdomain from entering a low power state while the FIFO has data to transmit. However, we no longer have a clean way to do this, since patches that add platform_data function pointers have been deprecated by the OMAP maintainer. So we attempt to work around this as well. The workarounds depend on the setting of CONFIG_CPU_IDLE. When CONFIG_CPU_IDLE=n, the driver will now only transmit one byte at a time. This causes the transmit FIFO threshold interrupt to stay active until there is no more data to be sent. Thus, the MPU powerdomain stays on during transmits. Aside from that energy consumption penalty, each transmitted byte results in a huge number of UART interrupts -- about five per byte. This wastes CPU time and is quite inefficient, but is probably the most expedient workaround in this case. When CONFIG_CPU_IDLE=y, there is a slightly more direct workaround: the PM QoS constraint can be abused to keep the MPU powerdomain on. This results in a normal number of interrupts, but, similar to the above workaround, wastes power by preventing the MPU from entering WFI. Future patches are planned for the 3.4 merge window to implement more efficient, but also more disruptive, workarounds to these problems. DMA operation is unaffected by this patch. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Govindraj Raja <govindraj.r@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Paul Walmsley 提交于
Ensure FIFO levels are set correctly in non-DMA mode (the default). This patch will cause a receive FIFO threshold interrupt to be raised when there is at least one byte in the RX FIFO. It will also cause a transmit FIFO threshold interrupt when there is only one byte remaining in the TX FIFO. These changes fix the receive interrupt problem and part of the transmit interrupt problem. A separate set of issues must be worked around for the transmit path to have a basic level of functionality; a subsequent patch will address these. DMA operation is unaffected by this patch. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Govindraj Raja <govindraj.r@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Shubhrajyoti D 提交于
The function serial_omap_restore_context is called only from serial_omap_runtime_resume which depends on CONFIG_PM_RUNTIME. Make serial_omap_restore_context also compile conditionally. if CONFIG_PM_RUNTIME is not defined below warn may be seen. LD net/xfrm/built-in.o drivers/tty/serial/omap-serial.c:1524: warning: 'serial_omap_restore_context' defined but not used CC drivers/tty/vt/selection.o Acked-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-