linux-sg2042/arch/arm/mach-omap2/serial.c

370 lines
10 KiB
C
Raw Normal View History

/*
* arch/arm/mach-omap2/serial.c
*
* OMAP2 serial support.
*
* Copyright (C) 2005-2008 Nokia Corporation
* Author: Paul Mundt <paul.mundt@nokia.com>
*
* Major rework for PM support by Kevin Hilman
*
* Based off of arch/arm/mach-omap/omap1/serial.c
*
* Copyright (C) 2009 Texas Instruments
* Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*/
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/delay.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled The console semaphore must be held while the OMAP UART devices are disabled, lest a console write cause an ARM abort (and a kernel crash) when the underlying console device is inaccessible. These crashes only occur when the console is on one of the OMAP internal serial ports. While this problem has been latent in the PM idle loop for some time, the crash was not triggerable with an unmodified kernel until commit 6f251e9db1093c187addc309b5f2f7fe3efd2995 ("OMAP: UART: omap_device conversions, remove implicit 8520 assumptions"). After this patch, a console write often occurs after the console UART has been disabled in the idle loop, crashing the system. Several users have encountered this bug: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38396.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36602.html The same commit also introduced new code that disabled the UARTs during init, in omap_serial_init_port(). The kernel will also crash in this code when earlyconsole and extra debugging is enabled: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36411.html The minimal fix for the -rc series is to hold the console semaphore while the OMAP UARTs are disabled. This is a somewhat overbroad fix, since the console may not be located on an OMAP UART, as is the case with the GPMC UART on Zoom3. While it is technically possible to determine which devices the console or earlyconsole is actually running on, it is not a trivial problem to solve, and the code to do so is not really appropriate for the -rc series. The right long-term fix is to ensure that no code outside of the OMAP serial driver can disable an OMAP UART. As I understand it, code to implement this is under development by TI. This patch is a collaboration between Paul Walmsley <paul@pwsan.com> and Tony Lindgren <tony@atomide.com>. Thanks to Ming Lei <tom.leiming@gmail.com> and Pramod <pramod.gurav@ti.com> for their feedback on earlier versions of this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Cc: Ming Lei <tom.leiming@gmail.com> Cc: Pramod <pramod.gurav@ti.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jean Pihet <jean.pihet@newoldbits.com> Cc: Govindraj.R <govindraj.raja@ti.com>
2010-11-25 07:49:05 +08:00
#include <linux/console.h>
#include <plat/omap-serial.h>
#include "common.h"
#include <plat/board.h>
#include <plat/dma.h>
#include <plat/omap_hwmod.h>
#include <plat/omap_device.h>
#include <plat/omap-pm.h>
#include "prm2xxx_3xxx.h"
#include "pm.h"
#include "cm2xxx_3xxx.h"
#include "prm-regbits-34xx.h"
#include "control.h"
#include "mux.h"
/*
* NOTE: By default the serial auto_suspend timeout is disabled as it causes
* lost characters over the serial ports. This means that the UART clocks will
* stay on until power/autosuspend_delay is set for the uart from sysfs.
* This also causes that any deeper omap sleep states are blocked.
*/
#define DEFAULT_AUTOSUSPEND_DELAY -1
#define MAX_UART_HWMOD_NAME_LEN 16
struct omap_uart_state {
int num;
struct list_head node;
struct omap_hwmod *oh;
OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of default uart pads) removed default uart pads that where getting populated and which was making rx pin wakeup capable. If uart pads were used in different mode by any other module then it would fail since the default pads took over all the uart pins forcefully. With removal of default pads the rx_pad wakeup for console uart while waking up from off mode is broken. Utilise the mux api available to probe the availability of mux pins in uart mode and probe for availability of uart pin in mux mode0 if uart is available as uart pin itself then configure rx pin as wakeup capable. This patch itself doesn't cater to all boards. Boards using uart rx wakeup mechanism should ensure the usage of omap_serial_init_port by configuring required uart ports and pass necessary mux data, till then this probing of uart pins can cater to enabling of rx pad wakeup to most of the boards. This patch can also throw some boot warning from _omap_mux_get_by_name if pin is requested for availability is not present while dynamically probing the uart pins availability such boot warnings can be addressed only when board files are patched with omap_serial_init_port calls passing the right pads needed for a given port. Discussion Threads for reference: http://www.spinics.net/lists/linux-omap/msg69859.html http://www.spinics.net/lists/linux-omap/msg68659.html Cc: Felipe Balbi <balbi@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Russ Dill <russ.dill@gmail.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Ameya Palande <ameya.palande@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> [tony@atomide.com: updated to fix compile when CONFIG_OMAP_MUX is not set] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-05 19:04:11 +08:00
struct omap_device_pad default_omap_uart_pads[2];
};
static LIST_HEAD(uart_list);
static u8 num_uarts;
static u8 console_uart_id = -1;
static u8 no_console_suspend;
static u8 uart_debug;
#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
#define DEFAULT_RXDMA_BUFSIZE 4096 /* RX DMA buffer size */
#define DEFAULT_RXDMA_TIMEOUT (3 * HZ)/* RX DMA timeout (jiffies) */
static struct omap_uart_port_info omap_serial_default_info[] __initdata = {
{
.dma_enabled = false,
.dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
.dma_rx_poll_rate = DEFAULT_RXDMA_POLLRATE,
.dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
.autosuspend_timeout = DEFAULT_AUTOSUSPEND_DELAY,
},
};
#ifdef CONFIG_PM
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{
struct omap_device *od = to_omap_device(pdev);
if (!od)
return;
if (enable)
omap_hwmod_enable_wakeup(od->hwmods[0]);
else
omap_hwmod_disable_wakeup(od->hwmods[0]);
}
/*
* Errata i291: [UART]:Cannot Acknowledge Idle Requests
* in Smartidle Mode When Configured for DMA Operations.
* WA: configure uart in force idle mode.
*/
static void omap_uart_set_noidle(struct platform_device *pdev)
{
struct omap_device *od = to_omap_device(pdev);
omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_NO);
}
tty: serial: OMAP: block idle while the UART is transferring data in PIO mode 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: Paul Walmsley <paul@pwsan.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Govindraj.R <govindraj.raja@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-01-26 10:50:52 +08:00
static void omap_uart_set_smartidle(struct platform_device *pdev)
{
struct omap_device *od = to_omap_device(pdev);
u8 idlemode;
if (od->hwmods[0]->class->sysc->idlemodes & SIDLE_SMART_WKUP)
idlemode = HWMOD_IDLEMODE_SMART_WKUP;
else
idlemode = HWMOD_IDLEMODE_SMART;
omap_hwmod_set_slave_idlemode(od->hwmods[0], idlemode);
}
#else
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{}
static void omap_uart_set_noidle(struct platform_device *pdev) {}
tty: serial: OMAP: block idle while the UART is transferring data in PIO mode 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: Paul Walmsley <paul@pwsan.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Govindraj.R <govindraj.raja@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-01-26 10:50:52 +08:00
static void omap_uart_set_smartidle(struct platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of default uart pads) removed default uart pads that where getting populated and which was making rx pin wakeup capable. If uart pads were used in different mode by any other module then it would fail since the default pads took over all the uart pins forcefully. With removal of default pads the rx_pad wakeup for console uart while waking up from off mode is broken. Utilise the mux api available to probe the availability of mux pins in uart mode and probe for availability of uart pin in mux mode0 if uart is available as uart pin itself then configure rx pin as wakeup capable. This patch itself doesn't cater to all boards. Boards using uart rx wakeup mechanism should ensure the usage of omap_serial_init_port by configuring required uart ports and pass necessary mux data, till then this probing of uart pins can cater to enabling of rx pad wakeup to most of the boards. This patch can also throw some boot warning from _omap_mux_get_by_name if pin is requested for availability is not present while dynamically probing the uart pins availability such boot warnings can be addressed only when board files are patched with omap_serial_init_port calls passing the right pads needed for a given port. Discussion Threads for reference: http://www.spinics.net/lists/linux-omap/msg69859.html http://www.spinics.net/lists/linux-omap/msg68659.html Cc: Felipe Balbi <balbi@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Russ Dill <russ.dill@gmail.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Ameya Palande <ameya.palande@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> [tony@atomide.com: updated to fix compile when CONFIG_OMAP_MUX is not set] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-05 19:04:11 +08:00
#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
static void __init
omap_serial_fill_uart_tx_rx_pads(struct omap_board_data *bdata,
struct omap_uart_state *uart)
{
uart->default_omap_uart_pads[0].name = rx_pad_name;
uart->default_omap_uart_pads[0].flags = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP;
uart->default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
OMAP_MUX_MODE0;
uart->default_omap_uart_pads[0].idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0;
uart->default_omap_uart_pads[1].name = tx_pad_name;
uart->default_omap_uart_pads[1].enable = OMAP_PIN_OUTPUT |
OMAP_MUX_MODE0;
bdata->pads = uart->default_omap_uart_pads;
bdata->pads_cnt = ARRAY_SIZE(uart->default_omap_uart_pads);
}
static void __init omap_serial_check_wakeup(struct omap_board_data *bdata,
struct omap_uart_state *uart)
{
OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of default uart pads) removed default uart pads that where getting populated and which was making rx pin wakeup capable. If uart pads were used in different mode by any other module then it would fail since the default pads took over all the uart pins forcefully. With removal of default pads the rx_pad wakeup for console uart while waking up from off mode is broken. Utilise the mux api available to probe the availability of mux pins in uart mode and probe for availability of uart pin in mux mode0 if uart is available as uart pin itself then configure rx pin as wakeup capable. This patch itself doesn't cater to all boards. Boards using uart rx wakeup mechanism should ensure the usage of omap_serial_init_port by configuring required uart ports and pass necessary mux data, till then this probing of uart pins can cater to enabling of rx pad wakeup to most of the boards. This patch can also throw some boot warning from _omap_mux_get_by_name if pin is requested for availability is not present while dynamically probing the uart pins availability such boot warnings can be addressed only when board files are patched with omap_serial_init_port calls passing the right pads needed for a given port. Discussion Threads for reference: http://www.spinics.net/lists/linux-omap/msg69859.html http://www.spinics.net/lists/linux-omap/msg68659.html Cc: Felipe Balbi <balbi@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Russ Dill <russ.dill@gmail.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Ameya Palande <ameya.palande@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> [tony@atomide.com: updated to fix compile when CONFIG_OMAP_MUX is not set] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-05 19:04:11 +08:00
struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
char *rx_fmt, *tx_fmt;
int uart_nr = bdata->id + 1;
if (bdata->id != 2) {
rx_fmt = "uart%d_rx.uart%d_rx";
tx_fmt = "uart%d_tx.uart%d_tx";
} else {
rx_fmt = "uart%d_rx_irrx.uart%d_rx_irrx";
tx_fmt = "uart%d_tx_irtx.uart%d_tx_irtx";
}
snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
uart_nr, uart_nr);
snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
uart_nr, uart_nr);
if (omap_mux_get_by_name(rx_pad_name, &rx_partition, &rx_mux) >= 0 &&
omap_mux_get_by_name
(tx_pad_name, &tx_partition, &tx_mux) >= 0) {
u16 tx_mode, rx_mode;
tx_mode = omap_mux_read(tx_partition, tx_mux->reg_offset);
rx_mode = omap_mux_read(rx_partition, rx_mux->reg_offset);
/*
* Check if uart is used in default tx/rx mode i.e. in mux mode0
* if yes then configure rx pin for wake up capability
*/
if (OMAP_MODE_UART(rx_mode) && OMAP_MODE_UART(tx_mode))
omap_serial_fill_uart_tx_rx_pads(bdata, uart);
}
}
#else
OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of default uart pads) removed default uart pads that where getting populated and which was making rx pin wakeup capable. If uart pads were used in different mode by any other module then it would fail since the default pads took over all the uart pins forcefully. With removal of default pads the rx_pad wakeup for console uart while waking up from off mode is broken. Utilise the mux api available to probe the availability of mux pins in uart mode and probe for availability of uart pin in mux mode0 if uart is available as uart pin itself then configure rx pin as wakeup capable. This patch itself doesn't cater to all boards. Boards using uart rx wakeup mechanism should ensure the usage of omap_serial_init_port by configuring required uart ports and pass necessary mux data, till then this probing of uart pins can cater to enabling of rx pad wakeup to most of the boards. This patch can also throw some boot warning from _omap_mux_get_by_name if pin is requested for availability is not present while dynamically probing the uart pins availability such boot warnings can be addressed only when board files are patched with omap_serial_init_port calls passing the right pads needed for a given port. Discussion Threads for reference: http://www.spinics.net/lists/linux-omap/msg69859.html http://www.spinics.net/lists/linux-omap/msg68659.html Cc: Felipe Balbi <balbi@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Russ Dill <russ.dill@gmail.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Ameya Palande <ameya.palande@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> [tony@atomide.com: updated to fix compile when CONFIG_OMAP_MUX is not set] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-05 19:04:11 +08:00
static void __init omap_serial_check_wakeup(struct omap_board_data *bdata,
struct omap_uart_state *uart)
{
}
#endif
ARM: OMAP2+: declare file-local functions as static Several function declarations used only in the files in which they're declared should include the static keyword, but don't: arch/arm/mach-omap2/serial.c:248:6: warning: symbol 'cmdline_find_option' was not declared. Should it be static? arch/arm/mach-omap2/omap-wakeupgen.c:259:6: warning: symbol 'irq_sar_clear' was not declared. Should it be static? arch/arm/mach-omap2/board-rx51-peripherals.c:878:27: warning: symbol 'rx51_vibra_data' was not declared. Should it be static? arch/arm/mach-omap2/board-rx51-peripherals.c:882:27: warning: symbol 'rx51_audio_data' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:201:29: warning: symbol 'omap_panda_wlan_data' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:393:24: warning: symbol 'omap4_panda_dvi_device' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:403:12: warning: symbol 'omap4_panda_dvi_init' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:464:6: warning: symbol 'omap4_panda_display_init' was not declared. Should it be static? arch/arm/mach-omap2/hsmmc.c:434:6: warning: symbol 'omap_init_hsmmc' was not declared. Should it be static? arch/arm/mach-omap2/hwspinlock.c:31:12: warning: symbol 'hwspinlocks_init' was not declared. Should it be static? arch/arm/mach-omap1/timer.c:58:12: warning: symbol 'omap1_dm_timer_init' was not declared. Should it be static? arch/arm/mach-omap1/fpga.c:90:6: warning: symbol 'innovator_fpga_IRQ_demux' was not declared. Should it be static? Mark all of these as static. Thanks to Arnd Bergmann <arnd@arndb.de> for pointing out a typo in the original patch description. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Govindraj R <govindraj.raja@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: David Anders <x0132446@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2012-04-13 20:34:26 +08:00
static char *cmdline_find_option(char *str)
{
extern char *saved_command_line;
return strstr(saved_command_line, str);
}
static int __init omap_serial_early_init(void)
{
do {
char oh_name[MAX_UART_HWMOD_NAME_LEN];
struct omap_hwmod *oh;
struct omap_uart_state *uart;
char uart_name[MAX_UART_HWMOD_NAME_LEN];
snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
"uart%d", num_uarts + 1);
oh = omap_hwmod_lookup(oh_name);
if (!oh)
break;
uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
if (WARN_ON(!uart))
return -ENODEV;
uart->oh = oh;
uart->num = num_uarts++;
list_add_tail(&uart->node, &uart_list);
snprintf(uart_name, MAX_UART_HWMOD_NAME_LEN,
"%s%d", OMAP_SERIAL_NAME, uart->num);
if (cmdline_find_option(uart_name)) {
console_uart_id = uart->num;
if (console_loglevel >= 10) {
uart_debug = true;
pr_info("%s used as console in debug mode"
" uart%d clocks will not be"
" gated", uart_name, uart->num);
}
if (cmdline_find_option("no_console_suspend"))
no_console_suspend = true;
/*
* omap-uart can be used for earlyprintk logs
* So if omap-uart is used as console then prevent
* uart reset and idle to get logs from omap-uart
* until uart console driver is available to take
* care for console messages.
* Idling or resetting omap-uart while printing logs
* early boot logs can stall the boot-up.
*/
oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
}
} while (1);
return 0;
}
core_initcall(omap_serial_early_init);
/**
* omap_serial_init_port() - initialize single serial port
* @bdata: port specific board data pointer
* @info: platform specific data pointer
*
* This function initialies serial driver for given port only.
* Platforms can call this function instead of omap_serial_init()
* if they don't plan to use all available UARTs as serial ports.
*
* Don't mix calls to omap_serial_init_port() and omap_serial_init(),
* use only one of the two.
*/
void __init omap_serial_init_port(struct omap_board_data *bdata,
struct omap_uart_port_info *info)
{
struct omap_uart_state *uart;
struct omap_hwmod *oh;
struct platform_device *pdev;
void *pdata = NULL;
u32 pdata_size = 0;
char *name;
struct omap_uart_port_info omap_up;
if (WARN_ON(!bdata))
return;
if (WARN_ON(bdata->id < 0))
return;
if (WARN_ON(bdata->id >= num_uarts))
return;
list_for_each_entry(uart, &uart_list, node)
if (bdata->id == uart->num)
break;
if (!info)
info = omap_serial_default_info;
OMAP3: serial - fix bug introduced in Commit f62349ee9788b1d94c55eb6c291d74a1f69bdd9e had side effect that causes kernel to oops when we are suspending to ram: # echo mem > /sys/power/state WARNING: at kernel/irq/manage.c:858 __free_irq+0x90/0x174() Trying to free already-free IRQ 72 Modules linked in: Backtrace: [<c00328d0>] (dump_backtrace+0x0/0x110) from [<c0347298>] (dump_stack+0x18/0x1c) r7:dfd4be08 r6:c009505c r5:c03fbfd1 r4:0000035a [<c0347280>] (dump_stack+0x0/0x1c) from [<c005a408>] (warn_slowpath_common+0x50/0x68) [<c005a3b8>] (warn_slowpath_common+0x0/0x68) from [<c005a46c>] (warn_slowpath_fmt+0x30) r7:c0474afc r6:00000048 r5:00000000 r4:c0474ac0 [<c005a43c>] (warn_slowpath_fmt+0x0/0x38) from [<c009505c>] (__free_irq+0x90/0x174) r3:00000048 r2:c03fc0ef [<c0094fcc>] (__free_irq+0x0/0x174) from [<c0095184>] (free_irq+0x44/0x64) [<c0095140>] (free_irq+0x0/0x64) from [<c0038100>] (omap_uart_enable_irqs+0x4c/0x90) r7:c034d58c r6:00000003 r5:00000000 r4:c0463028 [<c00380b4>] (omap_uart_enable_irqs+0x0/0x90) from [<c003d8f8>] (omap3_pm_begin+0x1c/0) r5:00000003 r4:00000000 [<c003d8dc>] (omap3_pm_begin+0x0/0x28) from [<c008d008>] (suspend_devices_and_enter+0x) [<c008cfd8>] (suspend_devices_and_enter+0x0/0x1dc) from [<c008d29c>] (enter_state+0xe8) r5:c03f7f46 r4:00000000 [<c008d1b4>] (enter_state+0x0/0x140) from [<c008c8e0>] (state_store+0x9c/0xc4) r7:c034d58c r6:00000003 r5:00000003 r4:c03f7f46 [<c008c844>] (state_store+0x0/0xc4) from [<c01cb2dc>] (kobj_attr_store+0x20/0x24) [<c01cb2bc>] (kobj_attr_store+0x0/0x24) from [<c0119420>] (sysfs_write_file+0x114/0x14) [<c011930c>] (sysfs_write_file+0x0/0x148) from [<c00cb298>] (vfs_write+0xb8/0x164) [<c00cb1e0>] (vfs_write+0x0/0x164) from [<c00cb408>] (sys_write+0x44/0x70) r8:4001f000 r7:00000004 r6:df81bd00 r5:00000000 r4:00000000 [<c00cb3c4>] (sys_write+0x0/0x70) from [<c002f040>] (ret_fast_syscall+0x0/0x38) r8:c002f204 r7:00000004 r6:401fa5e8 r5:4001f000 r4:00000004 This is due the fact that uart_list list was populated in omap_serial_early_init() and omap_uart_enable_irqs() went through this list even when serial idle wasn't enabled for all uarts. This patch moves the code that populates the uart_list and enables uart clocks into omap_serial_init_port(). Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-12-14 21:59:18 +08:00
oh = uart->oh;
name = DRIVER_NAME;
omap_up.dma_enabled = info->dma_enabled;
omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
omap_up.flags = UPF_BOOT_AUTOCONF;
omap_up.get_context_loss_count = omap_pm_get_dev_context_loss_count;
tty: serial: OMAP: block idle while the UART is transferring data in PIO mode 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: Paul Walmsley <paul@pwsan.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Govindraj.R <govindraj.raja@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-01-26 10:50:52 +08:00
omap_up.set_forceidle = omap_uart_set_smartidle;
omap_up.set_noidle = omap_uart_set_noidle;
omap_up.enable_wakeup = omap_uart_enable_wakeup;
omap_up.dma_rx_buf_size = info->dma_rx_buf_size;
omap_up.dma_rx_timeout = info->dma_rx_timeout;
omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
omap_up.autosuspend_timeout = info->autosuspend_timeout;
pdata = &omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
if (WARN_ON(!oh))
return;
pdev = omap_device_build(name, uart->num, oh, pdata, pdata_size,
NULL, 0, false);
WARN(IS_ERR(pdev), "Could not build omap_device for %s: %s.\n",
name, oh->name);
if ((console_uart_id == bdata->id) && no_console_suspend)
omap_device_disable_idle_on_suspend(pdev);
oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
oh->dev_attr = uart;
if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
&& !uart_debug)
device_init_wakeup(&pdev->dev, true);
}
/**
* omap_serial_board_init() - initialize all supported serial ports
* @info: platform specific data pointer
*
* Initializes all available UARTs as serial ports. Platforms
* can call this function when they want to have default behaviour
* for serial ports (e.g initialize them all as serial ports).
*/
void __init omap_serial_board_init(struct omap_uart_port_info *info)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
list_for_each_entry(uart, &uart_list, node) {
bdata.id = uart->num;
bdata.flags = 0;
bdata.pads = NULL;
bdata.pads_cnt = 0;
OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of default uart pads) removed default uart pads that where getting populated and which was making rx pin wakeup capable. If uart pads were used in different mode by any other module then it would fail since the default pads took over all the uart pins forcefully. With removal of default pads the rx_pad wakeup for console uart while waking up from off mode is broken. Utilise the mux api available to probe the availability of mux pins in uart mode and probe for availability of uart pin in mux mode0 if uart is available as uart pin itself then configure rx pin as wakeup capable. This patch itself doesn't cater to all boards. Boards using uart rx wakeup mechanism should ensure the usage of omap_serial_init_port by configuring required uart ports and pass necessary mux data, till then this probing of uart pins can cater to enabling of rx pad wakeup to most of the boards. This patch can also throw some boot warning from _omap_mux_get_by_name if pin is requested for availability is not present while dynamically probing the uart pins availability such boot warnings can be addressed only when board files are patched with omap_serial_init_port calls passing the right pads needed for a given port. Discussion Threads for reference: http://www.spinics.net/lists/linux-omap/msg69859.html http://www.spinics.net/lists/linux-omap/msg68659.html Cc: Felipe Balbi <balbi@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Russ Dill <russ.dill@gmail.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Ameya Palande <ameya.palande@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> [tony@atomide.com: updated to fix compile when CONFIG_OMAP_MUX is not set] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-05 19:04:11 +08:00
omap_serial_check_wakeup(&bdata, uart);
if (!info)
omap_serial_init_port(&bdata, NULL);
else
omap_serial_init_port(&bdata, &info[uart->num]);
}
}
/**
* omap_serial_init() - initialize all supported serial ports
*
* Initializes all available UARTs.
* Platforms can call this function when they want to have default behaviour
* for serial ports (e.g initialize them all as serial ports).
*/
void __init omap_serial_init(void)
{
omap_serial_board_init(NULL);
}