- Jul 29, 2013
-
-
Elen Song authored
use function pointer can avoid define atmel_use_pdc_tx/rx everywhere. (*prepare_rx/tx)() is in setup transfer stage. (*schedule_rx/tx)() is in tasklet schedule stage. (*release_rx/tx)() is used when shutdown the transfer. Signed-off-by:
Elen Song <elen.song@atmel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Elen Song authored
The DMA is available since at91sam9x5 socs, before that, we use PDC. Signed-off-by:
-
Darren Hart authored
The dmi_table is best accessed from the probe function, which is not an __init function. Drop the __initdata annotation from the dmi_table to avoid the section mismatch compiler warnings: WARNING: drivers/tty/serial/pch_uart.o(.text+0x4871): Section mismatch in reference from the function pch_uart_init_port() to the variable .init.data:pch_uart_dmi_table Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Alexander Shiyan authored
This patch fixes wrong dev_pm_ops which caused by commit: serial: max310x: Driver rework. CC drivers/tty/serial/max310x.o LD drivers/video/fb.o CC drivers/w1/slaves/w1_ds2433.o CC drivers/w1/slaves/w1_ds2760.o CC drivers/xen/balloon.o CC drivers/video/backlight/adp8870_bl.o drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.suspend') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.resume') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.freeze') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.thaw') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.poweroff') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.restore') [enabled by default] Reported-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
- Jul 26, 2013
-
-
Laurent Pinchart authored
Replace kzalloc and clk_get by their managed counterparts to simplify error and cleanup paths. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Stephen Boyd authored
UARTDM cores have a TX fifo that can accept more than one character per register write, but the msm_serial driver currently only supports 1 character mode. Add support for this mode of operation to speed up the transmit path on DM devices. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Acked-by:
David Brown <davidb@codeaurora.org> Signed-off-by:
-
Stephen Boyd authored
Currently msm_set_baud_rate() assumes the uart clock rate is 1.8432 MHz. This is not always true, and limits our options to program the baud rate. Instead of assuming the rate and hard-coding the baud_code based on it, calculate the divider that we want and try to find the closest baud_code that matches. This allows us to support uarts with faster clock speeds. Signed-off-by:
-
Stephen Boyd authored
drivers/tty/serial/msm_serial.c:302:6: warning: symbol 'msm_set_mctrl' was not declared. Should it be static? drivers/tty/serial/msm_serial.c:597:17: warning: incorrect type in argument 2 (different address spaces) drivers/tty/serial/msm_serial.c:597:17: expected void volatile [noderef] <asn:2>*addr drivers/tty/serial/msm_serial.c:597:17: got unsigned int * drivers/tty/serial/msm_serial.c:608:33: warning: incorrect type in argument 1 (different address spaces) drivers/tty/serial/msm_serial.c:608:33: expected void volatile [noderef] <asn:2>*addr drivers/tty/serial/msm_serial.c:608:33: got unsigned int *gsbi_base drivers/tty/serial/msm_serial.c:648:37: warning: incorrect type in assignment (different address spaces) drivers/tty/serial/msm_serial.c:648:37: expected unsigned int *gsbi_base drivers/tty/serial/msm_serial.c:648:37: got void [noderef] <asn:2>* Mark the ioremapped memory as __iomem and use writel instead of iowrite because we're not dealing with PCI devices. Also, mark msm_set_mctrl() static because it isn't used outside this file. Signed-off-by:
-
Stephen Boyd authored
UARTDM serial devices require us to wait for the entire TX fifo to drain before we can change the contents of the NCF_TX register. Furthermore, if we write any characters to the TX fifo within the same clock cycle of changing the NCF_TX register the NCF_TX register won't latch properly. To fix these issues we should read back the NCF_TX register to delay any TX fifo accesses by a clock cycle and we should wait for the TX fifo to drain (instead of just waiting for the fifo to be ready to receive more characters). Failure to do so leads to random NUL bytes interspersed in the output. Signed-off-by:
-
Ian Abbott authored
The quirks and PCI ID table entries for the original ADDI-DATA APCI-7800 (not the newer APCI-7800-3) use PCI_DEVICE_ID_ADDIDATA_APCI7800 from <linux/pci_ids.h> but the device ID was actually assigned to ADDI-DATA by Applied Micro Circuits Corporation (PCI_VENDOR_ID_AMCC). Replace it locally with #define PCI_DEVICE_ID_AMCC_ADDIDATA_APCI7800. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Ian Abbott authored
PCI_VENDOR_ID_ADDIDATA_OLD has the same value (0x10e8) as PCI_VENDOR_ID_AMCC in <linux/pci_ids.h>. The vender ID is actually assigned to Applied Micro Circuits Corporation. The 8250_pci driver uses PCI_VENDOR_ID_ADDIDATA_OLD in the lists of quirks and PCI IDs for the ADDI-DATA APCI-7800 card. Change it to use the more accurate PCI_VENDOR_ID_AMCC. Signed-off-by:
-
Srinivas Kandagatla authored
This patch adds support to ASC (asynchronous serial controller) driver, which is basically a standard serial driver. This IP is common across all the ST parts for settop box platforms. ASC is embedded in ST COMMS IP block. It supports Rx & Tx functionality. It support all industry standard baud rates. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@st.com> CC: Stephen Gallimore <stephen.gallimore@st.com> CC: Stuart Menefy <stuart.menefy@st.com> CC: Arnd Bergmann <arnd@arndb.de> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Uwe Kleine-König authored
Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
The driver fails to build on x86 because writel_relaxed isn't available there. That function exists on arm, arm64, avr32, hexagon, mips and sh, but adding all these is overkill so stick to arm only. Signed-off-by:
-
Wei Yongjun authored
Add the missing iounmap() before return from msm_request_port() in the error handling case. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Reviewed-by:
Ivan T. Ivanov <iivanov@mm-sol.com> Signed-off-by:
-
Axel Lin authored
No idea why we have redundant testing for ifdef CONFIG_SERIAL_BFIN_MODULE, check it once is enough. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
-
Darren Hart authored
Use the DMI interface rather than manually matching DMI strings. Signed-off-by:
-
Kees Cook authored
Some serial ports will not use the standard base baud rate. Report this after initialization so it might be discovered and used for early console configuration. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Grygorii Strashko authored
If earlyprintk is enabled and current UART is console port the platform code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and avoid resuming of already active device, but now, driver initialization will be performed in the wrong way: pm_runtime_enable(&pdev->dev); <-- PM runtime alowed (device state RPM_ACTIVE) if (omap_up_info->autosuspend_timeout == 0) omap_up_info->autosuspend_timeout = -1; device_init_wakeup(up->dev, true); pm_runtime_use_autosuspend(&pdev->dev); <-- update_autosuspend() will be called and it will disable device (device state RPM_SUSPENDED) pm_runtime_set_autosuspend_delay(&pdev->dev, omap_up_info->autosuspend_timeout); <-- update_autosuspend() will be called which will re-enable device (device state RPM_ACTIVE), because autosuspend_timeout < 0 pm_runtime_irq_safe(&pdev->dev); pm_runtime_get_sync(&pdev->dev); <-- will do nothing Such behavior isn't expected by OMAP serial drivers and causes unpredictable calls of serial_omap_runtime_suspend() and serial_omap_runtime_resume(). Hence, fix it by allowing PM runtime only after all its parameters are configured. CC: Tony Lindgren <tony@atomide.com> CC: Rajendra Nayak <rnayak@ti.com> CC: Felipe Balbi <balbi@ti.com> CC: Kevin Hilman <khilman@linaro.org> Tested-by:Mark Jackson <mpfj-list@newflow.co.uk> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Axel Lin authored
Signed-off-by:
-
Shawn Guo authored
Function lpuart_setup_watermark() clears some bits in register UARTCR2 before writing FIFO configuration registers as required by hardware. But it should restore UARTCR2 after that. Otherwise, we end up changing UARTCR2 register when setting up watermark, and that is not really desirable. At least, when low-level debug and earlyprint is enabled, serial console is broken due to it. Fix the problem by restoring UARTCR2 register at the end of function lpuart_setup_watermark(). Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Ruchika Kharwar authored
Ensure the Interrupt handling routine return IRQ_HANDLED vs IRQ_NONE. Signed-off-by:
Ruchika Kharwar <ruchika@ti.com> Signed-off-by:
Alexander Savchenko <oleksandr.savchenko@ti.com> Signed-off-by:
-
Vikram Pandita authored
Otherwise serial driver would crash accessing platform_data that was not initialized in functions like: serial_omap_pm(...) ... if (!state && pdata->enable_wakeup) ^^^^^^^ ... Signed-off-by:Vikram Pandita <vikram.pandita@ti.com> Signed-off-by:
-
Ruchika Kharwar authored
The revision register is a 32 bit register. The serial_in() function reads only the lower 16 bits of the register. This leads to an incorrect computation of the Module revision. Signed-off-by:
-
Dmitry Fink authored
Current logic results in interrupt storm since the fifo is constantly below the threshold level. Change the logic to fill all the available spaces in the fifo as long as we have data to minimize the possibilty of underflow and elimiate excessive interrupts. Signed-off-by:
Dmitry Fink <finik@ti.com> Signed-off-by:
-
Govindraj.R authored
wer has TX wakeup bit available enable the same by populating the necessary tx wakeup flag for the applicable module ip blocks and use the same while configuaring wer reg. Also wer is not context restored, restore wer when context is lost. Cc: Paul Walmsley <paul@pwsan.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Kevin Hilman <kevin.hilman@linaro.org> Acked-by:
Govindraj.R <govindraj.raja@ti.com> Signed-off-by:
-
Stefan Seyfried authored
The recent regression about NetMos 9835 Multi-I/O boards indicates that comment pointing to the parport_serial driver could be helpful. Signed-off-by:
Stefan Seyfried <seife+kernel@b1-systems.com> Signed-off-by:
-
Alexander Shiyan authored
This patch adds support for MAX14830 (advanced quad universal asynchronous receiver-transmitter) into max310x driver. Signed-off-by:
-
Alexander Shiyan authored
This patch adds support for MAX3109 (advanced dual universal asynchronous receiver-transmitter) into max310x driver. Signed-off-by:
-
Alexander Shiyan authored
This patch rework max310x driver. Major changes have been made: - Prepare driver to support ICs with more than one UART. - Prepare driver to support work with I2C-bus. The patch changes almost every function and can not be divided into parts. Signed-off-by:
-
Huang Shijie authored
We only enable the DMA support when the following are meet: [1] The uart port supports the hardware flow control(CTS/RTS). (Some uart port does not support the CTS/RTS.) [2] The application enables the CTS/RTS. [3] The Soc is imx6q. For the sdma's firmware limit, we do not support the DMA except the imx6q platform. [4] The uart is not used as a console. Signed-off-by:Huang Shijie <b32955@freescale.com> Signed-off-by:
-
Hubert Feurstein authored
It was not possible to set custom-baudrates like 62500. Signed-off-by:
Hubert Feurstein <h.feurstein@gmail.com> Signed-off-by:
-
Huang Shijie authored
We will add the DMA support for the imx uart. For the firmware's limit, only the imx6 serial chips (including the imx6q, imx6dl, imx6sl) can support the DMA. This patch adds the necessary macro and helper to distinguish the imx6q uart from the other imx uart. Other chips can use the "fsl,imx6q-uart" to enable the DMA support. This patch also replaces the check "is_imx21_uart()" with "!is_imx1_uart()". Signed-off-by:
-
Huang Shijie authored
The uart_console() check makes the clocks(clk_per and clk_ipg) opened even when we close the console uart. This patch enable/disable the clocks in imx_console_write(), so we can keep the clocks closed when the console uart is closed. Also remove the clock enable/disable oprations in the probe, we do not need them any more. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Acked-by:
Barry Song <baohua.song@csr.com> Acked-by:
Tony Prisk <linux@prisktech.co.nz> Acked-by:
-
- Jul 24, 2013
-
-
Richard Zhao authored
ttyTHS is consistent with the name used in driver. Signed-off-by:
Richard Zhao <rizhao@nvidia.com> Acked-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Henrik Nordström authored
The earlier change to use strlcpy uncovered a bug in the options argument length calculation causing last character to be truncated. This makes the actual console to be configured with incorrect baudrate when specifying the console using console=uart,... syntax. Bug symptom seen in kernel log output: Kernel command line: console=uart,mmio,0x90000000,115200 Early serial console at MMIO 0x90000000 (options '11520') which then results in a invalid baud rate 11520 instead of the expected 115200 when the console is switched to ttyS0 later in the boot process. Signed-off-by:
Henrik Nordstrom <henrik@henriknordstrom.net> Signed-off-by:
-
Wolfram Sang authored
Since commit ab78029e (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
- Jul 01, 2013
-
-
David Daney authored
A few differences needed by OCTEON: o These are DWC UARTS, but have USR at a different offset. o Internal SoC buses require reading back from registers to maintain write ordering. o 8250 on OCTEON appears with 64-bit wide registers, so when using readb/writeb in big endian mode we have to adjust the membase to hit the proper part of the register. o No UCV register, so we hard code some properties. Because OCTEON doesn't have a UCV register, I change where dw8250_setup_port(), which reads the UCV, is called by pushing it in to the OF and ACPI probe functions, and move unchanged dw8250_setup_port() earlier in the file. Signed-off-by:
David Daney <david.daney@cavium.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
- Jun 30, 2013
-
-
Greg Kroah-Hartman authored
Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller" This reverts commit 8d2f8cd4. As reported by Stefan, this device already works with the parport_serial driver, so the 8250_pci driver should not also try to grab it as well. Reported-by:
Stefan Seyfried <stefan.seyfried@googlemail.com> Cc: Wang YanQing <udknight@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
