- 25 Jan, 2017 6 commits
-
-
Manuel Schölling authored
Add a scrollback buffers for each VGA console. The benefit is that the scrollback history is not flushed when switching between consoles but is persistent. The buffers are allocated on demand when a new console is opened. This breaks tools like clear_console that rely on flushing the scrollback history by switching back and forth between consoles which is why this feature is disabled by default. Use the escape sequence \e[3J instead for flushing the buffer. Signed-off-by:
Manuel Schölling <manuel.schoelling@gmx.de> Reviewed-by:
Andrey Utkin <andrey_utkin@fastmail.com> Tested-by:
Adam Borowski <kilobyte@angband.pl> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Manuel Schölling authored
This new callback is in preparation for persistent scrollback buffer support for VGA consoles. With a single scrollback buffer for all consoles, we could flush the buffer just by invocating consw->con_switch(). But when each VGA console has its own scrollback buffer, we need a new callback to tell the video console driver which buffer to flush. Signed-off-by:
-
Manuel Schölling authored
This refactoring is in preparation for persistent scrollback support for VGA console. Signed-off-by:
-
Tony Lindgren authored
Otherwise the interconnect related code implementing PM runtime will produce these errors on a failed probe: omap_uart 48066000.serial: omap_device: omap_device_enable() called from invalid state 1 omap_uart 48066000.serial: use pm_runtime_put_sync_suspend() in driver? Note that we now also need to check for priv in omap8250_runtime_suspend() as it has not yet been registered if probe fails. And we need to use pm_runtime_put_sync() to properly idle the device like we already do in omap8250_remove(). Fixes: 61929cf0 ("tty: serial: Add 8250-core based omap driver") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Paul Gortmaker authored
Currently this warning is triggered for allmodconfig on m68k. It is well intentioned, in that if you are building the driver but not enabling one of the platforms where the hardware exists, you get a warning. The warning dates back to pre-git days, and now we have COMPILE_TEST so we can use that to mask the warning for people who are obviously just doing build coverage on tree wide changes. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-m68k@lists.linux-m68k.org Cc: linux-serial@vger.kernel.org Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Yasir-Khan authored
This patch adds xilinx uart loopback support by modifying the cdns_uart_set_mctrl function to handle the switch to loopback mode. After this patch, the loopback mode can be enabled/disabled by setting/clearing the TIOCM_LOOP modem bit via TIOCMBIS/TIOCMBIC ioctls respectively. Signed-off-by:
Yasir-Khan <yasir_khan@mentor.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
- 20 Jan, 2017 3 commits
-
-
Vignesh R authored
8250 UART DMA support was marked broken by default as it was not possible to pause ongoing RX DMA transfer. Now that both SDMA and EDMA can support pause operation for RX DMA transactions, don't set rx_dma_broken to true by default. With this patch 8250_omap driver will use DMA by default. Signed-off-by:
Vignesh R <vigneshr@ti.com> Acked-by:
-
Vignesh R authored
UART uses as EDMA as dma engine on AM437x SoC and therefore, requires OMAP_DMA_TX_KICK quirk just like AM33xx. So, enable OMAP_DMA_TX_KICK quirk for AM437x platform as well. While at that, drop use of of_machine_is_compatible() and instead pass quirks via device data. Signed-off-by:
-
Vignesh R authored
It is possible that DMA transfer is already complete but, completion handler is yet to be called, when dmaengine_pause() is called in case of error condition(like break/rx timeout). This leads to dmaengine_pause() API to return EINVAL (as descriptor is already NULL) causing rx_dma_broken flag to be set and effectively disabling RX DMA. Fix this by calling dmaengine_pause() only when transfer is in progress. Signed-off-by:
-
- 19 Jan, 2017 31 commits
-
-
Rob Herring authored
This is needed to work with the client operations which uses const ptrs. Really, the flags pointer could be const, too, but this would be a tree wide fix. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-By:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Rob Herring authored
tty_register_device is just a wrapper for tty_register_device_attr with NULL passed for drvdata and attr_grp. So similarly make tty_port_register_device a wrapper of tty_port_register_device_attr so that additions don't have to be made in both functions. Signed-off-by:
-
Alan Cox authored
Let us create tty objects entirely in kernel space. Untested proposal to show why all the ideas around rewriting half the uart stack are not needed. With this a kernel created non file backed tty object could be used to handle data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in particular has to work back to the fs/tty layer. The tty_port code is however otherwise clean of file handles as far as I can tell as is the low level tty port write path used by the ldisc, the configuration low level interfaces and most of the ldiscs. Currently you don't have any exposure to see tty hangups because those are built around the file layer. However a) it's a fixed port so you probably don't care about that b) if you do we can add a callback and c) you almost certainly don't want the userspace tear down/rebuild behaviour anyway. This should however be sufficient if we wanted for example to enumerate all the bluetooth bound fixed ports via ACPI and make them directly available. It doesn't deal with the case of a user opening a port that's also kernel opened and that would need some locking out (so it returned EBUSY if bound to a kernel device of some kind). That needs resolving along with how you "up" or "down" your new bluetooth device, or enumerate it while providing the existing tty API to avoid regressions (and to debug). Signed-off-by:
Alan Cox <alan@linux.intel.com> Reviewed-by:
-
Martin Blumenstingl authored
The vendor driver allows setting baud-rates higher than 115200 baud. There is a check in the vendor driver which prevents using more than 115200 baud during startup, however it does not have such a check in .set_termios. Higher baud-rates are often used by the bluetooth modules embedded into the SDIO wifi chips (Amlogic devices use brcmfmac based wifi chips quite often, 2000000 baud seems to be a common value for the UART baud-rate in Amlogic's "libbt"). I have tested this on a Meson GXL device with uart_A (to which the bluetooth module is connected, where initialization times out with 115200 baud) and uart_AO (which I manually set to 2000000 baud and then connected with my USB UART adapter to that). Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Kevin Hilman <khilman@baylibre.com> Tested-by:
Andreas Färber <afaerber@suse.de> Signed-off-by:
-
Rob Herring authored
For in-kernel tty users, we need to be able to create and destroy 'struct tty' that are not associated with a file. The creation side is fine, but tty_release() needs to be split into the file handle portion and the struct tty portion. Introduce a new function, tty_release_struct, to handle just the destroying of a struct tty. Signed-off-by:
-
Arvind Yadav authored
Here, If ioremap_nocache will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Lokesh Vutla authored
Add DT earlycon for omap_serial driver. This boot console is included with CONFIG_SERIAL_EARLYCON=y, CONFIG_OF=y, CONFIG_SERIAL_OMAP=y, and CONFIG_OF_EARLY_FLATTREE=y. This boot console is enabled with the command line option "earlycon" (without "=<name>...") when the DT 'stdout-path' property matches a compatible uart. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
-
Alexander Sverdlin authored
Exactly as in a80c49db ("serial8250: Mark console as CON_ANYTIME"), to enable printk() during CPU hot-plugging. Actually most of the serial console drivers do not use per-cpu resources and can be marked as CON_ANYTIME. Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-serial@vger.kernel.org Signed-off-by:
-
Bhumika Goyal authored
Declare dev_pm_ops structures as const as they are only stored in the pm field of a device_driver structure. This field is of type const, so dev_pm_ops structures having similar properties can be declared const too. Size details after cross compiling the .o file for blackfin architecture. File size before: text data bss dec hex filename 3572 320 16 3908 f44 tty/serial/bfin_sport_uart.o File size after: text data bss dec hex filename 3664 228 16 3908 f44 tty/serial/bfin_sport_uart.o Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
There is no need to set PCI bus mastering when device is not doing any DMA. It includes MSI type of interrupts. Currently only UART on Denverton, which is DMA capable, might have MSI enabled. Taking above into account enable bus mastering for Denverton case only. Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
-
Andy Shevchenko authored
Enable MSI type of interrupt if PCI BIOS supports it. Reviewed-by:
-
Andy Shevchenko authored
Starting from Tangier B0 and continuing on Anniedale the HSU DMA interrupt line is actually shared with UART. Handling them independently is racy and quite often comes with the following traceback. irq 54: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc6-edison64-86244934+ #1 Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 ffff88003f203eb0 ffffffff8130e718 ffff880032627000 ffff88003262709c ffff88003f203ed8 ffffffff810a3960 ffff880032627000 0000000000000000 ffff880032627000 ffff88003f203f10 ffffffff810a3cc7 ffff880032627000 Call Trace: <IRQ> [<ffffffff8130e718>] dump_stack+0x4d/0x65 [<ffffffff810a3960>] __report_bad_irq+0x30/0xc0 [<ffffffff810a3cc7>] note_interrupt+0x227/0x270 [<ffffffff810a1380>] handle_irq_event_percpu+0x40/0x50 [<ffffffff810a13b7>] handle_irq_event+0x27/0x50 [<ffffffff810a42d5>] handle_fasteoi_irq+0x85/0x150 [<ffffffff8101d7fe>] handle_irq+0x6e/0x120 [<ffffffff8105b8bc>] ? _local_bh_enable+0x1c/0x50 [<ffffffff8101d0d6>] do_IRQ+0x46/0xd0 [<ffffffff818cef3f>] common_interrupt+0x7f/0x7f <EOI> [<ffffffff818cdead>] ? mwait_idle+0x7d/0x140 [<ffffffff81024c9a>] arch_cpu_idle+0xa/0x10 [<ffffffff818ce150>] default_idle_call+0x20/0x30 [<ffffffff810908fd>] cpu_startup_entry+0x16d/0x1d0 [<ffffffff818c882d>] rest_init+0x6d/0x70 [<ffffffff81f93e8f>] start_kernel+0x3e2/0x3ef [<ffffffff81f9343d>] x86_64_start_reservations+0x38/0x3a [<ffffffff81f93529>] x86_64_start_kernel+0xea/0xed handlers: [<ffffffff81411670>] serial8250_interrupt Disabling IRQ #54 Fix this by handling interrupt only in one place. The issue is discussed here: https://github.com/andy-shev/linux/issues/5 Moreover this also fixes another bug when Rx DMA returns wrong residue and we can't rely on it. Reviewed-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Jason Uy authored
In the most common use case, the Synopsys DW UART driver does not set the set_termios callback function. This prevents UPSTAT_AUTOCTS from being set when the UART flag CRTSCTS is set. As a result, the driver will use software flow control as opposed to hardware flow control. To fix the problem, the set_termios callback function is set to the DW specific function. The logic to set UPSTAT_AUTOCTS is moved so that any clock error will not affect setting the hardware flow control. Reviewed-by:
Scott Branden <scott.branden@broadcom.com> Reviewed-by:
Ray Jui <ray.jui@broadcom.com> Signed-off-by:
Jason Uy <jason.uy@broadcom.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by:
-
Laurent Pinchart authored
SCI instances found in SH SoCs have different spacing between registers depending on the SoC. The platform data contains a regshift field that tells the driver by how many bits to shift the register offset to compute its address. We can compute the regshift value automatically based on the memory resource size, there's no need to pass the value through platform data. Fix the sh7750 SCI and sh7760 SIM port memory resources length to ensure proper computation of the regshift value. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Laurent Pinchart authored
The field isn't set by any platform but is only used internally in the driver to hold data parsed from DT. Move it to the sci_port structure. Signed-off-by:
-
Laurent Pinchart authored
The sh-sci driver implements manual break debouncing for a few SH platforms by reading the value of the RX pin port register. This feature is optional and the driver considers all negative or zero values of the platform data port_reg field as invalid. As the four platforms that set the field to a register address all use an address higher than 0x7fffffff, the driver will always consider the value as invalid and never perform debouncing. The feature is unused, remove it. Debouncing could be implemented properly in the future using the pinctrl and GPIO APIs if desired. Signed-off-by:
-
Laurent Pinchart authored
Only SH platforms still use platform data for the sh-sci, and none of them declare DMA channels connected to the SCI. Remove the corresponding platform data fields and simplify the driver accordingly. Signed-off-by:
-
Laurent Pinchart authored
The fifo size, overrun register and mask, sampling rate mask and error mask all depend on the port type only and don't need to be computed at runtime. Add them to the sci_port_parameters structure. Signed-off-by:
-
Laurent Pinchart authored
The driver modifies platform data for internal purpose only. Fix that and make the platform data structure const. Signed-off-by:
-
Laurent Pinchart authored
Turn the regmap two-dimensional array to an array of port parameters and store a pointer to the port parameters in the sci_port structure. This will allow handling additional port type dependent parameters. Signed-off-by:
-
Laurent Pinchart authored
The compiler zeros uninitialized fields, don't zero them manually. Signed-off-by:
-
Laurent Pinchart authored
Even though most of its registers are 8-bit wide, the IRDA has two 16-bit registers that make it a 16-bit peripheral and not a 8-bit peripheral with addresses shifted by one. Fix the registers offset in the driver and the platform data regshift value. Signed-off-by:
-
Laurent Pinchart authored
According to the datasheets, the sh7760 SIM and sh7723 SCIFA instances don't implement the REIE bit. Don't set it in platform data. Signed-off-by:
-
Laurent Pinchart authored
The bit is only set by platforms that also set the CKE1 but, in which case its value is ignored by the device. Don't set it, this simplifies platform data and only leaves the CKE1 bit to be handled. Signed-off-by:
-
Laurent Pinchart authored
The driver considers all negative or zero values of the port_reg field as invalid. The four platforms that set the field to a register address all use an address higher than 0x7fffffff, which is thus considered by the driver as invalid. The feature is thus never used, remove it. The feature could be implemented properly in the future using the pinctrl and GPIO APIs if desired. While at it, don't set the field to SCIx_NOT_SUPPORTED (-1) either, leaving it unset leads to the same result. This will allow removing the SCIx_NOT_SUPPORTED macro. Signed-off-by:
-
Laurent Pinchart authored
The flag is set by the driver internally, don't set it in platform data. Signed-off-by:
-
Laurent Pinchart authored
The SCIF ports on sh7264 and sh7269 don't support the TOIE bit according to the datasheets. Signed-off-by:
-
Laurent Pinchart authored
The scscr platform data field is used by the driver in three locations. One of them masks out all bits except SCSCR_REIE. The two other are the set_termios handler and the console write handler. The set_termios handler calls sci_start_rx() to enable the receiver, which sets the RIE bit unconditionally. It then calls sci_port_disable() that effectively disables both the transmitter and the receiver. The TIE bit will thus get set later when the serial cores reenables the serial port. The console write handler runs with interrupts disabled, and saves and restores the SCSCR register value. The RIE and TIE bits are thus not needed there. The bits are thus not necessary in platform data, remove them. Signed-off-by:
-
Laurent Pinchart authored
The bits are set by the driver internally, don't set them in platform data. Signed-off-by:
-
Laurent Pinchart authored
The UPF_BOOT_AUTOCONF platform data flag is set by all platforms, hardcode it. The UPF_IOREMAP flag is set by a single SH platform and thus needs to be kept. However, for ARM platforms, we can base the decision on whether an OF node is present and bypass the platform data flags completely. Signed-off-by:
-
Laurent Pinchart authored
The Transmit Enable and Receive Enable bits are set in the scscr field of all instances of the sh-sci platform data. Set them in the driver directly to prepare for their removal from platform data. Signed-off-by:
-
