summaryrefslogtreecommitdiffstats
path: root/include/linux/serial_8250.h
AgeCommit message (Collapse)Author
2015-02-02serial: 8250: Use canary to restart console after suspendPeter Hurley
When using no_console_suspend, the serial console may be powered off anyway during system sleep. Upon resume, the port may be in its default power-on state, but is expected to continue console i/o before the device has received its pm callback. The resultant garbage i/o can cause all kinds of havoc on the remote end. Use the scratch register as a canary to discover if the console has been powered-off. Write a non-zero value to the scratch register at port suspend and reprogram the port before any console i/o if the scratch register != canary before port resume. This workaround is disabled for omap_8250 (which uses different divisor programming). Credit to Doug Anderson <dianders@chromium.org> for the idea of using the scratch register canary to discover port power-down. Cc: Doug Anderson <dianders@chromium.org> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-09serial: omap_8250: Fix RTS handlingPeter Hurley
The OMAP3 UART ignores MCR[1] (ie., UART_MCR_RTS) when in autoRTS mode (UPF_HARD_FLOW + CRTSCTS). This makes it impossible for either the serial core or userspace to manually flow control the sender. Disable autoRTS mode when RTS is lowered and restore the previous mode when RTS is raised. Note that the OMAP3 UART provides no mechanism for switching from autoRTS mode without corrupting incoming data; to access the necessary register, the line control settings must be set to 8-e-2 and thus any data received during that time will be interpreted with those settings. This corruption has been observed in practice. Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-06serial/8250: Remove obsolete handling of rs485 ioctlsRicardo Ribalda Delgado
There is no more users for this functions. All the 8250 drivers are using the rs485 handler on serial_core instead. Reviewed-by: Alan Cox <alan@linux.intel.com> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Alan Cox <alan@linux.intel.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-29tty: serial: 8250: use 32bit variable for rpm_tx_activeSebastian Andrzej Siewior
The kbuild test robot wrote me: | make.cross ARCH=powerpc |>> ERROR: ".__xchg_called_with_bad_pointer" [drivers/tty/serial/8250/8250.ko] undefined! The generic implementation of xchg() on arm and x86 works for variables of size one bye (char). According to the report powerpc does not support xchg() for one byte sized variables and looking further it seems also to be the same case for sparc and tile (or for 10 out of 26 architectures which provide a custom implementation). For that reason I increase the size of the variable from one to four bytes to get it work on powerpc (and the others). Reported-By: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-26tty: serial: 8250_core: add run time pmSebastian Andrzej Siewior
While comparing the OMAP-serial and the 8250 part of this I noticed that the latter does not use run time-pm. Here are the pieces. It is basically a get before first register access and a last_busy + put after last access. This has to be enabled from userland _and_ UART_CAP_RPM is required for this. The runtime PM can usually work transparently in the background however there is one exception to this: After serial8250_tx_chars() completes there still may be unsent bytes in the FIFO (depending on CPU speed vs baud rate + flow control). Even if the TTY-buffer is empty we do not want RPM to disable the device because it won't send the remaining bytes. Instead we leave serial8250_tx_chars() with RPM enabled and wait for the FIFO empty interrupt. Once we enter serial8250_tx_chars() with an empty buffer we know that the FIFO is empty and since we are not going to send anything, we can disable the device. That xchg() is to ensure that serial8250_tx_chars() can be called multiple times and only the first invocation will actually invoke the runtime PM function. So that the last invocation of __stop_tx() will disable runtime pm. NOTE: do not enable RPM on the device unless you know what you do! If the device goes idle, it won't be woken up by incomming RX data _unless_ there is a wakeup irq configured which is usually the RX pin configure for wakeup via the reset module. The RX activity will then wake up the device from idle. However the first character is garbage and lost. The following bytes will be received once the device is up in time. On the beagle board xm (omap3) it takes approx 13ms from the first wakeup byte until the first byte that is received properly if the device was in core-off. v5…v8: - drop RPM from serial8250_set_mctrl() it will be used in restore path which already has RPM active and holds dev->power.lock v4…v5: - add a wrapper around rpm function and introduce UART_CAP_RPM to ensure RPM put is invoked after the TX FIFO is empty. v3…v4: - added runtime to the console code - removed device_may_wakeup() from serial8250_set_sleep() Cc: mika.westerberg@linux.intel.com Reviewed-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08tty: serial: 8250_core: allow to overwrite & export serial8250_startup()Sebastian Andrzej Siewior
The OMAP version of the 8250 can actually use 1:1 serial8250_startup(). However it needs to be extended by a wake up irq which should to be requested & enabled at ->startup() time and disabled at ->shutdown() time. v2…v3: properly copy callbacks v1…v2: add shutdown callback Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-08serial/8250: Add support for RS485 IOCTLsRicardo Ribalda Delgado
This patch allow the users of the 8250 infrastructure to define a handler for RS485 configration. If no handler is defined the 8250 driver will work as usual. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> -- v2:Change suggested by Alan "One Thousand Gnomes": - Move rs485 structure further down on the uart_8250_port structure drivers/tty/serial/8250/8250_core.c | 39 +++++++++++++++++++++++++++++++++++++ include/linux/serial_8250.h | 3 +++ 2 files changed, 42 insertions(+) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-17serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffersYoshihiro YUNOMAE
Add tunable RX interrupt trigger I/F of FIFO buffers. Serial devices are used as not only message communication devices but control or sending communication devices. For the latter uses, normally small data will be exchanged, so user applications want to receive data unit as soon as possible for real-time tendency. If we have a sensor which sends a 1 byte data each time and must control a device based on the sensor feedback, the RX interrupt should be triggered for each data. According to HW specification of serial UART devices, RX interrupt trigger can be changed, but the trigger is hard-coded. For example, RX interrupt trigger in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets the trigger to only 8bytes. This patch makes some devices change RX interrupt trigger from userland. <How to use> - Read current setting # cat /sys/class/tty/ttyS0/rx_trig_bytes 8 - Write user setting # echo 1 > /sys/class/tty/ttyS0/rx_trig_bytes # cat /sys/class/tty/ttyS0/rx_trig_bytes 1 <Support uart devices> - 16550A and Tegra (1, 4, 8, or 14 bytes) - 16650V2 (8, 16, 24, or 28 bytes) - 16654 (8, 16, 56, or 60 bytes) - 16750 (1, 16, 32, or 56 bytes) <Change log> Changes in V9: - Use attr_group instead of dev_spec_attr_group of uart_port structure Changes in V8: - Divide this patch from V7's patch based on Greg's comment Changes in V7: - Add Documentation - Change I/F name from rx_int_trig to rx_trig_bytes because the name rx_int_trig is hard to understand how users specify the value Changes in V6: - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h, rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to UART_FCR_R_TRIG_BITS() - Change following function names: convert_fcr2val() => fcr_get_rxtrig_bytes() convert_val2rxtrig() => bytes_to_fcr_rxtrig() - Fix typo in serial8250_do_set_termios() - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig() - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables (but UI remains rx_int_trig) - Change the meaningless variable name 'val' to 'bytes' following functions: fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(), do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig() - Use up->fcr in order to get rxtrig_bytes instead of rx_trig_raw in fcr_get_rxtrig_bytes() - Use conf_type->rxtrig_bytes[0] instead of switch statement for support check in register_dev_spec_attr_grp() - Delete the checking whether a user changed FCR or not when minimum buffer is needed in serial8250_do_set_termios() Changes in V5.1: - Fix FCR_RX_TRIG_MAX_STATE definition Changes in V5: - Support Tegra, 16650V2, 16654, and 16750 - Store default FCR value to up->fcr when the port is first created - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[] in convert_fcr2val() and convert_val2rxtrig() Changes in V4: - Introduce fifo_bug flag in uart_8250_port structure This is enabled only when parity is enabled and UART_BUG_PARITY is enabled for up->bugs. If this flag is enabled, user cannot set RX trigger. - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and at convert_val2rxtrig() - Set the nearest lower RX trigger when users input a meaningless value at convert_val2rxtrig() - Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos() - Set fcr = up->fcr in the begging of serial8250_do_set_termios() Changes in V3: - Change I/F from ioctl(2) to sysfs(rx_int_trig) Changed in V2: - Use _IOW for TIOCSFIFORTRIG definition - Pass the interrupt trigger value itself Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-17serial: 8250: introduce up_to_u8250p() helperAndy Shevchenko
It helps to cast struct uart_port to struct uart_8250_port at runtime. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-15serial: 8250: Add support for dmaengineHeikki Krogerus
Add support for dmaengine API. The drivers can implement the struct uart_8250_dma member in struct uart_8250_port and 8250.c can take care of the rest. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-16tty/8250_early: Turn serial_in/serial_out into weak symbols.Noam Camus
Allows overriding default methods serial_in/serial_out. In such platform specific replacement it is possible to use other regshift, biased register offset, any other manipulation that is not covered with common default methods. Overriding default methods may be useful for platforms which got serial peripheral with registers represented in big endian. In this situation and assuming that 32 bit operations / alignment is required then it may be useful to swab words before/after accessing the serial registers. Signed-off-by: Noam Camus <noamc@ezchip.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-178250: three way resolve of the 8250 diffsAlan Cox
This resolves the differences between the original 8250 patch, the revised 8250 patch and the independant clean up of the octeon driver (to use platform devices properly yay!) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-128250: use the 8250 register interface not the legacy oneAlan Cox
The old interface just copies bits over and calls the newer one. In addition we can now pass more information. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-23Merge branch 'delete-mca' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux Pull the MCA deletion branch from Paul Gortmaker: "It was good that we could support MCA machines back in the day, but realistically, nobody is using them anymore. They were mostly limited to 386-sx 16MHz CPU and some 486 class machines and never more than 64MB of RAM. Even the enthusiast hobbyist community seems to have dried up close to ten years ago, based on what you can find searching various websites dedicated to the relatively short lived hardware. So lets remove the support relating to CONFIG_MCA. There is no point carrying this forward, wasting cycles doing routine maintenance on it; wasting allyesconfig build time on validating it, wasting I/O on git grep'ping over it, and so on." Let's see if anybody screams. It generally has compiled, and James Bottomley pointed out that there was a MCA extension from NCR that allowed for up to 4GB of memory and PPro-class machines. So in *theory* there may be users out there. But even James (technically listed as a maintainer) doesn't actually have a system, and while Alan Cox claims to have a machine in his cellar that he offered to anybody who wants to take it off his hands, he didn't argue for keeping MCA support either. So we could bring it back. But somebody had better speak up and talk about how they have actually been using said MCA hardware with modern kernels for us to do that. And David already took the patch to delete all the networking driver code (commit a5e371f61ad3: "drivers/net: delete all code/drivers depending on CONFIG_MCA"). * 'delete-mca' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: MCA: delete all remaining traces of microchannel bus support. scsi: delete the MCA specific drivers and driver code serial: delete the MCA specific 8250 support. arm: remove ability to select CONFIG_MCA
2012-05-17serial: delete the MCA specific 8250 support.Paul Gortmaker
The support for CONFIG_MCA is being removed, since the 20 year old hardware simply isn't capable of meeting today's software demands on CPU and memory resources. This commit removes the MCA specific 8250 UART code. Cc: Alan Cox <alan@linux.intel.com> Cc: linux-serial@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-05-02serial8250: Introduce serial8250_register_8250_port()Magnus Damm
Introduce yet another 8250 registration function. This time it is serial8250_register_8250_port() and it allows us to register 8250 hardware instances using struct uart_8250_port. The new function makes it possible to register 8250 hardware that makes use of 8250 specific callbacks such as ->dl_read() and ->dl_write(). Signed-off-by: Magnus Damm <damm@opensource.se> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-18tegra, serial8250: add ->handle_break() uart_port opDan Williams
The "KT" serial port has another use case for a "received break" quirk, so before adding another special case to the 8250 core take this opportunity to push such quirks out of the core and into a uart_port op. Stephen says: "If the callback function is to no longer live in 8250.c itself, arch/arm/mach-tegra/devices.c isn't logically a good place to put it, and that file will be going away once we get rid of all the board files and move solely to device tree." ...so since 8250_pci.c houses all the quirks for pci serial devices this quirk is similarly housed in of_serial.c. Once the open firmware conversion completes the infrastructure details (include/linux/of_serial.h, and the export) can all be removed to make this self contained to of_serial.c. Cc: Nhan H Mai <nhan.h.mai@intel.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> [stephen: kill CONFIG_SERIAL_TEGRA in favor just using CONFIG_ARCH_TEGRA] Cc: Grant Likely <grant.likely@secretlab.ca> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Sudhakar Mamillapalli <sudhakar@fb.com> Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Tested-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2011-12-09serial: add irq handler for Freescale 16550 errata.Paul Gortmaker
Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx chips seems to cause a short lived IRQ storm (/proc/interrupts typically shows somewhere between 300 and 1500 events). Unfortunately this renders SysRQ over the serial console completely inoperable. The suggested workaround in the errata is to read the Rx register, wait one character period, and then read the Rx register again. We achieve this by tracking the old LSR value, and on the subsequent interrupt event after a break, we don't read LSR, instead we just read the RBR again and return immediately. The "fsl,ns16550" is used in the compatible field of the serial device to mark UARTs known to have this issue. Thanks to Scott Wood for providing the errata data which led to a much cleaner fix. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-09serial: export the key functions for an 8250 IRQ handlerPaul Gortmaker
For drivers that need to construct their own IRQ handler, the three components are seen in the current handle_port -- i.e. Rx, Tx and modem_status. Make these exported symbols so that "almost" 8250 UARTs can construct their own IRQ handler with these shared components, while working around their own unique errata issues. The function names are given a serial8250 prefix, since they are now entering the global namespace. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-24Revert "tty: serial8250: add helpers for the DesignWare 8250"Greg Kroah-Hartman
This reverts commit 6b1a98d1c4851235d9b6764b3f7b7db7909fc760. It causes a build error that needs to be resolved differently. Cc: Alan Cox <alan@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-23tty: serial8250: add helpers for the DesignWare 8250Jamie Iles
The Synopsys DesignWare 8250 is an 8250 that has an extra interrupt that gets raised when writing to the LCR when busy. To handle this we need special serial_out, serial_in and handle_irq methods. Add a new function serial8250_use_designware_io() that configures a uart_port with these accessors. Cc: Alan Cox <alan@linux.intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-23tty: serial8250: allow platforms to override irq handlerJamie Iles
Some ports (e.g. Synopsys DesignWare 8250) have special requirements for handling the interrupts. Allow these platforms to specify their own interrupt handler that will override the default. serial8250_handle_irq() is provided so that platforms can extend the IRQ handler rather than completely replacing it. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-10-22serial: abstraction for 8250 legacy portsAlan Cox
Not every platform that has generic legacy 8250 ports manages to have them clocked the right way or without errata. Provide a generic interface to allow platforms to override the default behaviour in a manner that dumps the complexity in *their* code not the 8250 driver. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-10-228250: allow platforms to override PM hook.Manuel Lauss
Add a hook for platforms to specify custom pm methods. Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10U6715 16550A serial driver supportPhilippe Langlais
UART Features extract from STEricsson U6715 data-sheet (arm926 SoC for mobile phone): * Fully compatible with industry standard 16C550 and 16C450 from various manufacturers * RX and TX 64 byte FIFO reduces CPU interrupts * Full double buffering * Modem control signals include CTS, RTS, (and DSR, DTR on UART1 only) * Automatic baud rate selection * Manual or automatic RTS/CTS smart hardware flow control * Programmable serial characteristics: – Baud rate generation (50 to 3.25M baud) – 5, 6, 7 or 8-bit characters – Even, odd or no-parity bit generation and detection – 1, 1.5 or 2 stop bit generation * Independent control of transmit, receive, line status, data set interrupts and FIFOs * Full status-reporting capabilities * Separate DMA signaling for RX and TX * Timed interrupt to spread receive interrupt on known duration * DMA time-out interrupt to allow detection of end of reception * Carkit pulse coding and decoding compliant with USB carkit control interface [40] In 16550A auto-configuration, if the fifo size is 64 then it's an U6 16550A port Add set_termios hook & export serial8250_do_set_termios to change uart clock following baudrate Signed-off-by: Philippe Langlais <philippe.langlais@stericsson.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-09-19serial: 8250: add IRQ trigger supportVikram Pandita
There is currently no provision for passing IRQ trigger flags for serial IRQs with triggering requirements (such as GPIO IRQs) This patch adds irqflags to plat_serial8250_port that can be passed from board file to reqest_irq() of 8250 driver Changes are backward compatible with boards passing UPF_SHARE_IRQ flag Tested on Zoom2 board that has IRQF_TRIGGER_RISING requirement for 8250 irq [Moved new flag to end to fix bugs in the original with the old_serial array -- Alan] Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-02Serial: Allow port type to be specified when calling serial8250_register_port.David Daney
Add flag value UPF_FIXED_TYPE which specifies that the UART type is known and should not be probed. For this case the UARTs properties are just copied out of the uart_config entry. This allows us to keep SOC specific 8250 probe code out of 8250.c. In this case we know the serial hardware will not be changing as it is on the same silicon as the CPU, and we can specify it with certainty in the board/cpu setup code. The alternative is to load up 8250.c with a bunch of OCTEON specific special cases in the probing code. Signed-off-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-01-028250: Serial driver changes to support future Cavium OCTEON serial patches.David Daney
In order to use Cavium OCTEON specific serial i/o drivers, we first patch the 8250 driver to use replaceable I/O functions. Compatible I/O functions are added for existing iotypeS. An added benefit of this change is that it makes it easy to factor some of the existing special cases out to board/SOC specific support code. The alternative is to load up 8250.c with a bunch of OCTEON specific iotype code and bug work-arounds. Signed-off-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Tomaso Paoletti <tpaoletti@caviumnetworks.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28sm501: add uart supportMagnus Damm
This patch extends the sm501 mfd with 8250 uart support. We're currently doing this in the board specific r2d-1 code already, but it would be nice to do move things into the mfd since it's more chip specific than board specific. Signed-off-by: Magnus Damm <damm@igel.co.jp> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-058250.c: support specifying DW APB UARTs in device platform_dataWill Newton
Allow the private_data field to be specified in platform_data for the standard 8250/16550 UART. This field is used by DW APB type UARTs and without this patch it's only possible to set this field when registering the port by hand. If private_data is not set then the driver will potentially oops with a NULL pointer dereference. Signed-off-by: Will Newton <will.newton@gmail.com> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-24Use resource_size_t for serial port IO addressesJosh Boyer
At present, various parts of the serial code use unsigned long to define resource addresses. This is a problem, because some 32-bit platforms have physical addresses larger than 32-bits, and have mmio serial uarts located above the 4GB point. This patch changes the type of mapbase in both struct uart_port and struct plat_serial8250_port to resource_size_t, which can be configured to be 64 bits on such platforms. The mapbase in serial_struct can't safely be changed, because that structure is user visible. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Paul Mackerras <paulus@samba.org> Cc: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-18serial: add early_serial_setup() back to header fileYinghai Lu
early_serial_setup was removed from serial.h, but forgot to put in serial_8250.h Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-16serial: convert early_uart to earlycon for 8250Yinghai Lu
Beacuse SERIAL_PORT_DFNS is removed from include/asm-i386/serial.h and include/asm-x86_64/serial.h. the serial8250_ports need to be probed late in serial initializing stage. the console_init=>serial8250_console_init=> register_console=>serial8250_console_setup will return -ENDEV, and console ttyS0 can not be enabled at that time. need to wait till uart_add_one_port in drivers/serial/serial_core.c to call register_console to get console ttyS0. that is too late. Make early_uart to use early_param, so uart console can be used earlier. Make it to be bootconsole with CON_BOOT flag, so can use console handover feature. and it will switch to corresponding normal serial console automatically. new command line will be: console=uart8250,io,0x3f8,9600n8 console=uart8250,mmio,0xff5e0000,115200n8 or earlycon=uart8250,io,0x3f8,9600n8 earlycon=uart8250,mmio,0xff5e0000,115200n8 it will print in very early stage: Early serial console at I/O port 0x3f8 (options '9600n8') console [uart0] enabled later for console it will print: console handover: boot [uart0] -> real [ttyS0] Signed-off-by: <yinghai.lu@sun.com> Cc: Andi Kleen <ak@suse.de> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Gerd Hoffmann <kraxel@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-12-07[PATCH] Exar quad port serialPaul B Schroeder
This is on our "Envoy" boxes which we have, according to the documentation, an "Exar ST16C554/554D Quad UART with 16-byte Fifo's". The box also has two other "on-board" serial ports and a modem chip. The two on-board serial UARTs were being detected along with the first two Exar UARTs. The last two Exar UARTs were not showing up and neither was the modem. This patch was the only way I could the kernel to see beyond the standard four serial ports and get all four of the Exar UARTs to show up. [akpm@osdl.org: build fix] Signed-off-by: Paul B Schroeder <pschroeder@uplogix.com> Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-25[ARM] 3383/3: ixp2000: ixdp2x01 platform serial conversionLennert Buytenhek
Patch from Lennert Buytenhek Add a PLAT8250_DEV_PLATFORM2, and convert the two ixdp2x01 CPLD serial ports to use platform serial devices with ids PLAT8250_DEV_PLATFORM[12]. (The on-chip xscale UART is PLAT8250_DEV_PLATFORM, id #0.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-21[SERIAL] Make uart_port flags a bitwise typeRussell King
Same reasoning as commit 747c8a55946ed037bf7d62454c3c599c02af2262 but this time we're making uart_port flags a bitwise type - not all of these flags correspond with the old ASYNC_ flags, so there is the possibility for bugs if the wrong ASYNC_* constants are used. Always use UPF_* constants for uart_port->flags. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-11-06[SERIAL] Support Au1x00 8250 UARTs using the generic 8250 driver.Pantelis Antoniou
The offsets of the registers are in a different place, and some parts cannot handle a full set of modem control signals. Signed-off-by: Pantelis Antoniou <pantelis@embeddedalley.ocm> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-29Create platform_device.h to contain all the platform device details.Russell King
Convert everyone who uses platform_bus_type to include linux/platform_device.h. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-08[SERIAL] Use an enum for serial8250 platform device IDsRussell King
Rather than hard-coding the platform device IDs, enumerate them. We don't particularly care about the actual ID we get, just as long as they're unique. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-01[SERIAL] Move serial8250_*_port prototypes to linux/serial_8250.hRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-27[PATCH] Serial: Split 8250 port tableRussell King
Add separate files for the different 8250 ISA-based serial boards. Looking across all the various architectures, it seems reasonable that we can key the availability of the configuration options for these beasts to the bus-related symbols (iow, CONFIG_ISA). We also standardise the base baud/uart clock rate for these boards - I'm sure that isn't architecture specific, but is solely dependent on the crystal fitted on the board (which should be the same no matter what type of machine its fitted into.) Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!