[PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
Converting uart driver to adapt to pm runtime API's. Code re-org + cleanup. Moving some functionality from serial.c to omap-serial.c Changes involves: 1.) Cleaning up certain uart calls from sram_idle func. 2.) Removed all types of uart clock handling code from serial.c 3.) Using hwmod_mux API enable wakeup capability for uart pad during hwmod_idle state i.e., when uart clocks are disabled we can enable io-pad wakeup capability for uart if mux_data is available for given uart. Also during during resume from idle call to uart we need to enable clocks back conditionally and this can be done only when io-pad wakeup event bit is set for uart_rx pad. So we need a hwmod API which can probe the uart pad and let us know whether a uart wakeup happened. So omap_hmwod_pad_wakeup_status API is added to meet this requirement. 3.) Adapted omap-serial driver to use runtime API's. 4.) Modify serial_init calls to accept uart parameters from board file. Like dma_usage, rx_timeout, dma_rx_pollrate, auto_suspend_timeout etc. 5.) Use the omap_prm driver with irq_chaining to wake up uart after clocks are cut. Patch series is based on 3.2-rc1. Patch series depends on *Tero's v9 Irq_chaining patches*. Dependent irq_chaining patches are as below. 89ac62b omap3+: add omap prm driver initialization 170431f OMAP3: pm: do not enable PRCM MPU interrupts manually 9aba1b0 omap3: pm: use prcm chain handler 435481f OMAP2+: mux: add support for PAD wakeup interrupts 5b2d361 mfd: omap-prm: added suspend prepare and complete callbacks aa55c41 mfd: omap-prm: added chain interrupt handler d1db904 mfd: omap-prm: add driver skeleton 31d056c TEMP: OMAP4xxx: hwmod data: add PRM hwmod 19ec3bc TEMP: OMAP3xxx: hwmod data: add PRM hwmod 9a89688 OMAP2+: hwmod: Add API to check IO PAD wakeup status 78e8b65 OMAP2+: hwmod: Add API to enable IO ring wakeup. Same combination is hosted at: git://gitorious.org/runtime_3-0/runtime_3-0.git 3.2-rc1_uart_runtime Ensure CONFIG_OMAP_PRM is set while testing irq_chaining with uart. And for pm_qos usage ensure CONFIG_CPU_IDLE is selected other wise console might be sluggish. Changes from v7: --- http://www.mail-archive.com/linux-omap@vger.kernel.org/msg57804.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58209.html http://www.spinics.net/lists/linux-omap/msg59978.html http://www.spinics.net/lists/linux-serial/msg04772.html Testing updates: OMAP2420/2430SDP: Boot tested. OMAP3430SDP: retention, off_mode, system_wide suspend is tested. (earlyprintk no_console_suspend checked) OMAP3630 - Zoom3: pm-retention checked with quart/omap-uart3 [Also tested with uart3 as console uart and pm-ret checked] BeagleBoard XM Rev C(3630): retention, off_mode, system_wide suspend is tested. Deepak K (1): OMAP2+: UART: Allow UART parameters to be configured from board file. Govindraj.R (18): OMAP2+: UART: cleanup + remove uart pm specific API OMAP2+: UART: cleanup 8250 console driver support OMAP2+: UART: Cleanup part of clock gating mechanism for uart OMAP2+: UART: Add default mux for all uarts. OMAP2+: UART: Remove mapbase/membase fields from pdata. OMAP2+: UART: Add runtime pm support for omap-serial driver OMAP2+: UART: Remove context_save and move context restore to driver OMAP2+: UART: Ensure all reg values configured are available from port structure OMAP2+: UART: Remove uart reset function. OMAP2+: UART: Get context loss count to context restore OMAP2+: UART: Move errata handling from serial.c to omap-serial OMAP2+: UART: Add wakeup mechanism for omap-uarts OMAP2+: UART: Remove old and unused clocks handling funcs OMAP2+: UART: remove temporary variable used to count uart instance OMAP2+: UART: Use custom activate func for console uart. OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecase OMAP2+: UART: Do not gate uart clocks if used for debug_prints OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos Jon Hunter (1): OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART arch/arm/mach-omap2/board-3430sdp.c | 100 +--- arch/arm/mach-omap2/board-4430sdp.c | 68 +-- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap4panda.c| 68 +-- arch/arm/mach-omap2/cpuidle34xx.c |5 - arch/arm/mach-omap2/pm24xx.c | 20 - arch/arm/mach-omap2/pm34xx.c | 42 -- arch/arm/mach-omap2/serial.c | 926 +++-- arch/arm/plat-omap/include/plat/omap-serial.h | 36 +- arch/arm/plat-omap/include/plat/serial.h | 10 +- drivers/tty/serial/omap-serial.c | 341 -- 11 files changed, 607 insertions(+), 1015 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info
[PATCH v8 05/20] OMAP2+: UART: Remove mapbase/membase fields from pdata.
The mapbase (start_address), membase(io_remap cookie) part of
pdata struct omap_uart_port_info are removed as this should be
derived within driver.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |2 --
arch/arm/plat-omap/include/plat/omap-serial.h |2 --
drivers/tty/serial/omap-serial.c | 10 --
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0de1a56..beb46e8 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -605,8 +605,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
omap_up.dma_enabled = uart-dma_enabled;
omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
- omap_up.mapbase = oh-slaves[0]-addr-pa_start;
- omap_up.membase = omap_hwmod_get_mpu_rt_va(oh);
omap_up.flags = UPF_BOOT_AUTOCONF;
pdata = omap_up;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 307cd6f..db9bda9 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -59,8 +59,6 @@
struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
- void __iomem*membase; /* ioremap cookie or NULL */
- resource_size_t mapbase;/* resource base */
upf_t flags; /* UPF_* flags */
};
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index be368cf7..31f0cbf 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1275,8 +1275,14 @@ static int serial_omap_probe(struct platform_device
*pdev)
up-port.ops = serial_omap_pops;
up-port.line = pdev-id;
- up-port.membase = omap_up_info-membase;
- up-port.mapbase = omap_up_info-mapbase;
+ up-port.mapbase = mem-start;
+ up-port.membase = ioremap(mem-start, resource_size(mem));
+ if (!up-port.membase) {
+ dev_err(pdev-dev, can't ioremap UART\n);
+ ret = -ENOMEM;
+ goto err;
+ }
+
up-port.flags = omap_up_info-flags;
up-port.uartclk = omap_up_info-uartclk;
up-uart_dma.uart_base = mem-start;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 02/20] OMAP2+: UART: cleanup 8250 console driver support
We had been using traditional 8250 driver as uart console driver
prior to omap-serial driver. Since we have omap-serial driver
in mainline kernel for some time now it has been used as default
uart console driver on omap2+ platforms. Remove 8250 support for
omap-uarts.
Serial_in and serial_out override for 8250 serial driver is also
removed. Empty fifo read fix is already taken care with omap-serial
driver with data ready bit check from LSR reg before reading RX fifo.
Also waiting for THRE(transmit hold reg empty) is done with wait_for_xmitr
in omap-serial driver.
Serial_in/out overrides are not neceesary for omap-serial driver
and things that are taken with omap-serial driver are removed here.
Remove headers that were necessary to support 8250 support
and remove all config bindings done to keep 8250 backward compatibility
while adding omap-serial driver. Remove omap_uart_reset needed for
8250 autoconf.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 97 --
1 files changed, 0 insertions(+), 97 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 8254067..8499f06 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -19,23 +19,17 @@
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
#include linux/delay.h
#include linux/platform_device.h
#include linux/slab.h
-#include linux/serial_8250.h
#include linux/pm_runtime.h
#include linux/console.h
-#ifdef CONFIG_SERIAL_OMAP
#include plat/omap-serial.h
-#endif
-
#include plat/common.h
#include plat/board.h
-#include plat/clock.h
#include plat/dma.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
@@ -47,10 +41,8 @@
#include control.h
#include mux.h
-#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
#define UART_OMAP_WER 0x17/* Wake-up enable register */
-#define UART_ERRATA_FIFO_FULL_ABORT(0x1 0)
#define UART_ERRATA_i202_MDR1_ACCESS (0x1 1)
/*
@@ -533,41 +525,6 @@ static void omap_uart_block_sleep(struct omap_uart_state
*uart)
#define DEV_CREATE_FILE(dev, attr)
#endif /* CONFIG_PM */
-#ifndef CONFIG_SERIAL_OMAP
-/*
- * Override the default 8250 read handler: mem_serial_in()
- * Empty RX fifo read causes an abort on omap3630 and omap4
- * This function makes sure that an empty rx fifo is not read on these silicons
- * (OMAP1/2/3430 are not affected)
- */
-static unsigned int serial_in_override(struct uart_port *up, int offset)
-{
- if (UART_RX == offset) {
- unsigned int lsr;
- lsr = __serial_read_reg(up, UART_LSR);
- if (!(lsr UART_LSR_DR))
- return -EPERM;
- }
-
- return __serial_read_reg(up, offset);
-}
-
-static void serial_out_override(struct uart_port *up, int offset, int value)
-{
- unsigned int status, tmout = 1;
-
- status = __serial_read_reg(up, UART_LSR);
- while (!(status UART_LSR_THRE)) {
- /* Wait up to 10ms for the character(s) to be sent. */
- if (--tmout == 0)
- break;
- udelay(1);
- status = __serial_read_reg(up, UART_LSR);
- }
- __serial_write_reg(up, offset, value);
-}
-#endif
-
static int __init omap_serial_early_init(void)
{
int i = 0;
@@ -628,15 +585,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
void *pdata = NULL;
u32 pdata_size = 0;
char *name;
-#ifndef CONFIG_SERIAL_OMAP
- struct plat_serial8250_port ports[2] = {
- {},
- {.flags = 0},
- };
- struct plat_serial8250_port *p = ports[0];
-#else
struct omap_uart_port_info omap_up;
-#endif
if (WARN_ON(!bdata))
return;
@@ -651,51 +600,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
oh = uart-oh;
uart-dma_enabled = 0;
-#ifndef CONFIG_SERIAL_OMAP
- name = serial8250;
-
- /*
-* !! 8250 driver does not use standard IORESOURCE* It
-* has it's own custom pdata that can be taken from
-* the hwmod resource data. But, this needs to be
-* done after the build.
-*
-* ?? does it have to be done before the register ??
-* YES, because platform_device_data_add() copies
-* pdata, it does not use a pointer.
-*/
- p-flags = UPF_BOOT_AUTOCONF;
- p-iotype = UPIO_MEM;
- p-regshift = 2;
- p-uartclk = OMAP24XX_BASE_BAUD * 16;
- p-irq = oh-mpu_irqs[0].irq;
- p-mapbase = oh-slaves[0]-addr-pa_start;
- p-membase = omap_hwmod_get_mpu_rt_va(oh);
- p-irqflags = IRQF_SHARED;
- p-private_data = uart;
-
- /*
-* omap44xx, ti816x: Never read empty UART fifo
-* omap3xxx: Never read empty UART fifo on UARTs
-* with IP rev
[PATCH v8 08/20] OMAP2+: UART: Ensure all reg values configured are available from port structure
Add missing uart regs to uart_port structure which can be used in
context restore. Store dll, dlh, mdr1, scr, efr, lcr, mcr reg values
into uart_port structure while configuring individual port in termios
function.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |4 ++
drivers/tty/serial/omap-serial.c | 43 +++--
2 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index db9bda9..70e7738 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -97,6 +97,10 @@ struct uart_omap_port {
unsigned char mcr;
unsigned char fcr;
unsigned char efr;
+ unsigned char dll;
+ unsigned char dlh;
+ unsigned char mdr1;
+ unsigned char scr;
int use_dma;
/*
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index a834e91..5327ff0 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -466,8 +466,9 @@ static void serial_omap_set_mctrl(struct uart_port *port,
unsigned int mctrl)
mcr |= UART_MCR_LOOP;
pm_runtime_get_sync(up-pdev-dev);
- mcr |= up-mcr;
- serial_out(up, UART_MCR, mcr);
+ up-mcr = serial_in(up, UART_MCR);
+ up-mcr |= mcr;
+ serial_out(up, UART_MCR, up-mcr);
pm_runtime_put(up-pdev-dev);
}
@@ -616,8 +617,6 @@ static inline void
serial_omap_configure_xonxoff
(struct uart_omap_port *up, struct ktermios *termios)
{
- unsigned char efr = 0;
-
up-lcr = serial_in(up, UART_LCR);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
up-efr = serial_in(up, UART_EFR);
@@ -627,8 +626,7 @@ serial_omap_configure_xonxoff
serial_out(up, UART_XOFF1, termios-c_cc[VSTOP]);
/* clear SW control mode bits */
- efr = up-efr;
- efr = OMAP_UART_SW_CLR;
+ up-efr = OMAP_UART_SW_CLR;
/*
* IXON Flag:
@@ -636,7 +634,7 @@ serial_omap_configure_xonxoff
* Transmit XON1, XOFF1
*/
if (termios-c_iflag IXON)
- efr |= OMAP_UART_SW_TX;
+ up-efr |= OMAP_UART_SW_TX;
/*
* IXOFF Flag:
@@ -644,7 +642,7 @@ serial_omap_configure_xonxoff
* Receiver compares XON1, XOFF1.
*/
if (termios-c_iflag IXOFF)
- efr |= OMAP_UART_SW_RX;
+ up-efr |= OMAP_UART_SW_RX;
serial_out(up, UART_EFR, up-efr | UART_EFR_ECB);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
@@ -667,7 +665,7 @@ serial_omap_configure_xonxoff
* load the new software flow control mode IXON or IXOFF
* and restore the UARTi.EFR_REG[4] ENHANCED_EN value.
*/
- serial_out(up, UART_EFR, efr | UART_EFR_SCD);
+ serial_out(up, UART_EFR, up-efr | UART_EFR_SCD);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up-mcr ~UART_MCR_TCRTLR);
@@ -714,6 +712,10 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
baud = uart_get_baud_rate(port, termios, old, 0, port-uartclk/13);
quot = serial_omap_get_divisor(port, baud);
+ up-dll = quot 0xff;
+ up-dlh = quot 8;
+ up-mdr1 = UART_OMAP_MDR1_DISABLE;
+
up-fcr = UART_FCR_R_TRIG_01 | UART_FCR_T_TRIG_01 |
UART_FCR_ENABLE_FIFO;
if (up-use_dma)
@@ -767,6 +769,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
up-ier |= UART_IER_MSI;
serial_out(up, UART_IER, up-ier);
serial_out(up, UART_LCR, cval); /* reset DLAB */
+ up-lcr = cval;
/* FIFOs and DMA Settings */
@@ -793,17 +796,18 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
if (up-use_dma) {
serial_out(up, UART_TI752_TLR, 0);
- serial_out(up, UART_OMAP_SCR,
- (UART_FCR_TRIGGER_4 | UART_FCR_TRIGGER_8));
+ up-scr |= (UART_FCR_TRIGGER_4 | UART_FCR_TRIGGER_8);
}
+ serial_out(up, UART_OMAP_SCR, up-scr);
+
serial_out(up, UART_EFR, up-efr);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up-mcr);
/* Protocol, Baud Rate, and Interrupt Settings */
- serial_out(up, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
+ serial_out(up, UART_OMAP_MDR1, up-mdr1);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
up-efr = serial_in(up, UART_EFR);
@@ -813,8 +817,8 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_IER, 0);
serial_out(up, UART_LCR,
[PATCH v8 03/20] OMAP2+: UART: Cleanup part of clock gating mechanism for uart
Currently we use a shared irq handler to identify uart activity and then
trigger a timer. By default the timeout value is zero and can be set or
modified from sysfs. If there was no uart activity for the period set
through sysfs, the timer will expire and call timer handler this will
set a flag can_sleep using which decision to gate uart clocks can be taken.
Since the clock gating mechanism is outside the uart driver, we currently
use this mechanism. In preparation to runtime implementation for omap-serial
driver we can cleanup this mechanism and use runtime API's to gate uart clocks.
Removes the following:
* timer related info from local uart_state struct
* the code used to set timeout value from sysfs.
* irqflags used to set shared irq handler.
* un-used function omap_uart_check_wakeup.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 118 +
arch/arm/plat-omap/include/plat/omap-serial.h |1 -
arch/arm/plat-omap/include/plat/serial.h |1 -
drivers/tty/serial/omap-serial.c |1 -
4 files changed, 2 insertions(+), 119 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 8499f06..f6adb49 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -58,8 +58,6 @@
struct omap_uart_state {
int num;
int can_sleep;
- struct timer_list timer;
- u32 timeout;
void __iomem *wk_st;
void __iomem *wk_en;
@@ -67,13 +65,9 @@ struct omap_uart_state {
u32 padconf;
u32 dma_enabled;
- struct clk *ick;
- struct clk *fck;
int clocked;
- int irq;
int regshift;
- int irqflags;
void __iomem *membase;
resource_size_t mapbase;
@@ -331,32 +325,6 @@ static void omap_uart_block_sleep(struct omap_uart_state
*uart)
omap_uart_smart_idle_enable(uart, 0);
uart-can_sleep = 0;
- if (uart-timeout)
- mod_timer(uart-timer, jiffies + uart-timeout);
- else
- del_timer(uart-timer);
-}
-
-static void omap_uart_allow_sleep(struct omap_uart_state *uart)
-{
- if (device_may_wakeup(uart-pdev-dev))
- omap_uart_enable_wakeup(uart);
- else
- omap_uart_disable_wakeup(uart);
-
- if (!uart-clocked)
- return;
-
- omap_uart_smart_idle_enable(uart, 1);
- uart-can_sleep = 1;
- del_timer(uart-timer);
-}
-
-static void omap_uart_idle_timer(unsigned long data)
-{
- struct omap_uart_state *uart = (struct omap_uart_state *)data;
-
- omap_uart_allow_sleep(uart);
}
int omap_uart_can_sleep(void)
@@ -380,35 +348,11 @@ int omap_uart_can_sleep(void)
return can_sleep;
}
-/**
- * omap_uart_interrupt()
- *
- * This handler is used only to detect that *any* UART interrupt has
- * occurred. It does _nothing_ to handle the interrupt. Rather,
- * any UART interrupt will trigger the inactivity timer so the
- * UART will not idle or sleep for its timeout period.
- *
- **/
-/* static int first_interrupt; */
-static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
-{
- struct omap_uart_state *uart = dev_id;
-
- omap_uart_block_sleep(uart);
-
- return IRQ_NONE;
-}
-
static void omap_uart_idle_init(struct omap_uart_state *uart)
{
int ret;
uart-can_sleep = 0;
- uart-timeout = DEFAULT_TIMEOUT;
- setup_timer(uart-timer, omap_uart_idle_timer,
- (unsigned long) uart);
- if (uart-timeout)
- mod_timer(uart-timer, jiffies + uart-timeout);
omap_uart_smart_idle_enable(uart, 0);
if (cpu_is_omap34xx() !cpu_is_ti816x()) {
@@ -470,51 +414,8 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
uart-wk_mask = 0;
uart-padconf = 0;
}
-
- uart-irqflags |= IRQF_SHARED;
- ret = request_threaded_irq(uart-irq, NULL, omap_uart_interrupt,
- IRQF_SHARED, serial idle, (void *)uart);
- WARN_ON(ret);
-}
-
-static ssize_t sleep_timeout_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_device *odev = to_omap_device(pdev);
- struct omap_uart_state *uart = odev-hwmods[0]-dev_attr;
-
- return sprintf(buf, %u\n, uart-timeout / HZ);
}
-static ssize_t sleep_timeout_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t n)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_device *odev = to_omap_device(pdev);
- struct omap_uart_state *uart = odev-hwmods[0]-dev_attr;
- unsigned int value;
-
- if (sscanf(buf, %u, value) != 1) {
-
[PATCH v8 09/20] OMAP2+: UART: Remove uart reset function.
Remove the uart reset function which is configuring the
TX empty irq which can now be handled within omap-serial driver.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 14 --
arch/arm/plat-omap/include/plat/omap-serial.h |2 ++
drivers/tty/serial/omap-serial.c |1 +
3 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3d5df9a..06887d3 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -74,19 +74,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
-/*
- * Internal UARTs need to be initialized for the 8250 autoconfig to work
- * properly. Note that the TX watermark initialization may not be needed
- * once the 8250.c watermark handling code is merged.
- */
-
-static inline void __init omap_uart_reset(struct omap_uart_state *uart)
-{
- serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
- serial_write_reg(uart, UART_OMAP_SCR, 0x08);
- serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
-}
-
#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3)
/*
@@ -521,7 +508,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
omap_device_enable(uart-pdev);
omap_uart_idle_init(uart);
- omap_uart_reset(uart);
omap_hwmod_enable_wakeup(uart-oh);
omap_device_idle(uart-pdev);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 70e7738..5b913c7 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -33,6 +33,8 @@
#define OMAP_MODE13X_SPEED 230400
+#define OMAP_UART_SCR_TX_EMPTY 0x08
+
/* WER = 0x7F
* Enable module level wakeup in WER reg
*/
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 5327ff0..f5a5ed6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -770,6 +770,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_IER, up-ier);
serial_out(up, UART_LCR, cval); /* reset DLAB */
up-lcr = cval;
+ up-scr = OMAP_UART_SCR_TX_EMPTY;
/* FIFOs and DMA Settings */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 07/20] OMAP2+: UART: Remove context_save and move context restore to driver
Remove context save function from serial.c and move context restore
function to omap-serial. Remove all regs stored in omap_uart_state
for contex_save/restore, reg read write funcs used in context_save/restore,
io_addresses populated for read/write funcs.
Clock gating mechanism was done in serial.c and had no info on uart state
thus we needed context save and restore in serial.c
With runtime conversion and clock gating done within uart driver
context restore can be done from regs value available from uart_omap_port
structure.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 118 --
drivers/tty/serial/omap-serial.c | 24
2 files changed, 24 insertions(+), 118 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index beb46e8..3d5df9a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -41,8 +41,6 @@
#include control.h
#include mux.h
-#define UART_OMAP_WER 0x17/* Wake-up enable register */
-
#define UART_ERRATA_i202_MDR1_ACCESS (0x1 1)
/*
@@ -66,60 +64,16 @@ struct omap_uart_state {
int clocked;
- int regshift;
- void __iomem *membase;
- resource_size_t mapbase;
-
struct list_head node;
struct omap_hwmod *oh;
struct platform_device *pdev;
u32 errata;
-#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
- int context_valid;
-
- /* Registers to be saved/restored for OFF-mode */
- u16 dll;
- u16 dlh;
- u16 ier;
- u16 sysc;
- u16 scr;
- u16 wer;
- u16 mcr;
-#endif
};
static LIST_HEAD(uart_list);
static u8 num_uarts;
-static inline unsigned int __serial_read_reg(struct uart_port *up,
-int offset)
-{
- offset = up-regshift;
- return (unsigned int)__raw_readb(up-membase + offset);
-}
-
-static inline unsigned int serial_read_reg(struct omap_uart_state *uart,
- int offset)
-{
- offset = uart-regshift;
- return (unsigned int)__raw_readb(uart-membase + offset);
-}
-
-static inline void __serial_write_reg(struct uart_port *up, int offset,
- int value)
-{
- offset = up-regshift;
- __raw_writeb(value, up-membase + offset);
-}
-
-static inline void serial_write_reg(struct omap_uart_state *uart, int offset,
- int value)
-{
- offset = uart-regshift;
- __raw_writeb(value, uart-membase + offset);
-}
-
/*
* Internal UARTs need to be initialized for the 8250 autoconfig to work
* properly. Note that the TX watermark initialization may not be needed
@@ -170,75 +124,6 @@ static void omap_uart_mdr1_errataset(struct
omap_uart_state *uart, u8 mdr1_val,
}
}
-static void omap_uart_save_context(struct omap_uart_state *uart)
-{
- u16 lcr = 0;
-
- if (!enable_off_mode)
- return;
-
- lcr = serial_read_reg(uart, UART_LCR);
- serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
- uart-dll = serial_read_reg(uart, UART_DLL);
- uart-dlh = serial_read_reg(uart, UART_DLM);
- serial_write_reg(uart, UART_LCR, lcr);
- uart-ier = serial_read_reg(uart, UART_IER);
- uart-sysc = serial_read_reg(uart, UART_OMAP_SYSC);
- uart-scr = serial_read_reg(uart, UART_OMAP_SCR);
- uart-wer = serial_read_reg(uart, UART_OMAP_WER);
- serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
- uart-mcr = serial_read_reg(uart, UART_MCR);
- serial_write_reg(uart, UART_LCR, lcr);
-
- uart-context_valid = 1;
-}
-
-static void omap_uart_restore_context(struct omap_uart_state *uart)
-{
- u16 efr = 0;
-
- if (!enable_off_mode)
- return;
-
- if (!uart-context_valid)
- return;
-
- uart-context_valid = 0;
-
- if (uart-errata UART_ERRATA_i202_MDR1_ACCESS)
- omap_uart_mdr1_errataset(uart, UART_OMAP_MDR1_DISABLE, 0xA0);
- else
- serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
-
- serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
- efr = serial_read_reg(uart, UART_EFR);
- serial_write_reg(uart, UART_EFR, UART_EFR_ECB);
- serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
- serial_write_reg(uart, UART_IER, 0x0);
- serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
- serial_write_reg(uart, UART_DLL, uart-dll);
- serial_write_reg(uart, UART_DLM, uart-dlh);
- serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
- serial_write_reg(uart, UART_IER, uart-ier);
- serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
- serial_write_reg(uart, UART_MCR, uart-mcr);
- serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
- serial_write_reg(uart, UART_EFR, efr);
-
[PATCH v8 04/20] OMAP2+: UART: Add default mux for all uarts.
Padconf wakeup is used to wakeup uart after uart fclks/iclks are gated.
Rx-Pad wakeup was done by writing to rx-pad offset value populated in
serial.c idle_init. Remove the direct reading and writing into rx pad.
Remove the padconf field part of omap_uart_state struct and pad offsets
populated.
Now with mux framework support we can use mux_utilities
along with hmwod framework to handle io-pad configuration and enable rx-pad
wake-up mechanism.
To avoid breaking any board support add default mux data for all uart's
if mux info is not passed from board file.
With the default pads populated in serial.c wakeup capability for
rx pads is set, this can be used to enable uart_rx io-pad wakeup from
hwmod framework. The pad values in 3430sdp/4430sdp/omap4panda board file
are same as the default pad values populated in serial.c. Remove pad values
from 3430sdp/4430sdp/omap4panda board file and use the default pads
from serial.c file.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c| 100 +
arch/arm/mach-omap2/board-4430sdp.c| 68 +--
arch/arm/mach-omap2/board-omap4panda.c | 68 +--
arch/arm/mach-omap2/serial.c | 155 ++-
4 files changed, 133 insertions(+), 258 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 77142c1..b80108b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -475,106 +475,8 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-
-static struct omap_device_pad serial1_pads[] __initdata = {
- /*
-* Note that off output enable is an active low
-* signal. So setting this means pin is a
-* input enabled in off mode
-*/
- OMAP_MUX_STATIC(uart1_cts.uart1_cts,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_rts.uart1_rts,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_rx.uart1_rx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_tx.uart1_tx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_device_pad serial2_pads[] __initdata = {
- OMAP_MUX_STATIC(uart2_cts.uart2_cts,
-OMAP_PIN_INPUT_PULLUP |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_rts.uart2_rts,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_rx.uart2_rx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_tx.uart2_tx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_device_pad serial3_pads[] __initdata = {
- OMAP_MUX_STATIC(uart3_cts_rctx.uart3_cts_rctx,
-OMAP_PIN_INPUT_PULLDOWN |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_rts_sd.uart3_rts_sd,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_rx_irrx.uart3_rx_irrx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_tx_irtx.uart3_tx_irtx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_board_data serial1_data __initdata = {
- .id = 0,
- .pads = serial1_pads,
- .pads_cnt = ARRAY_SIZE(serial1_pads),
-};
-
-static struct omap_board_data serial2_data __initdata = {
- .id = 1,
- .pads = serial2_pads,
- .pads_cnt = ARRAY_SIZE(serial2_pads),
-};
-
-static struct omap_board_data serial3_data __initdata = {
- .id = 2,
- .pads =
[PATCH v8 06/20] OMAP2+: UART: Add runtime pm support for omap-serial driver
Adapts omap-serial driver to use pm_runtime API's.
Use runtime runtime API's to handle uart clocks and obtain
device_usage statics. Set runtime API's usage to irq_safe so that
we can use get_sync from irq context. Auto-suspend for port specific
activities and put for reg access. Moving suspend/resume hooks
to dev_pm_ops structure and bing with config_suspend to avoid any
compilation warning if config_suspend is disabled.
By default uart autosuspend delay is set to -1 to avoid character loss
if uart's are autoidled and woken up on rx pin.
After boot up UART's can be autoidled by setting autosuspend delay from sysfs.
echo 3000 /sys/devices/platform/omap/omap_uart.X/power/autosuspend_delay_ms
X=0,1,2,3 for UART1/2/3/4. Number of uarts available may vary across omap_soc.
Also if uart is not wakeup capable we can prevent runtime autosuspend by
forbiding runtime.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
drivers/tty/serial/omap-serial.c | 122 ++
1 files changed, 109 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 31f0cbf..f16ef4b9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -37,11 +37,14 @@
#include linux/clk.h
#include linux/serial_core.h
#include linux/irq.h
+#include linux/pm_runtime.h
#include plat/dma.h
#include plat/dmtimer.h
#include plat/omap-serial.h
+#define OMAP_UART_AUTOSUSPEND_DELAY -1
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -102,6 +105,8 @@ static void serial_omap_stop_rxdma(struct uart_omap_port
*up)
omap_free_dma(up-uart_dma.rx_dma_channel);
up-uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE;
up-uart_dma.rx_dma_used = false;
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
}
}
@@ -110,8 +115,11 @@ static void serial_omap_enable_ms(struct uart_port *port)
struct uart_omap_port *up = (struct uart_omap_port *)port;
dev_dbg(up-port.dev, serial_omap_enable_ms+%d\n, up-pdev-id);
+
+ pm_runtime_get_sync(up-pdev-dev);
up-ier |= UART_IER_MSI;
serial_out(up, UART_IER, up-ier);
+ pm_runtime_put(up-pdev-dev);
}
static void serial_omap_stop_tx(struct uart_port *port)
@@ -129,23 +137,32 @@ static void serial_omap_stop_tx(struct uart_port *port)
omap_stop_dma(up-uart_dma.tx_dma_channel);
omap_free_dma(up-uart_dma.tx_dma_channel);
up-uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
}
+ pm_runtime_get_sync(up-pdev-dev);
if (up-ier UART_IER_THRI) {
up-ier = ~UART_IER_THRI;
serial_out(up, UART_IER, up-ier);
}
+
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
}
static void serial_omap_stop_rx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
+ pm_runtime_get_sync(up-pdev-dev);
if (up-use_dma)
serial_omap_stop_rxdma(up);
up-ier = ~UART_IER_RLSI;
up-port.read_status_mask = ~UART_LSR_DR;
serial_out(up, UART_IER, up-ier);
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
}
static inline void receive_chars(struct uart_omap_port *up, int *status)
@@ -262,7 +279,10 @@ static void serial_omap_start_tx(struct uart_port *port)
int ret = 0;
if (!up-use_dma) {
+ pm_runtime_get_sync(up-pdev-dev);
serial_omap_enable_ier_thri(up);
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
return;
}
@@ -272,6 +292,7 @@ static void serial_omap_start_tx(struct uart_port *port)
xmit = up-port.state-xmit;
if (up-uart_dma.tx_dma_channel == OMAP_UART_DMA_CH_FREE) {
+ pm_runtime_get_sync(up-pdev-dev);
ret = omap_request_dma(up-uart_dma.uart_dma_tx,
UART Tx DMA,
(void *)uart_tx_dma_callback, up,
@@ -354,9 +375,13 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
unsigned int iir, lsr;
unsigned long flags;
+ pm_runtime_get_sync(up-pdev-dev);
iir = serial_in(up, UART_IIR);
- if (iir UART_IIR_NO_INT)
+ if (iir UART_IIR_NO_INT) {
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
return IRQ_NONE;
+ }
spin_lock_irqsave(up-port.lock, flags);
lsr = serial_in(up, UART_LSR);
[PATCH v8 01/20] OMAP2+: UART: cleanup + remove uart pm specific API
In preparation to UART runtime conversion remove uart specific calls
from pm24xx/34xx files and their definition from serial.c
These func calls will no more be used with upcoming uart runtime design.
1.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks.
2.) omap_uart_enable_irqs :- Used to enable/disable uart irq's in suspend
path from PM code, this is removed as same is handled by
uart_suspend_port/uart_resume_port in omap-serial driver which will
do an port_shutdown on suspend freeing irq and port_startup on resume
enabling back irq.
3.) Remove prepare_idle/resume_idle calls used to gate uart clocks.
UART clocks can be gated within driver using runtime funcs
and be woken up using irq_chaining from omap_prm driver.
4.) Remove console_locking from idle path as clock gating is done withing
driver itself with runtime API. Remove is_suspending check used to acquire
console_lock.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm24xx.c | 18
arch/arm/mach-omap2/pm34xx.c | 32 ---
arch/arm/mach-omap2/serial.c | 65 --
arch/arm/plat-omap/include/plat/serial.h |4 --
4 files changed, 0 insertions(+), 119 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index cf0c216..5ec2b43 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -30,7 +30,6 @@
#include linux/irq.h
#include linux/time.h
#include linux/gpio.h
-#include linux/console.h
#include asm/mach/time.h
#include asm/mach/irq.h
@@ -126,27 +125,11 @@ static void omap2_enter_full_retention(void)
if (omap_irq_pending())
goto no_sleep;
- /* Block console output in case it is on one of the OMAP UARTs */
- if (!is_suspending())
- if (!console_trylock())
- goto no_sleep;
-
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
- omap_uart_prepare_idle(2);
-
/* Jump to SRAM suspend code */
omap2_sram_suspend(sdrc_read_reg(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_POWER));
- omap_uart_resume_idle(2);
- omap_uart_resume_idle(1);
- omap_uart_resume_idle(0);
-
- if (!is_suspending())
- console_unlock();
-
no_sleep:
omap2_gpio_resume_after_idle();
@@ -290,7 +273,6 @@ static int omap2_pm_suspend(void)
mir1 = omap_readl(0x480fe0a4);
omap_writel(1 5, 0x480fe0ac);
- omap_uart_prepare_suspend();
omap2_enter_full_retention();
omap_writel(mir1, 0x480fe0a4);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9517203..2eb3215 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,7 +28,6 @@
#include linux/clk.h
#include linux/delay.h
#include linux/slab.h
-#include linux/console.h
#include linux/mfd/omap-prm.h
#include trace/events/power.h
@@ -54,15 +53,6 @@
#ifdef CONFIG_SUSPEND
static suspend_state_t suspend_state = PM_SUSPEND_ON;
-static inline bool is_suspending(void)
-{
- return (suspend_state != PM_SUSPEND_ON) console_suspend_enabled;
-}
-#else
-static inline bool is_suspending(void)
-{
- return false;
-}
#endif
/* pm34xx errata defined in pm.h */
@@ -337,20 +327,11 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- /* Block console output in case it is on one of the OMAP UARTs */
- if (!is_suspending())
- if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
- if (!console_trylock())
- goto console_still_active;
-
pwrdm_pre_transition();
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
- omap_uart_prepare_idle(2);
- omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_going_off);
if (per_next_state == PWRDM_POWER_OFF)
omap3_per_save_context();
@@ -358,8 +339,6 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
@@ -408,8 +387,6 @@ void omap_sram_idle(void)
omap3_sram_restore_context();
omap2_sms_restore_context();
}
- omap_uart_resume_idle(0);
- omap_uart_resume_idle(1);
if (core_next_state == PWRDM_POWER_OFF)
[PATCH v8 10/20] OMAP2+: UART: Get context loss count to context restore
Avoid unconditional context restore every time we gate uart
clocks. Check whether context loss happened based on which
we can context restore uart regs from uart_port structure.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |2 ++
arch/arm/plat-omap/include/plat/omap-serial.h |3 +++
drivers/tty/serial/omap-serial.c | 20 ++--
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 06887d3..98e2666 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -33,6 +33,7 @@
#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
@@ -478,6 +479,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
omap_up.dma_enabled = uart-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;
pdata = omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 5b913c7..348c9ea 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -62,6 +62,8 @@ struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
upf_t flags; /* UPF_* flags */
+
+ int (*get_context_loss_count)(struct device *);
};
struct uart_omap_dma {
@@ -114,6 +116,7 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
charname[20];
unsigned long port_activity;
+ u32 context_loss_cnt;
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f5a5ed6..ea4c24a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1440,15 +1440,31 @@ static void serial_omap_restore_context(struct
uart_omap_port *up)
#ifdef CONFIG_PM_RUNTIME
static int serial_omap_runtime_suspend(struct device *dev)
{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+ struct omap_uart_port_info *pdata = dev-platform_data;
+
+ if (!up)
+ return -EINVAL;
+
+ if (pdata-get_context_loss_count)
+ up-context_loss_cnt = pdata-get_context_loss_count(dev);
+
return 0;
}
static int serial_omap_runtime_resume(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
+ struct omap_uart_port_info *pdata = dev-platform_data;
- if (up)
- serial_omap_restore_context(up);
+ if (up) {
+ if (pdata-get_context_loss_count) {
+ u32 loss_cnt = pdata-get_context_loss_count(dev);
+
+ if (up-context_loss_cnt != loss_cnt)
+ serial_omap_restore_context(up);
+ }
+ }
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 11/20] OMAP2+: UART: Move errata handling from serial.c to omap-serial
Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.
Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as from on errata will be handled in driver file itself.
Corrected errata id from chapter reference 2.15 to errata id i291.
Removed errata and dma_enabled fields from omap_uart_state struct
as they are no more needed with errata handling done within omap-serial.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 98 +++--
arch/arm/plat-omap/include/plat/omap-serial.h |6 ++
drivers/tty/serial/omap-serial.c | 66 -
3 files changed, 96 insertions(+), 74 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 98e2666..a52bd99 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -42,8 +42,6 @@
#include control.h
#include mux.h
-#define UART_ERRATA_i202_MDR1_ACCESS (0x1 1)
-
/*
* NOTE: By default the serial timeout is disabled as it causes lost characters
* over the serial ports. This means that the UART clocks will stay on until
@@ -61,59 +59,17 @@ struct omap_uart_state {
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
- u32 dma_enabled;
int clocked;
struct list_head node;
struct omap_hwmod *oh;
struct platform_device *pdev;
-
- u32 errata;
};
static LIST_HEAD(uart_list);
static u8 num_uarts;
-#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3)
-
-/*
- * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
- * The access to uart register after MDR1 Access
- * causes UART to corrupt data.
- *
- * Need a delay =
- * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS)
- * give 10 times as much
- */
-static void omap_uart_mdr1_errataset(struct omap_uart_state *uart, u8 mdr1_val,
- u8 fcr_val)
-{
- u8 timeout = 255;
-
- serial_write_reg(uart, UART_OMAP_MDR1, mdr1_val);
- udelay(2);
- serial_write_reg(uart, UART_FCR, fcr_val | UART_FCR_CLEAR_XMIT |
- UART_FCR_CLEAR_RCVR);
- /*
-* Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
-* TX_FIFO_E bit is 1.
-*/
- while (UART_LSR_THRE != (serial_read_reg(uart, UART_LSR)
- (UART_LSR_THRE | UART_LSR_DR))) {
- timeout--;
- if (!timeout) {
- /* Should *never* happen. we warn and carry on */
- dev_crit(uart-pdev-dev, Errata i202: timedout %x\n,
- serial_read_reg(uart, UART_LSR));
- break;
- }
- udelay(1);
- }
-}
-
-#endif /* CONFIG_PM CONFIG_ARCH_OMAP3 */
-
static inline void omap_uart_enable_clocks(struct omap_uart_state *uart)
{
if (uart-clocked)
@@ -156,27 +112,6 @@ static void omap_uart_disable_wakeup(struct
omap_uart_state *uart)
}
}
-static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
- int enable)
-{
- u8 idlemode;
-
- if (enable) {
- /**
-* Errata 2.15: [UART]:Cannot Acknowledge Idle Requests
-* in Smartidle Mode When Configured for DMA Operations.
-*/
- if (uart-dma_enabled)
- idlemode = HWMOD_IDLEMODE_FORCE;
- else
- idlemode = HWMOD_IDLEMODE_SMART;
- } else {
- idlemode = HWMOD_IDLEMODE_NO;
- }
-
- omap_hwmod_set_slave_idlemode(uart-oh, idlemode);
-}
-
static void omap_uart_block_sleep(struct omap_uart_state *uart)
{
omap_uart_enable_clocks(uart);
@@ -267,7 +202,28 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
}
}
+/*
+ * 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);
+}
+
+static void omap_uart_set_forceidle(struct platform_device *pdev)
+{
+ struct omap_device *od = to_omap_device(pdev);
+
+ omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_FORCE);
+}
+
#else
+static void omap_uart_set_noidle(struct platform_device *pdev) {}
+static void omap_uart_set_forceidle(struct platform_device *pdev) {}
static void omap_uart_block_sleep(struct omap_uart_state *uart)
{
/* Needed to enable UART clocks when built without CONFIG_PM */
@@ -473,13 +429,19 @@ void __init omap_serial_init_port(struct
[PATCH v8 12/20] OMAP2+: UART: Add wakeup mechanism for omap-uarts
From the runtime callbacks enable hwmod wakeups for uart which will
internally enable io-pad wakeups for uarts if they have rx-pad pins
set as wakeup capabale.
Use the io-ring wakeup mechanism after uart clock gating and leave
the PM_WKST set for uart to default reset values cleanup the
code in serial.c which was handling PM_WKST reg.
Irq_chaing(PRM_DRIVER) is used to wakeup uart after uart clocks are gated
using pad wakeup mechanism.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 96 +++-
arch/arm/plat-omap/include/plat/omap-serial.h |2 +
drivers/tty/serial/omap-serial.c | 15
3 files changed, 29 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a52bd99..d1d8b88 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -56,10 +56,6 @@ struct omap_uart_state {
int num;
int can_sleep;
- void __iomem *wk_st;
- void __iomem *wk_en;
- u32 wk_mask;
-
int clocked;
struct list_head node;
@@ -92,26 +88,6 @@ static inline void omap_uart_disable_clocks(struct
omap_uart_state *uart)
omap_device_idle(uart-pdev);
}
-static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
-{
- /* Set wake-enable bit */
- if (uart-wk_en uart-wk_mask) {
- u32 v = __raw_readl(uart-wk_en);
- v |= uart-wk_mask;
- __raw_writel(v, uart-wk_en);
- }
-}
-
-static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
-{
- /* Clear wake-enable bit */
- if (uart-wk_en uart-wk_mask) {
- u32 v = __raw_readl(uart-wk_en);
- v = ~uart-wk_mask;
- __raw_writel(v, uart-wk_en);
- }
-}
-
static void omap_uart_block_sleep(struct omap_uart_state *uart)
{
omap_uart_enable_clocks(uart);
@@ -141,65 +117,17 @@ int omap_uart_can_sleep(void)
return can_sleep;
}
-static void omap_uart_idle_init(struct omap_uart_state *uart)
+static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{
- int ret;
-
- uart-can_sleep = 0;
- omap_uart_smart_idle_enable(uart, 0);
+ struct omap_device *od = to_omap_device(pdev);
- if (cpu_is_omap34xx() !cpu_is_ti816x()) {
- u32 mod = (uart-num 1) ? OMAP3430_PER_MOD : CORE_MOD;
- u32 wk_mask = 0;
+ if (!od)
+ return;
- /* XXX These PRM accesses do not belong here */
- uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
- uart-wk_st = OMAP34XX_PRM_REGADDR(mod, PM_WKST1);
- switch (uart-num) {
- case 0:
- wk_mask = OMAP3430_ST_UART1_MASK;
- break;
- case 1:
- wk_mask = OMAP3430_ST_UART2_MASK;
- break;
- case 2:
- wk_mask = OMAP3430_ST_UART3_MASK;
- break;
- case 3:
- wk_mask = OMAP3630_ST_UART4_MASK;
- break;
- }
- uart-wk_mask = wk_mask;
- } else if (cpu_is_omap24xx()) {
- u32 wk_mask = 0;
- u32 wk_en = PM_WKEN1, wk_st = PM_WKST1;
-
- switch (uart-num) {
- case 0:
- wk_mask = OMAP24XX_ST_UART1_MASK;
- break;
- case 1:
- wk_mask = OMAP24XX_ST_UART2_MASK;
- break;
- case 2:
- wk_en = OMAP24XX_PM_WKEN2;
- wk_st = OMAP24XX_PM_WKST2;
- wk_mask = OMAP24XX_ST_UART3_MASK;
- break;
- }
- uart-wk_mask = wk_mask;
- if (cpu_is_omap2430()) {
- uart-wk_en = OMAP2430_PRM_REGADDR(CORE_MOD, wk_en);
- uart-wk_st = OMAP2430_PRM_REGADDR(CORE_MOD, wk_st);
- } else if (cpu_is_omap2420()) {
- uart-wk_en = OMAP2420_PRM_REGADDR(CORE_MOD, wk_en);
- uart-wk_st = OMAP2420_PRM_REGADDR(CORE_MOD, wk_st);
- }
- } else {
- uart-wk_en = NULL;
- uart-wk_st = NULL;
- uart-wk_mask = 0;
- }
+ if (enable)
+ omap_hwmod_enable_wakeup(od-hwmods[0]);
+ else
+ omap_hwmod_disable_wakeup(od-hwmods[0]);
}
/*
@@ -222,6 +150,8 @@ static void omap_uart_set_forceidle(struct platform_device
*pdev)
}
#else
+static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
+{}
static void omap_uart_set_noidle(struct platform_device *pdev) {}
static void omap_uart_set_forceidle(struct platform_device *pdev) {}
static void
[PATCH v8 13/20] OMAP2+: UART: Remove old and unused clocks handling funcs
With runtime adaptation done remove clock_enable/disbale API's
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 36
1 files changed, 0 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index d1d8b88..6d574f0 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -56,8 +56,6 @@ struct omap_uart_state {
int num;
int can_sleep;
- int clocked;
-
struct list_head node;
struct omap_hwmod *oh;
struct platform_device *pdev;
@@ -66,36 +64,8 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
-static inline void omap_uart_enable_clocks(struct omap_uart_state *uart)
-{
- if (uart-clocked)
- return;
-
- omap_device_enable(uart-pdev);
- uart-clocked = 1;
- omap_uart_restore_context(uart);
-}
-
#ifdef CONFIG_PM
-static inline void omap_uart_disable_clocks(struct omap_uart_state *uart)
-{
- if (!uart-clocked)
- return;
-
- omap_uart_save_context(uart);
- uart-clocked = 0;
- omap_device_idle(uart-pdev);
-}
-
-static void omap_uart_block_sleep(struct omap_uart_state *uart)
-{
- omap_uart_enable_clocks(uart);
-
- omap_uart_smart_idle_enable(uart, 0);
- uart-can_sleep = 0;
-}
-
int omap_uart_can_sleep(void)
{
struct omap_uart_state *uart;
@@ -154,11 +124,6 @@ static void omap_uart_enable_wakeup(struct platform_device
*pdev, bool enable)
{}
static void omap_uart_set_noidle(struct platform_device *pdev) {}
static void omap_uart_set_forceidle(struct platform_device *pdev) {}
-static void omap_uart_block_sleep(struct omap_uart_state *uart)
-{
- /* Needed to enable UART clocks when built without CONFIG_PM */
- omap_uart_enable_clocks(uart);
-}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
@@ -404,7 +369,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
omap_device_enable(uart-pdev);
omap_device_idle(uart-pdev);
- omap_uart_block_sleep(uart);
console_unlock();
if ((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 14/20] OMAP2+: UART: Allow UART parameters to be configured from board file.
From: Deepak K deepa...@ti.com
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The auto suspend delay that will be passed for pm_runtime_autosuspend
where uart will be disabled after timeout
Different UARTs may be used for different purpose such as the console,
for interfacing bluetooth chip, for interfacing to a modem chip, etc.
Therefore, it is necessary to be able to customize the above settings
for a given board on a per UART basis.
This change allows these parameters to be configured from the board file
and allows the parameters to be configured for each UART independently.
If a board does not define its own custom parameters for the UARTs, then
use the default parameters in the structure omap_serial_default_info.
The default parameters are defined to be the same as the current settings
in the UART driver to avoid breaking the UART for any cuurnelty supported
boards. By default, make all boards use the default UART parameters.
Signed-off-by: Deepak K deepa...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-n8x0.c |6 +-
arch/arm/mach-omap2/serial.c | 56 -
arch/arm/plat-omap/include/plat/omap-serial.h |7 ++-
arch/arm/plat-omap/include/plat/serial.h |5 ++-
drivers/tty/serial/omap-serial.c |8 +--
5 files changed, 60 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index e9d5f4a..fbafa71 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -644,15 +644,15 @@ static inline void board_serial_init(void)
bdata.pads_cnt = 0;
bdata.id = 0;
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
bdata.id = 1;
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
bdata.id = 2;
bdata.pads = serial2_pads;
bdata.pads_cnt = ARRAY_SIZE(serial2_pads);
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
}
#else
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 6d574f0..3eb2469 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -43,12 +43,12 @@
#include mux.h
/*
- * NOTE: By default the serial timeout is disabled as it causes lost characters
- * over the serial ports. This means that the UART clocks will stay on until
- * disabled via sysfs. This also causes that any deeper omap sleep states are
- * blocked.
+ * 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_TIMEOUT 0
+#define DEFAULT_AUTOSUSPEND_DELAY -1
#define MAX_UART_HWMOD_NAME_LEN16
@@ -64,6 +64,18 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
+#define DEFAULT_RXDMA_TIMEOUT 1 /* RX DMA polling rate (us) */
+#define DEFAULT_RXDMA_BUFSIZE 4096/* RX DMA buffer size */
+
+static struct omap_uart_port_info omap_serial_default_info[] __initdata = {
+ {
+ .dma_enabled= false,
+ .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
+ .autosuspend_timeout = DEFAULT_AUTOSUSPEND_DELAY,
+ },
+};
+
#ifdef CONFIG_PM
int omap_uart_can_sleep(void)
@@ -294,6 +306,7 @@ 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()
@@ -302,7 +315,8 @@ core_initcall(omap_serial_early_init);
* 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)
+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;
@@ -322,17 +336,22 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
list_for_each_entry(uart, uart_list, node)
if (bdata-id == uart-num)
break;
+ if (!info)
+ info = omap_serial_default_info;
oh = uart-oh;
name = DRIVER_NAME;
-
[PATCH v8 16/20] OMAP2+: UART: remove temporary variable used to count uart instance
Reuse the num_uarts variable itself to count number of uarts.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5c6c48f..4d65d00 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -266,15 +266,13 @@ static void omap_serial_fill_default_pads(struct
omap_board_data *bdata) {}
static int __init omap_serial_early_init(void)
{
- int i = 0;
-
do {
char oh_name[MAX_UART_HWMOD_NAME_LEN];
struct omap_hwmod *oh;
struct omap_uart_state *uart;
snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
-uart%d, i + 1);
+uart%d, num_uarts + 1);
oh = omap_hwmod_lookup(oh_name);
if (!oh)
break;
@@ -284,9 +282,8 @@ static int __init omap_serial_early_init(void)
return -ENODEV;
uart-oh = oh;
- uart-num = i++;
+ uart-num = num_uarts++;
list_add_tail(uart-node, uart_list);
- num_uarts++;
/*
* NOTE: omap_hwmod_setup*() has not yet been called,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 17/20] OMAP2+: UART: Use custom activate func for console uart.
Omap-uart can be used as console uart to print early boot
messages using earlyprintk so for console uart prevent
hwmod reset or idling during bootup.
Identify the console_uart set the id and use the custom
pm_latency ops for console uart for the first time
to idle console uart left enabled from bootup and then enable
them back and reset pm_latency ops to default ops.
Thanks to Kevin Hilman khil...@ti.com for suggesting
this approach.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 86 +
1 files changed, 61 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 4d65d00..631d72a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -61,8 +61,10 @@ struct omap_uart_state {
struct platform_device *pdev;
};
+static struct omap_device_pm_latency *default_uart_latency;
static LIST_HEAD(uart_list);
static u8 num_uarts;
+static u8 console_uart_id = -1;
#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
#define DEFAULT_RXDMA_BUFSIZE 4096/* RX DMA buffer size */
@@ -78,6 +80,34 @@ static struct omap_uart_port_info omap_serial_default_info[]
__initdata = {
},
};
+static int console_uart_enable_hwmod(struct omap_device *od)
+{
+ console_lock();
+ /*
+* For early console we prevented hwmod reset and idle
+* So before we enable the uart clocks idle the console
+* uart clocks, then enable back the console uart hwmod.
+*/
+ omap_hwmod_idle(od-hwmods[0]);
+ omap_hwmod_enable(od-hwmods[0]);
+ console_unlock();
+
+ /*
+* Restore the default activate/deactivate funcs,
+* since now we have set the hwmod state machine right
+* with the idle/enable for console uart
+*/
+ od-pm_lats = default_uart_latency;
+
+ return 0;
+}
+
+static struct omap_device_pm_latency console_uart_latency[] = {
+ {
+ .activate_func = console_uart_enable_hwmod,
+ },
+};
+
#ifdef CONFIG_PM
int omap_uart_can_sleep(void)
@@ -264,12 +294,20 @@ static void omap_serial_fill_default_pads(struct
omap_board_data *bdata)
static void omap_serial_fill_default_pads(struct omap_board_data *bdata) {}
#endif
+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);
@@ -284,18 +322,23 @@ static int __init omap_serial_early_init(void)
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;
+ /*
+* 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;
+ }
- /*
-* NOTE: omap_hwmod_setup*() has not yet been called,
-* so no hwmod functions will work yet.
-*/
-
- /*
-* During UART early init, device need to be probed
-* to determine SoC specific init before omap_device
-* is ready. Therefore, don't allow idle here
-*/
- uart-oh-flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
} while (1);
return 0;
@@ -324,6 +367,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
u32 pdata_size = 0;
char *name;
struct omap_uart_port_info omap_up;
+ struct omap_device *od;
if (WARN_ON(!bdata))
return;
@@ -369,6 +413,12 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
WARN(IS_ERR(pdev), Could not build omap_device for %s: %s.\n,
name, oh-name);
+ if (console_uart_id == bdata-id) {
+ od =
[PATCH v8 15/20] OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART
From: Jon Hunter jon-hun...@ti.com
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
The secound timeout, RX_TIMEOUT, is a timeout after which the
DMA will be stopped if no more data is received. To make this
clearer, rename rx_timeout as rx_poll_rate and rename the
function serial_omap_rx_timeout() to serial_omap_rxdma_poll().
The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is
used to indicate when the DMA for UART can be stopped if no more
data is received. The value is a global definition that is applied
to all instances of the UART.
Each UART may be used for a different purpose and so the timeout
required may differ. Make this value configurable for each UART so
that this value can be optimised for power savings.
Acked-by: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |5 -
arch/arm/plat-omap/include/plat/omap-serial.h |3 ++-
drivers/tty/serial/omap-serial.c | 15 ---
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3eb2469..5c6c48f 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -64,13 +64,15 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
-#define DEFAULT_RXDMA_TIMEOUT 1 /* RX DMA polling rate (us) */
+#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,
},
@@ -351,6 +353,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
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;
/* Enable the MDR1 errata for OMAP2/3/4 */
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 84906e9..e05c8da 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -53,7 +53,6 @@
#define OMAP_UART_DMA_CH_FREE -1
-#define RX_TIMEOUT (3 * HZ)
#define OMAP_MAX_HSUART_PORTS 4
#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
@@ -68,6 +67,7 @@ struct omap_uart_port_info {
unsigned intdma_rx_buf_size;
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
+ unsigned intdma_rx_poll_rate;
int (*get_context_loss_count)(struct device *);
void (*set_forceidle)(struct platform_device *);
@@ -97,6 +97,7 @@ struct uart_omap_dma {
/* timer to poll activity on rx dma */
struct timer_list rx_timer;
unsigned intrx_buf_size;
+ unsigned intrx_poll_rate;
unsigned intrx_timeout;
};
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 297fcec..be55a5d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -47,7 +47,7 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
static void uart_tx_dma_callback(int lch, u16 ch_status, void *data);
-static void serial_omap_rx_timeout(unsigned long uart_no);
+static void serial_omap_rxdma_poll(unsigned long uart_no);
static int serial_omap_start_rxdma(struct uart_omap_port *up);
static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
@@ -542,7 +542,7 @@ static int serial_omap_startup(struct uart_port *port)
(dma_addr_t *)(up-uart_dma.tx_buf_dma_phys),
0);
init_timer((up-uart_dma.rx_timer));
- up-uart_dma.rx_timer.function = serial_omap_rx_timeout;
+ up-uart_dma.rx_timer.function = serial_omap_rxdma_poll;
up-uart_dma.rx_timer.data = up-pdev-id;
/* Currently the buffer size is 4KB. Can increase it */
up-uart_dma.rx_buf = dma_alloc_coherent(NULL,
@@ -1160,7
[PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
If OMAP UART is used as console uart and debug is enabled,
avoid gating of uart clocks to print all debug prints.
If uart clocks are gated then the debug prints from omap_device
framework or hwmod framework can cause uart to enter recursive
pm_runtime calls, which can cause a deadlock over power lock usage.
For example: Say, uart clocks are cut and we get a print from
omap_device_disable stating disabling uart clocks. This print
calls omap_uart driver console_write which will call runtime API
get_sync which means we enter from runtime API put context to
runtime API get context.
-- runtime put (take power lock)
-- print disabling uart clocks
-- call uart console write
-- call get_sync (try to take power lock)
Also any clock enable API call from uart driver should not call any uart
operation until clocks are enabled back. Like get_sync having debug print
calling uart console write even before clocks are enabled.
So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used
in debug mode. If so, do not set device_may_wakeup. This will prevent
pm_runtime_enable in uart driver and will avoid uart clock gating.
Debug is enabled either by adding debug word in bootarg or by setting
loglevel=10
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5d910ef..a5d9c9c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -66,6 +66,7 @@ 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 */
@@ -329,6 +330,13 @@ static int __init omap_serial_early_init(void)
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;
@@ -432,7 +440,8 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
oh-dev_attr = uart;
- if ((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads)
+ if (((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads)
+!uart_debug)
device_init_wakeup(pdev-dev, true);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 18/20] OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecase
If no_console_suspend is used we have prevent uart idling during suspend
to provide debug prints.
Power domain hooks can idle uarts if left enabled during system wide suspend
so re-use the omap_device_disable_idle_on_suspend API's to ensure console_uart
is not idled during suspend.
omap_device_disable_idle_on_suspend API was used on all uarts since the uart
driver was not runtime adapted, now with runtime adaptation we can re-use this
API only for no_console_suspend use cases.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 631d72a..5d910ef 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -65,6 +65,7 @@ static struct omap_device_pm_latency *default_uart_latency;
static LIST_HEAD(uart_list);
static u8 num_uarts;
static u8 console_uart_id = -1;
+static u8 no_console_suspend;
#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
#define DEFAULT_RXDMA_BUFSIZE 4096/* RX DMA buffer size */
@@ -327,6 +328,10 @@ static int __init omap_serial_early_init(void)
if (cmdline_find_option(uart_name)) {
console_uart_id = 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
@@ -417,9 +422,10 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
od = to_omap_device(pdev);
default_uart_latency = od-pm_lats;
od-pm_lats = console_uart_latency;
+ if (no_console_suspend)
+ omap_device_disable_idle_on_suspend(pdev);
}
- omap_device_disable_idle_on_suspend(pdev);
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
uart-pdev = pdev;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 20/20] OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
Omap_uart_can_sleep function blocks system wide low power state until
uart is active remove this func and add qos requests to prevent
MPU from transitioning.
Keep qos request to default value which will allow MPU to transition
and while uart baud rate is available calculate the latency value
from the baudrate and use the same to hold constraint while uart clocks
are enabled, and if uart is auto-idled the constraint is updated with
default constraint value allowing MPU to transition.
Qos requests are blocking notifier calls so put these requests to
work queue, also the driver uses irq_safe version of runtime API's
and callbacks can be called in interrupt disabled context.
So to avoid warn on slow path warning while using qos update
API's from runtime callbacks use the qos_work_queue.
During bootup the runtime_resume call backs might not be called and runtime
callback gets called only after uart is idled by setting the autosuspend
timeout. So qos_request from runtime resume callback might not activated during
boot if uart baudrate is calculated during bootup for console uart, so schedule
the qos_work queue once we calc_latency while configuring the uart port.
Flush and complete any pending qos jobs in work queue while suspending.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |5 ---
arch/arm/mach-omap2/pm24xx.c |2 -
arch/arm/mach-omap2/pm34xx.c | 10 ---
arch/arm/mach-omap2/serial.c | 22 ---
arch/arm/plat-omap/include/plat/omap-serial.h |6
drivers/tty/serial/omap-serial.c | 36 -
6 files changed, 41 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1fe35c2..6b4ed89 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -243,11 +243,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
struct omap3_idle_statedata *cx;
int ret;
- if (!omap3_can_sleep()) {
- new_state_idx = drv-safe_state_index;
- goto select_state;
- }
-
/*
* Prevent idle completely if CAM is active.
* CAM does not have wakeup capability in OMAP3.
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 5ec2b43..3a9e80b 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -221,8 +221,6 @@ static int omap2_can_sleep(void)
{
if (omap2_fclks_active())
return 0;
- if (!omap_uart_can_sleep())
- return 0;
if (osc_ck-usecount 1)
return 0;
if (omap_dma_running())
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2eb3215..6edcca8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -417,21 +417,11 @@ void omap_sram_idle(void)
clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
-int omap3_can_sleep(void)
-{
- if (!omap_uart_can_sleep())
- return 0;
- return 1;
-}
-
static void omap3_pm_idle(void)
{
local_irq_disable();
local_fiq_disable();
- if (!omap3_can_sleep())
- goto out;
-
if (omap_irq_pending() || need_resched())
goto out;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a5d9c9c..cf7484a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -111,28 +111,6 @@ static struct omap_device_pm_latency
console_uart_latency[] = {
};
#ifdef CONFIG_PM
-
-int omap_uart_can_sleep(void)
-{
- struct omap_uart_state *uart;
- int can_sleep = 1;
-
- list_for_each_entry(uart, uart_list, node) {
- if (!uart-clocked)
- continue;
-
- if (!uart-can_sleep) {
- can_sleep = 0;
- continue;
- }
-
- /* This UART can now safely sleep. */
- omap_uart_allow_sleep(uart);
- }
-
- return can_sleep;
-}
-
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{
struct omap_device *od = to_omap_device(pdev);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index e05c8da..f685150 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -19,6 +19,7 @@
#include linux/serial_core.h
#include linux/platform_device.h
+#include linux/pm_qos.h
#include plat/mux.h
@@ -129,6 +130,11 @@ struct uart_omap_port {
u32 context_loss_cnt;
u32 errata;
u8 wakeups_enabled;
+
+ struct pm_qos_request pm_qos_request;
+ u32 latency;
+ u32
Re: [PATCH v7 11/21] OMAP2+: UART: Move errata handling from serial.c to omap-serial
Hi Jon, On Fri, Nov 11, 2011 at 5:14 AM, Jon Hunter jon-hun...@ti.com wrote: Hi Govindraj, On 10/18/2011 10:26, Govindraj.R wrote: Move the errata handling mechanism from serial.c to omap-serial file and utilise the same func in driver file. Errata i202, i291 are moved to be handled with omap-serial Moving the errata macro from serial.c file to driver header file as from on errata will be handled in driver file itself. Corrected errata id from chapter reference 2.15 to errata id i291. Removed errata and dma_enabled feilds from omap_uart_state struct as they are no more needed with errata handling done within omap-serial. Acked-by: Alan Coxa...@linux.intel.com Signed-off-by: Govindraj.Rgovindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 97 +++-- arch/arm/plat-omap/include/plat/omap-serial.h | 6 ++ drivers/tty/serial/omap-serial.c | 66 - 3 files changed, 95 insertions(+), 74 deletions(-) [snip] + /* Enable the MDR1 errata for OMAP3 */ + if (cpu_is_omap34xx() !cpu_is_ti816x()) + omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS; This errata (i202) is applicable to all devices from OMAP2430 to OMAP4460 (apparently this one is not getting fixed). So could you make sure this is enabled for 2430, 3430, 3630, 4430 and 4460? [snip] Thanks for the info, Have posted a updated the patch [1] +/* + * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6) We should update the comment to be Work Around for Errata i202 (2430, 3430, 3630, 4430 and 4460). The 1.12 and 1.6 are just the section references in the errata docs, but I think that you can drop these as you can just search for the errata ID which is i202. yes corrected [1] -- Thanks, Govindraj.R [1]: http://www.spinics.net/lists/linux-serial/msg04841.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 17/21] OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
On Fri, Nov 11, 2011 at 12:32 AM, Kevin Hilman khil...@ti.com wrote: Govindraj govindraj...@gmail.com writes: [..] I have fixed this and other uart_v7 comments and have re-based the patch series on top of 3.2-rc1 along with Tero's v9 irq chaining patches and tested the same. Available here [1]. Please repost your updated series. Yes done. v8 posted [1] Can this patches series be added to a test branch for upstreaming or do you think there are still some outstanding comments that needs to be discussed? The PRCM IRQ chaining series is not yet finalized. okay fine. -- Thanks, Govindraj.R [1]: http://www.spinics.net/lists/linux-omap/msg60115.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present
-Original Message-
From: Hilman, Kevin
Sent: Friday, November 11, 2011 12:04 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash
Subject: Re: [PATCH] ARM: OMAP: PM: only register TWL with
voltage layer when device is present
Premi, Sanjeev pr...@ti.com writes:
Current code registers voltage layer details for TWL PMIC
even when a
TWL has not been registered. Fix this to only register
the TWL with
voltage layer when the TWL PMIC is initialized by board-level code.
Signed-off-by: Kevin Hilman khil...@ti.com
[...]
I have been out-of-loop from PM for some time. So my query may be
redundant:
1) What happens when different PMIC (not TWL series) is registered
for AM35x? e.g. TPS65023
http://www.spinics.net/lists/linux-omap/msg48630.html
2) Wouldn't we still fall back into omap3_twl_init()?
I'm not sure I follow the question.
If you're not using a TWL PMIC (or similar derivative) then
omap*_twl_init() should not be called.
If you are using a TWL PMIC, then no, the omap*_twl_init functions
should not be called.
When I read this function (in the patch), if pmic_i2c_board_info.irq
is non-zero, omap3_twl_init() and omap4_twl_init() are called.
So my question was, for the case when PMIC is not TWL family. Then,
is checking .irq sufficient to prevent the execution of twl specific
functions.
void __init omap_pmic_late_init(void)
{
/* Init the OMAP TWL parameters (if PMIC has been registerd) */
if (!pmic_i2c_board_info.irq)
return;
omap3_twl_init();
omap4_twl_init();
}
Shouldn't we check for some signature or equiv, before calling the
PMIC specific init? This signature can be set when the PMIC is
registered?
Another simplification would be to register the PMIC specific init
function itself during registration; and call here.
~sanjeev
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Help with clk API
Hi Paul, I have a doubt about using clk API to change CLKSEL_UTMI_P1 bit for a silicon errata (OMAP4460 i693) implementation. According to errata, I need to switch from external to internal clock during USB port suspend, wait 1ms and switch back from internal to external. How can I do that with clk API ? Is it by changing clk parent ? Any tips would be helpful ;-) thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
[Adding Benoit to CC]. On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote: On Wed, 9 Nov 2011, Ming Lei wrote: Also, current arm perf code don't handle three IRQs(one pl310 irq and two CTI irq) inside one device correctly. To fix this, that ARM perf code should either be using platform_get_irq_byname(), or the hwmod hardware data will need to be rearranged to meet the arbitrary ordering requirement. I'd suggest pinging Will on this issue to see what he wants to do. The issue stems from the fact that we have to route the PMU interrupts to the correct CPU manually (I think only MSM routes them as PPIs, which is clearly the correct thing to do). To do this, we expect the IRQ resources to be laid out in CPU order. In hindsight, maybe naming the resources might have been a good idea, but them we'd still have to generate the names using CPU numbers when iterating through the platform device. So although the ordering requirements are a bit of a pain, I do think it's reasonable for perf to expect that it's not being handed some random other interrupts along with those for the PMU. So the clockdomain is already defined in mach-omap2/clockdomains44xx_data.c and there's code to control it - see for example clkdm_enable_idle(). But this code should not be called directly by any device driver code or driver integration code. The thing to do here is to ask Benoît to release the hwmod data for the DEBUGSS hwmod, then someone will need to write an MFD driver for that which exposes the PMU address space to the PMU platform driver. Benoit? Please can you chime in here? Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote: [Adding Benoit to CC]. On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote: On Wed, 9 Nov 2011, Ming Lei wrote: Also, current arm perf code don't handle three IRQs(one pl310 irq and two CTI irq) inside one device correctly. To fix this, that ARM perf code should either be using platform_get_irq_byname(), or the hwmod hardware data will need to be rearranged to meet the arbitrary ordering requirement. I'd suggest pinging Will on this issue to see what he wants to do. The issue stems from the fact that we have to route the PMU interrupts to the correct CPU manually (I think only MSM routes them as PPIs, which is clearly the correct thing to do). To do this, we expect the IRQ resources to be laid out in CPU order. In hindsight, maybe naming the resources might have been a good idea, but them we'd still have to generate the names using CPU numbers when iterating through the platform device. There isn't yet a way to do naming of resources with DT, and although I think there was a proposal for doing named register resources I don't think this has been accepted and there wasn't anything for IRQ resources... Jamie -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Fri, Nov 11, 2011 at 11:47:35AM +, Jamie Iles wrote: On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote: The issue stems from the fact that we have to route the PMU interrupts to the correct CPU manually (I think only MSM routes them as PPIs, which is clearly the correct thing to do). To do this, we expect the IRQ resources to be laid out in CPU order. In hindsight, maybe naming the resources might have been a good idea, but them we'd still have to generate the names using CPU numbers when iterating through the platform device. There isn't yet a way to do naming of resources with DT, and although I think there was a proposal for doing named register resources I don't think this has been accepted and there wasn't anything for IRQ resources... That's good news - means I have an excuse other than laziness for not implementing this for perf :) Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 07:28:39PM +, David Woodhouse wrote: ... which implies that a mapping, once made, might *never* actually get torn down until we loop and start reusing address space? That has interesting security implications. Yes, it is a trade-off between security and performance. But if the user wants more security the unmap_flush parameter can be used. Is it true even for devices which have been assigned to a VM and then unassigned? No, this is only used in the DMA-API path. The device-assignment code uses the IOMMU-API directly. There the IOTLB is always flushed on unmap. There is something similar on the AMD IOMMU side. There it is called unmap_flush. OK, so that definitely wants consolidating into a generic option. Agreed. Some time ago I proposed the iommu_commit() interface which changes these requirements. With this interface the requirement is that after a couple of map/unmap operations the IOMMU-API user has to call iommu_commit() to make these changes visible to the hardware (so mostly sync the IOTLBs). As discussed at that time this would make sense for the Intel and AMD IOMMU drivers. I would *really* want to keep those off the fast path (thinking mostly about DMA API here, since that's the performance issue). But as long as we can achieve that, that's fine. For AMD IOMMU there is a feature called not-present cache. It says that the IOMMU caches non-present entries as well and needs an IOTLB flush when something is mapped (meant for software implementations of the IOMMU). So it can't be really taken out of the fast-path. But the IOMMU driver can optimize the function so that it only flushes the IOTLB when there was an unmap-call before. It is also an improvement over the current situation where every iommu_unmap call results in a flush implicitly. This pretty much a no-go for using IOMMU-API in DMA mapping at the moment. But also, it's not *so* much of an issue to divide the space up even when it's limited. The idea was not to have it *strictly* per-CPU, but just for a CPU to try allocating from its own subrange first, and then fall back to allocating a new subrange, and *then* fall back to allocating from subranges belonging to other CPUs. It's not that the allocation from a subrange would be lockless — it's that the lock would almost never leave the l1 cache of the CPU that *normally* uses that subrange. Yeah, I get the idea. I fear that the memory consumption will get pretty high with that approach. It basically means one round-robin allocator per cpu and device. What does that mean on a 4096 CPU machine :) How much lock contention will be lowered also depends on the work-load. If dma-handles are frequently freed from another cpu than they were allocated from the same problem re-appears. But in the end we have to try it out and see what works best :) Regards, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] OMAPDSS: HDMI: Move duplicate code from boardfile to
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
arch/arm/mach-omap2/display.c | 23 +++
include/video/omapdss.h|2 ++
4 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73b1e99..4a519a3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -595,20 +595,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static void sdp4430_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
@@ -838,9 +824,9 @@ static void omap_4430sdp_display_init(void)
pr_err(%s: Could not get display_sel GPIO\n, __func__);
sdp4430_lcd_init();
- sdp4430_hdmi_mux_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
+ omap_hdmi_enable_pads();
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a5b576b..26c6440 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -478,21 +478,6 @@ int __init omap4_panda_dvi_init(void)
return r;
}
-
-static void omap4_panda_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
@@ -555,8 +540,8 @@ void omap4_panda_display_init(void)
if (r)
pr_err(error initializing panda DVI\n);
- omap4_panda_hdmi_mux_init();
omap_display_init(omap4_panda_dss_data);
+ omap_hdmi_enable_pads();
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index dce9905..ec7ac1b 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -29,6 +29,7 @@
#include plat/omap-pm.h
#include plat/common.h
+#include mux.h
#include control.h
#include display.h
@@ -96,6 +97,20 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static void omap4_hdmi_mux_pads(void)
+{
+ /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
+ omap_mux_init_signal(hdmi_hpd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_cec,
+ OMAP_PIN_INPUT_PULLUP);
+ /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
+ omap_mux_init_signal(hdmi_ddc_scl,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_ddc_sda,
+ OMAP_PIN_INPUT_PULLUP);
+}
+
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift;
@@ -129,6 +144,14 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
+int omap_hdmi_enable_pads(void)
+{
+ if (cpu_is_omap44xx())
+ omap4_hdmi_mux_pads();
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
if (cpu_is_omap44xx())
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 378c7ed..f4913d6 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -309,6 +309,8 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+/* HDMI mux init*/
+extern int omap_hdmi_enable_pads(void);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this
[PATCH v2 1/2] OMAPDSS: HDMI: Move duplicate code from boardfile to
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
arch/arm/mach-omap2/display.c | 23 +++
include/video/omapdss.h|2 ++
4 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73b1e99..4a519a3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -595,20 +595,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static void sdp4430_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
@@ -838,9 +824,9 @@ static void omap_4430sdp_display_init(void)
pr_err(%s: Could not get display_sel GPIO\n, __func__);
sdp4430_lcd_init();
- sdp4430_hdmi_mux_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
+ omap_hdmi_enable_pads();
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a5b576b..26c6440 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -478,21 +478,6 @@ int __init omap4_panda_dvi_init(void)
return r;
}
-
-static void omap4_panda_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
@@ -555,8 +540,8 @@ void omap4_panda_display_init(void)
if (r)
pr_err(error initializing panda DVI\n);
- omap4_panda_hdmi_mux_init();
omap_display_init(omap4_panda_dss_data);
+ omap_hdmi_enable_pads();
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index dce9905..ec7ac1b 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -29,6 +29,7 @@
#include plat/omap-pm.h
#include plat/common.h
+#include mux.h
#include control.h
#include display.h
@@ -96,6 +97,20 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static void omap4_hdmi_mux_pads(void)
+{
+ /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
+ omap_mux_init_signal(hdmi_hpd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_cec,
+ OMAP_PIN_INPUT_PULLUP);
+ /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
+ omap_mux_init_signal(hdmi_ddc_scl,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_ddc_sda,
+ OMAP_PIN_INPUT_PULLUP);
+}
+
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift;
@@ -129,6 +144,14 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
+int omap_hdmi_enable_pads(void)
+{
+ if (cpu_is_omap44xx())
+ omap4_hdmi_mux_pads();
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
if (cpu_is_omap44xx())
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 378c7ed..f4913d6 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -309,6 +309,8 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+/* HDMI mux init*/
+extern int omap_hdmi_enable_pads(void);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this
[PATCH v2 2/2] OMAPDSS: HDMI: Disable HDMI DDC internal pull up
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL enabled by
default as there are expernal pull up's in 4460 and 4430 ES2.3,
It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 12 +++-
arch/arm/mach-omap2/board-omap4panda.c | 13 -
arch/arm/mach-omap2/display.c | 17 ++---
include/video/omapdss.h|2 +-
4 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 4a519a3..91d3742 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -826,7 +826,17 @@ static void omap_4430sdp_display_init(void)
sdp4430_lcd_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
- omap_hdmi_enable_pads();
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor - This is a change needed in
+* OMAP4460 and OMAP4430 ES2.3 as the external pull up
+* are present. This is needed to avoid EDID read failure.
+*/
+ if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2))
+ omap_hdmi_enable_pads(1);
+ else
+ omap_hdmi_enable_pads(0);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 26c6440..a4e7bf8 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -541,7 +541,18 @@ void omap4_panda_display_init(void)
pr_err(error initializing panda DVI\n);
omap_display_init(omap4_panda_dss_data);
- omap_hdmi_enable_pads();
+
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor - This is a change needed in
+* OMAP4460 and OMAP4430 ES2.3 as the external pull up
+* are present. This is needed to avoid EDID read failure.
+*/
+ if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2))
+ omap_hdmi_enable_pads(1);
+ else
+ omap_hdmi_enable_pads(0);
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ec7ac1b..8af5714 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -97,8 +97,11 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
-static void omap4_hdmi_mux_pads(void)
+static void omap4_hdmi_mux_pads(int ext_pull_up)
{
+ u32 reg;
+ u16 control_i2c_1;
+
/* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
omap_mux_init_signal(hdmi_hpd,
OMAP_PIN_INPUT_PULLUP);
@@ -109,6 +112,14 @@ static void omap4_hdmi_mux_pads(void)
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
OMAP_PIN_INPUT_PULLUP);
+
+ if (ext_pull_up) {
+ control_i2c_1 = OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_1;
+ reg = omap4_ctrl_pad_readl(control_i2c_1);
+ reg |= (OMAP4_HDMI_DDC_SDA_PULLUPRESX_MASK |
+ OMAP4_HDMI_DDC_SCL_PULLUPRESX_MASK);
+ omap4_ctrl_pad_writel(reg, control_i2c_1);
+ }
}
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
@@ -144,10 +155,10 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
-int omap_hdmi_enable_pads(void)
+int omap_hdmi_enable_pads(int ext_pull_up)
{
if (cpu_is_omap44xx())
- omap4_hdmi_mux_pads();
+ omap4_hdmi_mux_pads(ext_pull_up);
return 0;
}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index f4913d6..27b71f4 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -310,7 +310,7 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
/* HDMI mux init*/
-extern int omap_hdmi_enable_pads(void);
+extern int omap_hdmi_enable_pads(int ext_pull_up);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] OMAPDSS: HDMI: Disable HDMI DDC internal pull up
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL enabled by
default as there are expernal pull up's in 4460 and 4430 ES2.3,
It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 12 +++-
arch/arm/mach-omap2/board-omap4panda.c | 13 -
arch/arm/mach-omap2/display.c | 17 ++---
include/video/omapdss.h|2 +-
4 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 4a519a3..91d3742 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -826,7 +826,17 @@ static void omap_4430sdp_display_init(void)
sdp4430_lcd_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
- omap_hdmi_enable_pads();
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor - This is a change needed in
+* OMAP4460 and OMAP4430 ES2.3 as the external pull up
+* are present. This is needed to avoid EDID read failure.
+*/
+ if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2))
+ omap_hdmi_enable_pads(1);
+ else
+ omap_hdmi_enable_pads(0);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 26c6440..a4e7bf8 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -541,7 +541,18 @@ void omap4_panda_display_init(void)
pr_err(error initializing panda DVI\n);
omap_display_init(omap4_panda_dss_data);
- omap_hdmi_enable_pads();
+
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor - This is a change needed in
+* OMAP4460 and OMAP4430 ES2.3 as the external pull up
+* are present. This is needed to avoid EDID read failure.
+*/
+ if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2))
+ omap_hdmi_enable_pads(1);
+ else
+ omap_hdmi_enable_pads(0);
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ec7ac1b..8af5714 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -97,8 +97,11 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
-static void omap4_hdmi_mux_pads(void)
+static void omap4_hdmi_mux_pads(int ext_pull_up)
{
+ u32 reg;
+ u16 control_i2c_1;
+
/* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
omap_mux_init_signal(hdmi_hpd,
OMAP_PIN_INPUT_PULLUP);
@@ -109,6 +112,14 @@ static void omap4_hdmi_mux_pads(void)
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
OMAP_PIN_INPUT_PULLUP);
+
+ if (ext_pull_up) {
+ control_i2c_1 = OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_1;
+ reg = omap4_ctrl_pad_readl(control_i2c_1);
+ reg |= (OMAP4_HDMI_DDC_SDA_PULLUPRESX_MASK |
+ OMAP4_HDMI_DDC_SCL_PULLUPRESX_MASK);
+ omap4_ctrl_pad_writel(reg, control_i2c_1);
+ }
}
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
@@ -144,10 +155,10 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
-int omap_hdmi_enable_pads(void)
+int omap_hdmi_enable_pads(int ext_pull_up)
{
if (cpu_is_omap44xx())
- omap4_hdmi_mux_pads();
+ omap4_hdmi_mux_pads(ext_pull_up);
return 0;
}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index f4913d6..27b71f4 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -310,7 +310,7 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
/* HDMI mux init*/
-extern int omap_hdmi_enable_pads(void);
+extern int omap_hdmi_enable_pads(int ext_pull_up);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] OMAPDSS: HDMI: remove duplicate video interface code
From: Mythri P K mythr...@ti.com
video interface structure is a duplicate structure with parameters which are
already present in ip_data config structure, Thus removing the structure and
modifying corresponding code.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 31 +++-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |7 --
2 files changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e1a6ce5..403d6fc 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -629,8 +629,7 @@ static void hdmi_core_av_packet_config(struct hdmi_ip_data
*ip_data,
}
static void hdmi_wp_init(struct omap_video_timings *timings,
- struct hdmi_video_format *video_fmt,
- struct hdmi_video_interface *video_int)
+ struct hdmi_video_format *video_fmt)
{
pr_debug(Enter hdmi_wp_init\n);
@@ -645,12 +644,6 @@ static void hdmi_wp_init(struct omap_video_timings
*timings,
video_fmt-y_res = 0;
video_fmt-x_res = 0;
- video_int-vsp = 0;
- video_int-hsp = 0;
-
- video_int-interlacing = 0;
- video_int-tm = 0; /* HDMI_TIMING_SLAVE */
-
}
void ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
@@ -687,17 +680,16 @@ static void hdmi_wp_video_config_format(struct
hdmi_ip_data *ip_data,
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_SIZE, l);
}
-static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data,
- struct hdmi_video_interface *video_int)
+static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data)
{
u32 r;
pr_debug(Enter hdmi_wp_video_config_interface\n);
r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG);
- r = FLD_MOD(r, video_int-vsp, 7, 7);
- r = FLD_MOD(r, video_int-hsp, 6, 6);
- r = FLD_MOD(r, video_int-interlacing, 3, 3);
- r = FLD_MOD(r, video_int-tm, 1, 0);
+ r = FLD_MOD(r, ip_data-cfg.timings.vsync_pol, 7, 7);
+ r = FLD_MOD(r, ip_data-cfg.timings.hsync_pol, 6, 6);
+ r = FLD_MOD(r, ip_data-cfg.interlace, 3, 3);
+ r = FLD_MOD(r, 1, 1, 0); /* HDMI_TIMING_MASTER_24BIT */
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, r);
}
@@ -725,15 +717,13 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
/* HDMI */
struct omap_video_timings video_timing;
struct hdmi_video_format video_format;
- struct hdmi_video_interface video_interface;
/* HDMI core */
struct hdmi_core_infoframe_avi avi_cfg;
struct hdmi_core_video_config v_core_cfg;
struct hdmi_core_packet_enable_repeat repeat_cfg;
struct hdmi_config *cfg = ip_data-cfg;
- hdmi_wp_init(video_timing, video_format,
- video_interface);
+ hdmi_wp_init(video_timing, video_format);
hdmi_core_init(v_core_cfg,
avi_cfg,
@@ -748,12 +738,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
hdmi_wp_video_config_format(ip_data, video_format);
- video_interface.vsp = cfg-timings.vsync_pol;
- video_interface.hsp = cfg-timings.hsync_pol;
- video_interface.interlacing = cfg-interlace;
- video_interface.tm = 1 ; /* HDMI_TIMING_MASTER_24BIT */
-
- hdmi_wp_video_config_interface(ip_data, video_interface);
+ hdmi_wp_video_config_interface(ip_data);
/*
* configure core video part
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 2040956..914bec6 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -517,13 +517,6 @@ struct hdmi_video_format {
u32 x_res; /* pixel per line */
};
-struct hdmi_video_interface {
- int vsp;/* Vsync polarity */
- int hsp;/* Hsync polarity */
- int interlacing;
- int tm; /* Timing mode */
-};
-
struct hdmi_audio_format {
enum hdmi_stereo_channels stereo_channels;
u8 active_chnnls_msk;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] OMAPDSS: HDMI: change the timing match logic
From: Mythri P K mythr...@ti.com
Change the timing match logic, Instead of the statically mapped method
to get the corresponding timings for a given code and mode, move to a
simpler array indexed method. It will help to scale up to add more
timings when needed.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 162 ---
1 files changed, 67 insertions(+), 95 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f76ae47..b859350 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -58,8 +58,6 @@
#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
-#define OMAP_HDMI_TIMINGS_NB 34
-
#define HDMI_DEFAULT_REGN 16
#define HDMI_DEFAULT_REGM2 1
@@ -88,7 +86,7 @@ static struct {
* map it to corresponding CEA or VESA index.
*/
-static const struct hdmi_config cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
+static const struct hdmi_config cea_timings[] = {
{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
@@ -104,6 +102,8 @@ static const struct hdmi_config
cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+};
+static const struct hdmi_config vesa_timings[] = {
/* VESA From Here */
{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
{ {800, 600, 4, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
@@ -126,39 +126,6 @@ static const struct hdmi_config
cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {0x55, HDMI_DVI} }
};
-/*
- * This is a static mapping array which maps the timing values
- * with corresponding CEA / VESA code
- */
-static const int code_index[OMAP_HDMI_TIMINGS_NB] = {
- 1, 19, 4, 2, 37, 6, 21, 20, 5, 16, 17, 29, 31, 35, 32,
- /* --15 CEA 17-- vesa*/
- 4, 9, 0xE, 0x17, 0x1C, 0x27, 0x20, 0x23, 0x10, 0x2A,
- 0X2F, 0x3A, 0X51, 0X52, 0x16, 0x29, 0x39, 0x1B
-};
-
-/*
- * This is reverse static mapping which maps the CEA / VESA code
- * to the corresponding timing values
- */
-static const int code_cea[39] = {
- -1, 0, 3, 3, 2, 8, 5, 5, -1, -1,
- -1, -1, -1, -1, -1, -1, 9, 10, 10, 1,
- 7, 6, 6, -1, -1, -1, -1, -1, -1, 11,
- 11, 12, 14, -1, -1, 13, 13, 4, 4
-};
-
-static const int code_vesa[85] = {
- -1, -1, -1, -1, 15, -1, -1, -1, -1, 16,
- -1, -1, -1, -1, 17, -1, 23, -1, -1, -1,
- -1, -1, 29, 18, -1, -1, -1, 32, 19, -1,
- -1, -1, 21, -1, -1, 22, -1, -1, -1, 20,
- -1, 30, 24, -1, -1, -1, -1, 25, -1, -1,
- -1, -1, -1, -1, -1, -1, -1, 31, 26, -1,
- -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
- -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
- -1, 27, 28, -1, 33};
-
static int hdmi_runtime_get(void)
{
int r;
@@ -188,82 +155,88 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-static int get_timings_index(void)
+static bool hdmi_find_code(const struct hdmi_config *timings_arr,
+ int len, struct hdmi_config *timing)
{
- int code;
+ int i;
- if (hdmi.mode == 0)
- code = code_vesa[hdmi.code];
- else
- code = code_cea[hdmi.code];
+ for (i = 0; i len; i++) {
+ if (timings_arr[i].cm.code == hdmi.code) {
+ *timing = timings_arr[i];
+ return true;
+ }
+ }
+
+ return false;
+}
- if (code == -1) {
+static void hdmi_get_timings(struct hdmi_config *timing)
+{
+ int r;
+
+ if (hdmi.mode == 0) {
+ r = hdmi_find_code(vesa_timings,
+ ARRAY_SIZE(vesa_timings), timing);
+ } else {
+ r = hdmi_find_code(cea_timings,
+ ARRAY_SIZE(cea_timings), timing);
+ }
+ if (!r) {
/* HDMI code 4 corresponds to 640 * 480 VGA */
hdmi.code = 4;
/* DVI mode 1 corresponds to HDMI 0 to DVI */
hdmi.mode = HDMI_DVI;
+ *timing = vesa_timings[0];
+ }
+}
+
+static bool hdmi_timings_compare(struct omap_video_timings *timing,
+ const struct hdmi_video_timings *temp)
+{
+ int timing_vsync, timing_hsync, temp_vsync, temp_hsync;
+
+ if ((temp-pixel_clock == timing-pixel_clock)
+ (temp-x_res == timing-x_res)
+ (temp-y_res == timing-y_res)) {
- code = code_vesa[hdmi.code];
+
[PATCH 0/4] OMAPDSS: HDMI: Improve the timings logic in HDMI
From: Mythri P K mythr...@ti.com There are some duplicate timing structure which are not needed thus removing them to clean the code. Also the static mapped timing structure is quite complicated to add new timings, so simplify it by using array indexed method. Mythri P K (4): OMAPDSS: HDMI: remove duplicate video interface code OMAPDSS: HDMI: update static timing table OMAPDSS: HDMI: change the timing match logic OMAPDSS: HDMI: remove duplicate code and mode parameter drivers/video/omap2/dss/hdmi.c| 246 + drivers/video/omap2/dss/ti_hdmi.h | 14 +- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 47 ++ drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |7 - 4 files changed, 128 insertions(+), 186 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] OMAPDSS: HDMI: remove duplicate code and mode parameter
From: Mythri P K mythr...@ti.com
code and mode parameters are already a part of the ip_data structure
so no need to keep the same parameters again in hdmi global structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index b859350..8d06ce6 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -66,8 +66,6 @@ static struct {
struct omap_display_platform_data *pdata;
struct platform_device *pdev;
struct hdmi_ip_data ip_data;
- int code;
- int mode;
struct clk *sys_clk;
} hdmi;
@@ -161,7 +159,7 @@ static bool hdmi_find_code(const struct hdmi_config
*timings_arr,
int i;
for (i = 0; i len; i++) {
- if (timings_arr[i].cm.code == hdmi.code) {
+ if (timings_arr[i].cm.code == hdmi.ip_data.cfg.cm.code) {
*timing = timings_arr[i];
return true;
}
@@ -174,7 +172,7 @@ static void hdmi_get_timings(struct hdmi_config *timing)
{
int r;
- if (hdmi.mode == 0) {
+ if (hdmi.ip_data.cfg.cm.mode == 0) {
r = hdmi_find_code(vesa_timings,
ARRAY_SIZE(vesa_timings), timing);
} else {
@@ -183,9 +181,9 @@ static void hdmi_get_timings(struct hdmi_config *timing)
}
if (!r) {
/* HDMI code 4 corresponds to 640 * 480 VGA */
- hdmi.code = 4;
+ hdmi.ip_data.cfg.cm.code = 4;
/* DVI mode 1 corresponds to HDMI 0 to DVI */
- hdmi.mode = HDMI_DVI;
+ hdmi.ip_data.cfg.cm.mode = HDMI_DVI;
*timing = vesa_timings[0];
}
}
@@ -335,8 +333,6 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
goto err;
}
- hdmi.ip_data.cfg.cm.mode = hdmi.mode;
- hdmi.ip_data.cfg.cm.code = hdmi.code;
hdmi.ip_data.ops-video_configure(hdmi.ip_data);
/* Make selection of HDMI in DSS */
@@ -396,8 +392,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device
*dssdev)
struct hdmi_cm cm;
cm = hdmi_get_code(dssdev-panel.timings);
- hdmi.code = cm.code;
- hdmi.mode = cm.mode;
+ hdmi.ip_data.cfg.cm.code = cm.code;
+ hdmi.ip_data.cfg.cm.mode = cm.mode;
if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE) {
int r;
@@ -663,7 +659,7 @@ static int hdmi_audio_hw_params(struct hdmi_ip_data
*ip_data,
static int hdmi_audio_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
- if (!hdmi.mode) {
+ if (!hdmi.ip_data.cfg.cm.mode) {
pr_err(Current video settings do not support audio.\n);
return -EIO;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] OMAPDSS: HDMI: update static timing table
From: Mythri P K mythr...@ti.com
Add the vsync polarity, hsync polarity, interlace to hdmi_video_timings.
Remove the now duplicate structure hdmi_timings.
update the static table structure in HDMI with CEA/VESA code and mode.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c| 96 ++--
drivers/video/omap2/dss/ti_hdmi.h | 14 ++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 20 +++---
3 files changed, 63 insertions(+), 67 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c56378c..f76ae47 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -88,42 +88,42 @@ static struct {
* map it to corresponding CEA or VESA index.
*/
-static const struct hdmi_timings cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
- { {640, 480, 25200, 96, 16, 48, 2, 10, 33} , 0 , 0},
- { {1280, 720, 74250, 40, 440, 220, 5, 5, 20}, 1, 1},
- { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1},
- { {720, 480, 27027, 62, 16, 60, 6, 9, 30}, 0, 0},
- { {2880, 576, 108000, 256, 48, 272, 5, 5, 39}, 0, 0},
- { {1440, 240, 27027, 124, 38, 114, 3, 4, 15}, 0, 0},
- { {1440, 288, 27000, 126, 24, 138, 3, 2, 19}, 0, 0},
- { {1920, 540, 74250, 44, 528, 148, 5, 2, 15}, 1, 1},
- { {1920, 540, 74250, 44, 88, 148, 5, 2, 15}, 1, 1},
- { {1920, 1080, 148500, 44, 88, 148, 5, 4, 36}, 1, 1},
- { {720, 576, 27000, 64, 12, 68, 5, 5, 39}, 0, 0},
- { {1440, 576, 54000, 128, 24, 136, 5, 5, 39}, 0, 0},
- { {1920, 1080, 148500, 44, 528, 148, 5, 4, 36}, 1, 1},
- { {2880, 480, 108108, 248, 64, 240, 6, 9, 30}, 0, 0},
- { {1920, 1080, 74250, 44, 638, 148, 5, 4, 36}, 1, 1},
- /* VESA From Here */
- { {640, 480, 25175, 96, 16, 48, 2 , 11, 31}, 0, 0},
- { {800, 600, 4, 128, 40, 88, 4 , 1, 23}, 1, 1},
- { {848, 480, 33750, 112, 16, 112, 8 , 6, 23}, 1, 1},
- { {1280, 768, 79500, 128, 64, 192, 7 , 3, 20}, 1, 0},
- { {1280, 800, 83500, 128, 72, 200, 6 , 3, 22}, 1, 0},
- { {1360, 768, 85500, 112, 64, 256, 6 , 3, 18}, 1, 1},
- { {1280, 960, 108000, 112, 96, 312, 3 , 1, 36}, 1, 1},
- { {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38}, 1, 1},
- { {1024, 768, 65000, 136, 24, 160, 6, 3, 29}, 0, 0},
- { {1400, 1050, 121750, 144, 88, 232, 4, 3, 32}, 1, 0},
- { {1440, 900, 106500, 152, 80, 232, 6, 3, 25}, 1, 0},
- { {1680, 1050, 146250, 176 , 104, 280, 6, 3, 30}, 1, 0},
- { {1366, 768, 85500, 143, 70, 213, 3, 3, 24}, 1, 1},
- { {1920, 1080, 148500, 44, 148, 80, 5, 4, 36}, 1, 1},
- { {1280, 768, 68250, 32, 48, 80, 7, 3, 12}, 0, 1},
- { {1400, 1050, 101000, 32, 48, 80, 4, 3, 23}, 0, 1},
- { {1680, 1050, 119000, 32, 48, 80, 6, 3, 21}, 0, 1},
- { {1280, 800, 79500, 32, 48, 80, 6, 3, 14}, 0, 1},
- { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1}
+static const struct hdmi_config cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
+{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
+{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
+{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
+{ {1920, 540, 74250, 44, 88, 148, 5, 2, 15, 1, 1, 1}, {5, HDMI_HDMI} },
+{ {1440, 240, 27027, 124, 38, 114, 3, 4, 15, 0, 0, 1}, {6, HDMI_HDMI} },
+{ {1920, 1080, 148500, 44, 88, 148, 5, 4, 36, 1, 1, 0}, {16, HDMI_HDMI} },
+{ {720, 576, 27000, 64, 12, 68, 5, 5, 39, 0, 0, 0}, {17, HDMI_HDMI} },
+{ {1280, 720, 74250, 40, 440, 220, 5, 5, 20, 1, 1, 0}, {19, HDMI_HDMI} },
+{ {1920, 540, 74250, 44, 528, 148, 5, 2, 15, 1, 1, 1}, {20, HDMI_HDMI} },
+{ {1440, 288, 27000, 126, 24, 138, 3, 2, 19, 0, 0, 1}, {21, HDMI_HDMI} },
+{ {1440, 576, 54000, 128, 24, 136, 5, 5, 39, 0, 0, 0}, {29, HDMI_HDMI} },
+{ {1920, 1080, 148500, 44, 528, 148, 5, 4, 36, 1, 1, 0}, {31, HDMI_HDMI} },
+{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
+{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
+{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+/* VESA From Here */
+{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
+{ {800, 600, 4, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
+{ {848, 480, 33750, 112, 16, 112, 8 , 6, 23, 1, 1, 0}, {0xE, HDMI_DVI} },
+{ {1280, 768, 79500, 128, 64, 192, 7 , 3, 20, 1, 0, 0}, {0x17, HDMI_DVI} },
+{ {1280, 800, 83500, 128, 72, 200, 6 , 3, 22, 1, 0, 0}, {0x1C, HDMI_DVI} },
+{ {1360, 768, 85500, 112, 64, 256, 6 , 3, 18, 1, 1, 0}, {0x27, HDMI_DVI} },
+{ {1280, 960, 108000, 112, 96, 312, 3 , 1, 36, 1, 1, 0}, {0x20, HDMI_DVI} },
+{ {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38, 1, 1, 0}, {0x23, HDMI_DVI} },
+{ {1024, 768, 65000, 136, 24, 160, 6, 3, 29, 0, 0, 0}, {0x10, HDMI_DVI} },
+{ {1400, 1050, 121750, 144, 88, 232, 4, 3, 32, 1, 0, 0}, {0x2A, HDMI_DVI} },
+{ {1440, 900, 106500, 152, 80, 232, 6, 3,
Changing IOMMU-API for generic DMA-mapping supported by the hardware
Okay, seperate thread for this one. On Thu, Nov 10, 2011 at 07:28:39PM +, David Woodhouse wrote: The plan is to have a single DMA-API implementation for all IOMMU drivers (X86 and ARM) which just uses the IOMMU-API. But to make this performing reasonalbly well a few changes to the IOMMU-API are required. I already have some ideas which we can discuss if you want. Yeah, that sounds useful. As I said some changes to the IOMMU-API are required in my opinion. These changes should also allow it to move over old-style IOMMUs like Calgary or GART later. The basic idea is that IOMMU drivers should be required to put every device they are responsible for into a default domain. The DMA mapping code can query this default domain for each device. Also the default domain has capabilities that can be queried. Those capabilities include the size and offset of the address space they can re-map. For GART and Calgary this will be the aperture, for VT-d and AMD IOMMU the whole 64bit address space. Another capability is whether addresses outside of that area are 1-1 mapped or no accessible to the device. The generic DMA-mapping code will use that information to initialize its allocator and uses iommu_map/iommu_unmap to create and destroy mappings as requested by the DMA-API (but the DMA-mapping code does not need to create a domain of its own). The good thing about these default domains is that IOMMU drivers can implement their own optimizations on it. The AMD IOMMU driver for example already makes a distinction between dma-mapping domains and other protection-domains. The optimization for dma-mapping domains is that the leaf-pages of the page-table are keept in an array so that it is very easy to find the PTE for an address. Those optimizations are still possible with the default-domain concept. In short, the benefits of the default-domain concept are: 1) It allows existing optimizations for the DMA-mapping code paths to persist 2) It also fits old-style IOMMUs like GART, Calgary and others An open problem is how to report reserved ranges of an address-space. These ranges might exist from a BIOS requirement for 1-1 mapping of certain address ranges (in AMD jargon: Unity mapped ranges, something similar exists on VT-d afaik) or hardware requirements like the reserved address range used for MSI interrupts. Regards, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 01:12:00PM -0800, Stepan Moskovchenko wrote: I have been experimenting with an iommu_map_range call, which maps a given scatterlist of discontiguous physical pages into a contiguous virtual region at a given IOVA. This has some performance advantages over just calling iommu_map iteratively. First, it reduces the amount of table walking / calculation needed for mapping each page, given how you know that all the pages will be mapped into a single virtually-contiguous region (so in most cases, the first-level table calculation can be reused). Second, it allows one to defer the TLB (and sometimes cache) maintenance operations until the entire scatterlist has been mapped, rather than doing a TLB invalidate after mapping each page, as would have been the case if iommu_map were just being called from within a loop. Granted, just using iommu_map many times may be acceptable on the slow path, but I have seen significant performance gains when using this approach on the fast path. Yes, from a performance point-of-view that makes sense, as an addition to the existing iommu_map interface. Are the pages in the list allowed to have different page-sizes? Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Fri, 2011-11-11 at 13:58 +0100, Joerg Roedel wrote: For AMD IOMMU there is a feature called not-present cache. It says that the IOMMU caches non-present entries as well and needs an IOTLB flush when something is mapped (meant for software implementations of the IOMMU). So it can't be really taken out of the fast-path. But the IOMMU driver can optimize the function so that it only flushes the IOTLB when there was an unmap-call before. We have exactly the same situation with the Intel IOMMU (we call it 'Caching Mode') for the same reasons. I'd be wary about making the IOMMU driver *track* whether there was an unmap call before — that seems like hard work and more cache contention, especially if the -commit() call happens on a CPU other than the one that just did the unmap. I'm also not sure exactly when you'd call the -commit() function when the DMA API is being used, and which 'side' of that API the deferred-flush optimisations would live. Would the optimisation be done on the generic side, only calling -commit when it absolutely *has* to happen? (Or periodically after unmaps have happened to avoid entries hanging around for ever?) Or would the optimisation be done in the IOMMU driver, thus turning the -commit() function into more of a *hint*? You could add a 'simon_says' boolean argument to it, I suppose...? It is also an improvement over the current situation where every iommu_unmap call results in a flush implicitly. This pretty much a no-go for using IOMMU-API in DMA mapping at the moment. Right. That definitely needs to be handled. We just need to work out the (above and other) details. But also, it's not *so* much of an issue to divide the space up even when it's limited. The idea was not to have it *strictly* per-CPU, but just for a CPU to try allocating from its own subrange first… Yeah, I get the idea. I fear that the memory consumption will get pretty high with that approach. It basically means one round-robin allocator per cpu and device. What does that mean on a 4096 CPU machine :) Well, if your network device is taking interrupts, and mapping/unmapping buffers across all 4096 CPUs, then your performance is screwed anyway :) Certainly your concerns are valid, but I think we can cope with them fairly reasonably. If we *do* have large number of CPUs allocating for a given domain, we can move to a per-node rather than per-CPU allocator. And we can have dynamically sized allocation regions, so we aren't wasting too much space on unused bitmaps if you map just *one* page from each of your 4096 CPUs. How much lock contention will be lowered also depends on the work-load. If dma-handles are frequently freed from another cpu than they were allocated from the same problem re-appears. The idea is that dma handles are *infrequently* freed, in batches. So we'll bounce the lock's cache line occasionally, but not all the time. In strict or unmap_flush mode, you get to go slowly unless you do the unmap on the same CPU that you mapped it from. I can live with that. But in the end we have to try it out and see what works best :) Indeed. I'm just trying to work out if I should try to do the allocator thing purely inside the Intel code first, and then try to move it out and make it generic — or if I should start with making the DMA API work with a wrapper around the IOMMU API, with your -commit() and other necessary changes. I think I'd prefer the latter, if we can work out how it should look. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Fri, Nov 11, 2011 at 01:27:28PM +, David Woodhouse wrote: On Fri, 2011-11-11 at 13:58 +0100, Joerg Roedel wrote: For AMD IOMMU there is a feature called not-present cache. It says that the IOMMU caches non-present entries as well and needs an IOTLB flush when something is mapped (meant for software implementations of the IOMMU). So it can't be really taken out of the fast-path. But the IOMMU driver can optimize the function so that it only flushes the IOTLB when there was an unmap-call before. We have exactly the same situation with the Intel IOMMU (we call it 'Caching Mode') for the same reasons. I'd be wary about making the IOMMU driver *track* whether there was an unmap call before — that seems like hard work and more cache contention, especially if the -commit() call happens on a CPU other than the one that just did the unmap. Well, the IOMMU driver does not need to track this globally or per-IOMMU. It basically tracks it per-domain. This lowers the cache-bouncing a bit. I'm also not sure exactly when you'd call the -commit() function when the DMA API is being used, and which 'side' of that API the deferred-flush optimisations would live. The commit function is called every time before one of the DMA-API functions return. Would the optimisation be done on the generic side, only calling -commit when it absolutely *has* to happen? (Or periodically after unmaps have happened to avoid entries hanging around for ever?) Or would the optimisation be done in the IOMMU driver, thus turning the -commit() function into more of a *hint*? You could add a 'simon_says' boolean argument to it, I suppose...? The IOMMU driver can't do that because special knowledge about the address allocator is needed. So it has to happen in the generic part. Okay, that optimization does not really work with the -commit() idea, as I think about it. With the requirement to call commit() on the map-side would result in too many flushes to happen. So it may be better to just call it iommu_flush_tlb(domain) or something. The user of the IOMMU-API can assume that the flush is only necessary on the unmap-path. Stricter flushing rules need to be handled in the IOMMU driver itself. It is also an improvement over the current situation where every iommu_unmap call results in a flush implicitly. This pretty much a no-go for using IOMMU-API in DMA mapping at the moment. Right. That definitely needs to be handled. We just need to work out the (above and other) details. Yes, I am convinced now that the commit() idea is not the right solution :) Some less generic semantics like a iommu_flush_tlb call-back would do better with such an optimization. Certainly your concerns are valid, but I think we can cope with them fairly reasonably. If we *do* have large number of CPUs allocating for a given domain, we can move to a per-node rather than per-CPU allocator. And we can have dynamically sized allocation regions, so we aren't wasting too much space on unused bitmaps if you map just *one* page from each of your 4096 CPUs. It also requires somewhat that the chunks are reasonably small. On a typical small system the amount of allocated DMA memory is rather small (GPUs are the exception, of course). Btw, do you have numbers how much time is spent in spinlocks for multi-node machines and the VT-d driver for some workloads? I remember that I did this measurement some time ago on a 24 core AMD machine with netperf on a 10GBit network card and the time spent spinning came out at ~5%. For 1Gbit network and disk-load it was around 0.5% on that machine. How much lock contention will be lowered also depends on the work-load. If dma-handles are frequently freed from another cpu than they were allocated from the same problem re-appears. The idea is that dma handles are *infrequently* freed, in batches. So we'll bounce the lock's cache line occasionally, but not all the time. Hmm, btw, how does this batch-freeing works? Is the freeing done when the address space is filled up or is another approach used? But in the end we have to try it out and see what works best :) Indeed. I'm just trying to work out if I should try to do the allocator thing purely inside the Intel code first, and then try to move it out and make it generic — or if I should start with making the DMA API work with a wrapper around the IOMMU API, with your -commit() and other necessary changes. I think I'd prefer the latter, if we can work out how it should look. I think it is the best to start with a generic DMA-mapping implementation, benchmark it and then find the bottlenecks and try out possible optimizations. In the beginning it is hard enough to come up with an implementation that fits X86 and ARM at the same time. When this is worked out we can continue to optimize :) Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers:
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On 11/11/2011 12:47 PM, Jamie Iles wrote: On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote: [Adding Benoit to CC]. On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote: On Wed, 9 Nov 2011, Ming Lei wrote: Also, current arm perf code don't handle three IRQs(one pl310 irq and two CTI irq) inside one device correctly. To fix this, that ARM perf code should either be using platform_get_irq_byname(), or the hwmod hardware data will need to be rearranged to meet the arbitrary ordering requirement. I'd suggest pinging Will on this issue to see what he wants to do. The issue stems from the fact that we have to route the PMU interrupts to the correct CPU manually (I think only MSM routes them as PPIs, which is clearly the correct thing to do). To do this, we expect the IRQ resources to be laid out in CPU order. In hindsight, maybe naming the resources might have been a good idea, but them we'd still have to generate the names using CPU numbers when iterating through the platform device. There isn't yet a way to do naming of resources with DT, and although I think there was a proposal for doing named register resources I don't think this has been accepted and there wasn't anything for IRQ resources... It will come soon... along with the updated patch for reg-names support. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Benoit, On Fri, Nov 11, 2011 at 02:56:05PM +, Cousson, Benoit wrote: It will come soon... along with the updated patch for reg-names support. Actually, I was hoping you could help Ming Lei with the hwmod stuff :) Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Will,
On 11/11/2011 3:58 PM, Will Deacon wrote:
Hi Benoit,
On Fri, Nov 11, 2011 at 02:56:05PM +, Cousson, Benoit wrote:
It will come soon... along with the updated patch for reg-names support.
Actually, I was hoping you could help Ming Lei with the hwmod stuff :)
And I'll do :-)
We already started looking at that with Paul a couple of days ago, but
the organization of the debugss IPs inside MPUSS is a little bit messy
in OMAP :-)
For the moment the cti IRQs are attached to the MPU subsystem which make
sense for the HW partitioning point of view.
Unfortunately, these debug IPs are accessed through an external L3_EMU
configuration bus and not using some internal bus inside the MPUSS.
In the memory maps they are thus all located inside the
0x5400-0x54164FFF.
So for the driver point of view, it might be better to assign these IRQs
to the debugss IP instead of the MPUSS IP.
The MPU will then only have the PL310 IRQ.
static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
{ .name = pl310, .irq = 0 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
The debugss one will have the cti ones, that will start at 0 and thus
will make them even accessible using the index.
static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
{ .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
{ .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
I need to fix this IRQ mapping and then I'll be able to send a hwmod
version of this debugss virtual IP that should help Ming.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Fri, Nov 11, 2011 at 03:12:49PM +, Cousson, Benoit wrote:
Hi Will,
Hello,
On 11/11/2011 3:58 PM, Will Deacon wrote:
Actually, I was hoping you could help Ming Lei with the hwmod stuff :)
And I'll do :-)
Cheers!
We already started looking at that with Paul a couple of days ago, but
the organization of the debugss IPs inside MPUSS is a little bit messy
in OMAP :-)
Ok, I'm not familiar with it so that's why I've been pestering.
For the moment the cti IRQs are attached to the MPU subsystem which make
sense for the HW partitioning point of view.
Unfortunately, these debug IPs are accessed through an external L3_EMU
configuration bus and not using some internal bus inside the MPUSS.
In the memory maps they are thus all located inside the
0x5400-0x54164FFF.
So for the driver point of view, it might be better to assign these IRQs
to the debugss IP instead of the MPUSS IP.
The MPU will then only have the PL310 IRQ.
static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
{ .name = pl310, .irq = 0 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
At some point I'd like to add support for the PL310 PMU, which will want to
use that IRQ. That would need to be passed to the PL310 driver though, which
will then register it's own PMU device with perf.
The debugss one will have the cti ones, that will start at 0 and thus
will make them even accessible using the index.
static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
{ .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
{ .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
I need to fix this IRQ mapping and then I'll be able to send a hwmod
version of this debugss virtual IP that should help Ming.
That looks cracking and should work out of the box.
Thanks,
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Introduce local common.h files
On Thu, Nov 10, 2011 at 03:33:47PM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [10 13:54]: Thanks, merged that into the series. The updated OMAP patch updated is below, which has been moved to part 2. Lastly, the final patch of part 2 has been updated to delete the empty arch_reset(), so OMAP is now entirely free of arch_reset() references. This leaves a total of 12 references left to nobble. Great, good to hear. I've added this to the patch, as these no longer need to include this header. diff --git a/arch/arm/mach-omap1/board-voiceblue.c b/arch/arm/mach-omap1/board-voiceblue.c index fb61434..f83a502d 100644 --- a/arch/arm/mach-omap1/board-voiceblue.c +++ b/arch/arm/mach-omap1/board-voiceblue.c @@ -28,7 +28,6 @@ #include linux/export.h #include mach/hardware.h -#include mach/system.h #include asm/mach-types.h #include asm/mach/arch.h #include asm/mach/map.h diff --git a/arch/arm/mach-omap1/reset.c b/arch/arm/mach-omap1/reset.c index 8b1cc6e..91d199b 100644 --- a/arch/arm/mach-omap1/reset.c +++ b/arch/arm/mach-omap1/reset.c @@ -5,7 +5,6 @@ #include linux/io.h #include mach/hardware.h -#include mach/system.h #include plat/prcm.h void omap1_restart(char mode, const char *cmd) diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index b6c8cb5..626acfa 100644 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -25,7 +25,6 @@ #include linux/delay.h #include linux/export.h -#include mach/system.h #include common.h #include plat/prcm.h #include plat/irqs.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Introduce local common.h files
* Russell King - ARM Linux li...@arm.linux.org.uk [11 07:42]: On Thu, Nov 10, 2011 at 03:33:47PM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [10 13:54]: Thanks, merged that into the series. The updated OMAP patch updated is below, which has been moved to part 2. Lastly, the final patch of part 2 has been updated to delete the empty arch_reset(), so OMAP is now entirely free of arch_reset() references. This leaves a total of 12 references left to nobble. Great, good to hear. I've added this to the patch, as these no longer need to include this header. OK thanks. Tony diff --git a/arch/arm/mach-omap1/board-voiceblue.c b/arch/arm/mach-omap1/board-voiceblue.c index fb61434..f83a502d 100644 --- a/arch/arm/mach-omap1/board-voiceblue.c +++ b/arch/arm/mach-omap1/board-voiceblue.c @@ -28,7 +28,6 @@ #include linux/export.h #include mach/hardware.h -#include mach/system.h #include asm/mach-types.h #include asm/mach/arch.h #include asm/mach/map.h diff --git a/arch/arm/mach-omap1/reset.c b/arch/arm/mach-omap1/reset.c index 8b1cc6e..91d199b 100644 --- a/arch/arm/mach-omap1/reset.c +++ b/arch/arm/mach-omap1/reset.c @@ -5,7 +5,6 @@ #include linux/io.h #include mach/hardware.h -#include mach/system.h #include plat/prcm.h void omap1_restart(char mode, const char *cmd) diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index b6c8cb5..626acfa 100644 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -25,7 +25,6 @@ #include linux/delay.h #include linux/export.h -#include mach/system.h #include common.h #include plat/prcm.h #include plat/irqs.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] OMAPDSS: HDMI: Move duplicate code from boardfile to
* mythr...@ti.com mythr...@ti.com [11 04:41]:
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
arch/arm/mach-omap2/display.c | 23 +++
include/video/omapdss.h|2 ++
4 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73b1e99..4a519a3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -595,20 +595,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static void sdp4430_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
@@ -838,9 +824,9 @@ static void omap_4430sdp_display_init(void)
pr_err(%s: Could not get display_sel GPIO\n, __func__);
sdp4430_lcd_init();
- sdp4430_hdmi_mux_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
+ omap_hdmi_enable_pads();
}
Good to see some removal of the code here :) Maybe call the fuction
omap_hdmi_init() instead? That way you can make it more generic and
pass it some options.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] OMAPDSS: HDMI: Disable HDMI DDC internal pull up
* mythr...@ti.com mythr...@ti.com [11 04:41]: From: Mythri P K mythr...@ti.com Disables the internal pull resistor for SDA and SCL enabled by default as there are expernal pull up's in 4460 and 4430 ES2.3, It is done to avoid the EDID read failure. Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org Signed-off-by: Mythri P K mythr...@ti.com --- arch/arm/mach-omap2/board-4430sdp.c| 12 +++- arch/arm/mach-omap2/board-omap4panda.c | 13 - arch/arm/mach-omap2/display.c | 17 ++--- include/video/omapdss.h|2 +- 4 files changed, 38 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 4a519a3..91d3742 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -826,7 +826,17 @@ static void omap_4430sdp_display_init(void) sdp4430_lcd_init(); sdp4430_picodlp_init(); omap_display_init(sdp4430_dss_data); - omap_hdmi_enable_pads(); + /* + * CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and + * HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable + * internal pull up resistor - This is a change needed in + * OMAP4460 and OMAP4430 ES2.3 as the external pull up + * are present. This is needed to avoid EDID read failure. + */ + if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2)) + omap_hdmi_enable_pads(1); + else + omap_hdmi_enable_pads(0); } If you now have omap_hdmi_init(), then you can just pass it board specific flags like OMAP_HDMI_EXTERNAL_PULL. The generic init function will make it easier to move things over to DT also. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Fix reprogramming of dpll1 rate
Commit a66cb3454f220f49f900646ebdc76cb943319eb7 (ARM: OMAP: Map SRAM
later on with ioremap_exec()) moved the SRAM init to happen later
to remove a dependency to early SoC detection for map_io.
This broke booting on some boards not using Kconfig option for
OMAP_CLOCKS_SET_BY_BOOTLOADER as the dpll1 reprogramming would
cause the following error:
kernel BUG at arch/arm/plat-omap/sram.c:226!
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
Modules linked in:
CPU: 0Not tainted (3.2.0-rc1-e3 #9)
PC is at omap_sram_reprogram_clock+0x28/0x30
LR is at omap1_select_table_rate+0x88/0xb4
pc : [c001b0c4]lr : [c0019f54]psr: 60d3
sp : c035bf10 ip : c035bf20 fp : c035bf1c
r10: c035bfd4 r9 : 54029252 r8 : c03f8120
r7 : c0362b50 r6 : 00b71b00 r5 : c03873cc r4 : c0362b40
r3 : r2 : c0362b40 r1 : 010a r0 : 2cb0
Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 317f Table: 10004000 DAC: 0017
Process swapper (pid: 0, stack limit = 0xc035a270)
Stack: (0xc035bf10 to 0xc035c000)
bf00: c035bf3c c035bf20 c0019f54 c001b0ac
bf20: 1000 2cb3 0004 c035ed4c c035bf74 c035bf40 c033ea24 c0019edc
bf40: c02f526c 0002 0015 bc058c9b 93111a16 c035335c 0200 c035ed4c
bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec c035bfc4 c035bf88
bf80: c033bc24 c00194a0 c035bf90 c035bf98
bfa0: 0001 c0354678 c035ece4 10004000 103532f4 c035bff4 c035bfc8
bfc0: c0338574 c033b598 c035467c 317d c035c03c
bfe0: c0354678 c035ece4 c035bff8 10008040 c0338508
Backtrace:
[c001b09c] (omap_sram_reprogram_clock+0x0/0x30) from [c0019f54]
(omap1_select_table_rate+0x88/0xb4)
[c0019ecc] (omap1_select_table_rate+0x0/0xb4) from [c033ea24]
(omap1_clk_init+0x148/0x334)
r7:c035ed4c r6:0004 r5:2cb3 r4:1000
[c033e8dc] (omap1_clk_init+0x0/0x334) from [c00194c4]
(omap1_init_early+0x34/0x48)
r8:c03f8120 r7:c035ed4c r6:c035ed4c r5:0200 r4:c035335c
[c0019490] (omap1_init_early+0x0/0x48) from [c033bc24]
(setup_arch+0x69c/0x79c)
[c033b588] (setup_arch+0x0/0x79c) from [c0338574] (start_kernel+0x7c/0x2f4)
[c03384f8] (start_kernel+0x0/0x2f4) from [10008040] (0x10008040)
r7:c035ece4 r6:c0354678 r5:c035c03c r4:317d
Code: 0a02 e1a0e00f e12fff13 e89da800 (e7f001f2)
Fix this by adding omap1_clk_late_init() that only reprograms dpll1
if the bootloader rate is less than 60MHz. This also allows removing
of the OMAP_CLOCKS_SET_BY_BOOTLOADER option.
Reported-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Tony Lindgren t...@atomide.com
---
This seems to work when forced on OSK5912 at least. Moving the dpll1
reprogramming to happen later should not mess up drivers as it's still
before driver inits. Also the system timer should not change as the
source is ck_ref.
---
diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index 7b63462..a7e7775 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -48,7 +48,6 @@ CONFIG_MACH_SX1=y
CONFIG_MACH_NOKIA770=y
CONFIG_MACH_AMS_DELTA=y
CONFIG_MACH_OMAP_GENERIC=y
-CONFIG_OMAP_CLOCKS_SET_BY_BOOTLOADER=y
CONFIG_OMAP_ARM_216MHZ=y
CONFIG_OMAP_ARM_195MHZ=y
CONFIG_OMAP_ARM_192MHZ=y
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index e0a0281..73f287d 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -171,14 +171,6 @@ config MACH_OMAP_GENERIC
comment OMAP CPU Speed
depends on ARCH_OMAP1
-config OMAP_CLOCKS_SET_BY_BOOTLOADER
- bool OMAP clocks set by bootloader
- depends on ARCH_OMAP1
- help
- Enable this option to prevent the kernel from overriding the clock
- frequencies programmed by bootloader for MPU, DSP, MMUs, TC,
- internal LCD controller and MPU peripherals.
-
config OMAP_ARM_216MHZ
bool OMAP ARM 216 MHz CPU (1710 only)
depends on ARCH_OMAP1 ARCH_OMAP16XX
diff --git a/arch/arm/mach-omap1/clock.h b/arch/arm/mach-omap1/clock.h
index eaf09ef..16b1423 100644
--- a/arch/arm/mach-omap1/clock.h
+++ b/arch/arm/mach-omap1/clock.h
@@ -17,7 +17,8 @@
#include plat/clock.h
-extern int __init omap1_clk_init(void);
+int omap1_clk_init(void);
+void omap1_clk_late_init(void);
extern int omap1_clk_enable(struct clk *clk);
extern void omap1_clk_disable(struct clk *clk);
extern long omap1_clk_round_rate(struct clk *clk, unsigned long rate);
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 92400b9..1297bb5 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -767,6 +767,15 @@ static struct clk_functions omap1_clk_functions = {
.clk_disable_unused = omap1_clk_disable_unused,
};
+static void __init omap1_show_rates(void)
+{
+ pr_notice(Clocking rate (xtal/DPLL1/MPU):
+
Re: [PATCH] ARM: OMAP: Fix reprogramming of dpll1 rate
Hi, On 11.11.2011, at 21.16, Tony Lindgren wrote: Commit a66cb3454f220f49f900646ebdc76cb943319eb7 (ARM: OMAP: Map SRAM later on with ioremap_exec()) moved the SRAM init to happen later to remove a dependency to early SoC detection for map_io. This broke booting on some boards not using Kconfig option for OMAP_CLOCKS_SET_BY_BOOTLOADER as the dpll1 reprogramming would cause the following error: kernel BUG at arch/arm/plat-omap/sram.c:226! Internal error: Oops - undefined instruction: 0 [#1] PREEMPT Modules linked in: CPU: 0Not tainted (3.2.0-rc1-e3 #9) PC is at omap_sram_reprogram_clock+0x28/0x30 LR is at omap1_select_table_rate+0x88/0xb4 pc : [c001b0c4]lr : [c0019f54]psr: 60d3 sp : c035bf10 ip : c035bf20 fp : c035bf1c r10: c035bfd4 r9 : 54029252 r8 : c03f8120 r7 : c0362b50 r6 : 00b71b00 r5 : c03873cc r4 : c0362b40 r3 : r2 : c0362b40 r1 : 010a r0 : 2cb0 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 317f Table: 10004000 DAC: 0017 Process swapper (pid: 0, stack limit = 0xc035a270) Stack: (0xc035bf10 to 0xc035c000) bf00: c035bf3c c035bf20 c0019f54 c001b0ac bf20: 1000 2cb3 0004 c035ed4c c035bf74 c035bf40 c033ea24 c0019edc bf40: c02f526c 0002 0015 bc058c9b 93111a16 c035335c 0200 c035ed4c bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec c035bfc4 c035bf88 bf80: c033bc24 c00194a0 c035bf90 c035bf98 bfa0: 0001 c0354678 c035ece4 10004000 103532f4 c035bff4 c035bfc8 bfc0: c0338574 c033b598 c035467c 317d c035c03c bfe0: c0354678 c035ece4 c035bff8 10008040 c0338508 Backtrace: [c001b09c] (omap_sram_reprogram_clock+0x0/0x30) from [c0019f54] (omap1_select_table_rate+0x88/0xb4) [c0019ecc] (omap1_select_table_rate+0x0/0xb4) from [c033ea24] (omap1_clk_init+0x148/0x334) r7:c035ed4c r6:0004 r5:2cb3 r4:1000 [c033e8dc] (omap1_clk_init+0x0/0x334) from [c00194c4] (omap1_init_early+0x34/0x48) r8:c03f8120 r7:c035ed4c r6:c035ed4c r5:0200 r4:c035335c [c0019490] (omap1_init_early+0x0/0x48) from [c033bc24] (setup_arch+0x69c/0x79c) [c033b588] (setup_arch+0x0/0x79c) from [c0338574] (start_kernel +0x7c/0x2f4) [c03384f8] (start_kernel+0x0/0x2f4) from [10008040] (0x10008040) r7:c035ece4 r6:c0354678 r5:c035c03c r4:317d Code: 0a02 e1a0e00f e12fff13 e89da800 (e7f001f2) Fix this by adding omap1_clk_late_init() that only reprograms dpll1 if the bootloader rate is less than 60MHz. This also allows removing of the OMAP_CLOCKS_SET_BY_BOOTLOADER option. Reported-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Tony Lindgren t...@atomide.com --- This seems to work when forced on OSK5912 at least. Moving the dpll1 reprogramming to happen later should not mess up drivers as it's still before driver inits. Also the system timer should not change as the source is ck_ref. Cheers mate, this fixes the 3.2-rc1 boot issue on Amstrad E3. Tested-by: Aaro Koskinen aaro.koski...@iki.fi A. --- diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/ omap1_defconfig index 7b63462..a7e7775 100644 --- a/arch/arm/configs/omap1_defconfig +++ b/arch/arm/configs/omap1_defconfig @@ -48,7 +48,6 @@ CONFIG_MACH_SX1=y CONFIG_MACH_NOKIA770=y CONFIG_MACH_AMS_DELTA=y CONFIG_MACH_OMAP_GENERIC=y -CONFIG_OMAP_CLOCKS_SET_BY_BOOTLOADER=y CONFIG_OMAP_ARM_216MHZ=y CONFIG_OMAP_ARM_195MHZ=y CONFIG_OMAP_ARM_192MHZ=y diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index e0a0281..73f287d 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -171,14 +171,6 @@ config MACH_OMAP_GENERIC comment OMAP CPU Speed depends on ARCH_OMAP1 -config OMAP_CLOCKS_SET_BY_BOOTLOADER - bool OMAP clocks set by bootloader - depends on ARCH_OMAP1 - help - Enable this option to prevent the kernel from overriding the clock - frequencies programmed by bootloader for MPU, DSP, MMUs, TC, - internal LCD controller and MPU peripherals. - config OMAP_ARM_216MHZ bool OMAP ARM 216 MHz CPU (1710 only) depends on ARCH_OMAP1 ARCH_OMAP16XX diff --git a/arch/arm/mach-omap1/clock.h b/arch/arm/mach-omap1/clock.h index eaf09ef..16b1423 100644 --- a/arch/arm/mach-omap1/clock.h +++ b/arch/arm/mach-omap1/clock.h @@ -17,7 +17,8 @@ #include plat/clock.h -extern int __init omap1_clk_init(void); +int omap1_clk_init(void); +void omap1_clk_late_init(void); extern int omap1_clk_enable(struct clk *clk); extern void omap1_clk_disable(struct clk *clk); extern long omap1_clk_round_rate(struct clk *clk, unsigned long rate); diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/ clock_data.c index 92400b9..1297bb5 100644 --- a/arch/arm/mach-omap1/clock_data.c +++ b/arch/arm/mach-omap1/clock_data.c @@ -767,6 +767,15 @@ static struct clk_functions
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On 11/11/2011 5:24 AM, Joerg Roedel wrote: On Thu, Nov 10, 2011 at 01:12:00PM -0800, Stepan Moskovchenko wrote: I have been experimenting with an iommu_map_range call, which maps a given scatterlist of discontiguous physical pages into a contiguous virtual region at a given IOVA. This has some performance advantages over just calling iommu_map iteratively. First, it reduces the amount of table walking / calculation needed for mapping each page, given how you know that all the pages will be mapped into a single virtually-contiguous region (so in most cases, the first-level table calculation can be reused). Second, it allows one to defer the TLB (and sometimes cache) maintenance operations until the entire scatterlist has been mapped, rather than doing a TLB invalidate after mapping each page, as would have been the case if iommu_map were just being called from within a loop. Granted, just using iommu_map many times may be acceptable on the slow path, but I have seen significant performance gains when using this approach on the fast path. Yes, from a performance point-of-view that makes sense, as an addition to the existing iommu_map interface. Are the pages in the list allowed to have different page-sizes? Joerg Hello Yes, the scatterlist is allowed to have different page sizes. But, they are required to have a length that is a multiple of 4K. If a page in the list is bigger than 4K, the code will iteratively map it with 4K pages. I suppose based on how my implementation is written, it would not be too difficult to add checks for the proper length and VA/PA alignments, and insert a 64K / 1M / 16M mapping if the alignment is lucky and the SG item is big enough. In my particular test case, even though the pages in the list might be of different sizes, they are not guaranteed to be aligned properly and I would most likely have to fall back on mapping them as multiple consecutive 4K pages, anyway. But even despite this, having map_range to consolidate a lot of the common operations into one call sill gives me a nice speed boost. I hadn't sent the patches out because this was all for my testing, but would you be interested in me adding a map_range to the API? The iommu_map_range call could even do a check if the ops supports a .map_range, and fall back on calling iommu_map repeatedly if the driver doesn't support this operation natively. In my code, the function takes a domain, iova, scatterlist, length, and prot. Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
