Re: [OMAP3] ALSA driver 'suspend/resume' handlers
On Wed, 23 Sep 2009 00:02:01 -0500 hari n hari.z...@gmail.com wrote: It appears OMAP ALSA driver does not seem to disable and idle the SDMA channel on a 'suspend' call. The problem seems to be with the 'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in 'omap_pcm_trigger()'. ALSA audio driver uses self linking and the function 'omap_stop_dma()', only unlinks the channels, but DOES NOT disable an active channel for linked channels. Good finding, definitely I was expecting that it will stop the transfer. I worder what's the background for current omap_stop_dma implementation? I would expect that omap_stop_dma would just stop the logical channel without touching the channel linking etc. as there is own API for chained transfers and thus omap_stop_dma could be used for non-chained transfers or 'hacking' with chained transfers. This means after a return from the 'omap_stop_dma()', there can still be an active DMA transaction on the channel. Is this the intent Or a bug? I can think of situations, where in, we may want to complete the DMA transfer and then disable the channel. In such a case, we need to wait until the channel is inactive. I don't know, probably there is no driver expecting that transfer will complete after the omap_stop_dma is called or they explicitly do some PIO based FIFO flush for their devices? The problem with the current implementation is that after the audio platform trigger (suspend) is called, SOC core calls the CPU DAI trigger (suspend) and this stops the McBSP. Depending on the current DMA pointer, this may leave the DMA channel in active state, since DMA is configured for DEST HW Synchronization and and the this never gets asserted after the McBSP is stopped.. This is true. Then the question is will the operation recover after the stream is resumed and after the low-level dma and mcbsp contexts are restored and operation started again. I see two ways to resolve this issue: a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend) until the DMA channel is inactive (i.e buffer transfer complete). But, i believe 'trigger' is supposed to be an atomic operation, so we may need to wait in a worker thread. And we need to flag the McBSP stop based on DMA transfer completion. b) Explicitly disable the DMA channel in 'omap_stop_dma(). Option 'b' above may mean losing some data on resume, if we hit 'OFF' state during suspend. This may not be a big deal for audio (loss of few secs audio), but for other drivers (ex: USB data file transfer?), this may not be acceptable. 'Option 'a' means more rework in audio driver, but no changes in DAM driver and no loss of data. Yeah, trigger callback is atomic and can be called from the interrupt context as well. Option 'a' doesn't help losing of audio samples since the soc-core is first muting the codec. Current Audio driver also does not seem to support 'OFF' mode during suspend. It seems to assume that all DMA and McBSP configurations are retained in a suspend to resume transition. It's true, this has not got so much attention. I think I was expecting that low-level mcbsp and dma modules will take care of their context back-up and restore and that's enough for audio as long as audio will inform those modules with _start/_stop calls. I don't see any problem if suspend and resume callbacks are added into omap-pcm.c and omap-mcbsp.c calling e.g. omap_mcbsp_config if needed. -- Jarkko -- 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
OSS emulation broken
Hi I tried playing a .mp3 file using madplay utility in ASoC-OSS emulation. But it didn't work properly. I am able to hear something but the configuration seems incorrect. Has anyone tried the OSS emulation layer in ASoC? I am at 382af94eb4 (Revert omap850: Use ck_ref clock for omap850.). Regards, Anuj Aggarwal -- 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 1/3] OMAP UART: Adding support for omap-serial driver.
On Tue, Sep 22, 2009 at 11:33 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [090922 10:06]: From: Govindraj R govindraj.r...@ti.com This patch adds support for OMAP3430-HIGH SPEED UART Controller. Why do you have the same subject anad description is the same for all of them? --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1359,6 +1359,98 @@ config SERIAL_OF_PLATFORM Currently, only 8250 compatible ports are supported, but others can easily be added. +config SERIAL_OMAP + bool OMAP serial port support + depends on ARM ARCH_OMAP + select SERIAL_CORE + help + If you have a machine based on an Texas Instruments OMAP CPU you + can enable its onboard serial ports by enabling this option. + +config SERIAL_OMAP_CONSOLE + bool Console on OMAP serial port + depends on SERIAL_OMAP + select SERIAL_CORE_CONSOLE + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can make it the console by answering Y to this option. + + Even if you say Y here, the currently visible virtual console + (/dev/tty0) will still be used as the system console by default, but + you can alter that using a kernel command line option such as + console=ttyS0. (Try man bootparam or see the documentation of + your boot loader (lilo or loadlin) about how to pass options to the + kernel at boot time.) + +config SERIAL_OMAP_DMA_UART1 + bool UART1 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 1 by answering + to this option. + Didn't I already comment these options should be passed in platform_data from board-*.c files? Will resend PATCH v1 incorporating SERIAL_OMAP_UARTx_RXDMA_BUFSIZE and SERIAL_OMAP_UARTx_RXDMA_BUFSIZE values into platform data and will clean up in Kconfig. Thanks for your review comments. --- Regards, Govindraj.R -- 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: [OMAP3] ALSA driver 'suspend/resume' handlers
Hari/Jarkko, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Thursday, September 24, 2009 12:16 PM To: hari n Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [OMAP3] ALSA driver 'suspend/resume' handlers On Wed, 23 Sep 2009 00:02:01 -0500 hari n hari.z...@gmail.com wrote: It appears OMAP ALSA driver does not seem to disable and idle the SDMA channel on a 'suspend' call. The problem seems to be with the 'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in 'omap_pcm_trigger()'. ALSA audio driver uses self linking and the function 'omap_stop_dma()', only unlinks the channels, but DOES NOT disable an active channel for linked channels. Good finding, definitely I was expecting that it will stop the transfer. I worder what's the background for current omap_stop_dma implementation? I would expect that omap_stop_dma would just stop the logical channel without touching the channel linking etc. as there is own API for chained transfers and thus omap_stop_dma could be used for non-chained transfers or 'hacking' with chained transfers. This means after a return from the 'omap_stop_dma()', there can still be an active DMA transaction on the channel. Is this the intent Or a bug? I can think of situations, where in, we may want to complete the DMA transfer and then disable the channel. In such a case, we need to wait until the channel is inactive. I don't know, probably there is no driver expecting that transfer will complete after the omap_stop_dma is called or they explicitly do some PIO based FIFO flush for their devices? The problem with the current implementation is that after the audio platform trigger (suspend) is called, SOC core calls the CPU DAI trigger (suspend) and this stops the McBSP. Depending on the current DMA pointer, this may leave the DMA channel in active state, since DMA is configured for DEST HW Synchronization and and the this never gets asserted after the McBSP is stopped.. This is true. Then the question is will the operation recover after the stream is resumed and after the low-level dma and mcbsp contexts are restored and operation started again. I see two ways to resolve this issue: a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend) until the DMA channel is inactive (i.e buffer transfer complete). But, i believe 'trigger' is supposed to be an atomic operation, so we may need to wait in a worker thread. And we need to flag the McBSP stop based on DMA transfer completion. b) Explicitly disable the DMA channel in 'omap_stop_dma(). Option 'b' above may mean losing some data on resume, if we hit 'OFF' state during suspend. This may not be a big deal for audio (loss of few secs audio), but for other drivers (ex: USB data file transfer?), this may not be acceptable. 'Option 'a' means more rework in audio driver, but no changes in DAM driver and no loss of data. Yeah, trigger callback is atomic and can be called from the interrupt context as well. Option 'a' doesn't help losing of audio samples since the soc-core is first muting the codec. Current Audio driver also does not seem to support 'OFF' mode during suspend. It seems to assume that all DMA and McBSP configurations are retained in a suspend to resume transition. It's true, this has not got so much attention. I think I was expecting that low-level mcbsp and dma modules will take care of their context back-up and restore and that's enough for audio as long as audio will inform those modules with _start/_stop calls. I don't see any problem if suspend and resume callbacks are added into omap-pcm.c and omap-mcbsp.c calling e.g. omap_mcbsp_config if needed. omap_stop_dma() should be issued when we really want to stop the DMA transfer and issuing this with an outstanding transfer is a BUG in ALSA driver. Having said that, there is also bug in the DMA driver which doesn't disable the channel in linking cases. Since we use always hardware synchronized method, hardware will take care of draining the buffer so no loss of data. So option B should be ok and USB case also would work as mentioned above. Regrads Santosh -- 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
[PATCHv1 1/3] OMAP UART: Adds omap-serial driver support.
From: Govindraj R govindraj.r...@ti.com
This patch adds support for OMAP3430-HIGH SPEED UART Controller.
Signed-off-by: Govindraj R govindraj.r...@ti.com
Reviewed-by: Alan Cox a...@lxorguk.ukuu.org.uk
Reviewed-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/include/mach/omap-serial.h | 156 ++
drivers/serial/Kconfig| 47
drivers/serial/Makefile |1
drivers/serial/omap-serial.c | 1745 ++
4 files changed, 1949 insertions(+)
diff --git a/arch/arm/plat-omap/include/mach/omap-serial.h
b/arch/arm/plat-omap/include/mach/omap-serial.h
new file mode 100644
index 000..17b6d17
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/omap-serial.h
@@ -0,0 +1,156 @@
+/*
+ * arch/arm/plat-omap/include/mach/omap-serial.h
+ *
+ * Driver for OMAP3430 UART controller.
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * Authors:
+ * Govindraj R govindraj.r...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include linux/serial_core.h
+#include linux/platform_device.h
+
+#ifdef CONFIG_PM
+#include ../arch/arm/mach-omap2/prm.h
+#include ../arch/arm/mach-omap2/pm.h
+#include ../arch/arm/mach-omap2/prm-regbits-34xx.h
+#include mach/control.h
+#endif
+
+/* TI OMAP CONSOLE */
+#define PORT_OMAP 86
+#define DRIVER_NAMEomap-hsuart
+
+/* tty device name used by omap-serial driver,
+ * in bootargs we specify as console=ttyO0 if uart1
+ * is used as console uart.
+ */
+#define DEVICE_NAMEttyO
+
+/*
+ * We default to IRQ0 for the no irq hack. Some
+ * machine types want others as well - they're free
+ * to redefine this in their header file.
+ */
+#define is_real_interrupt(irq) ((irq) != 0)
+
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE) defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#ifdef CONFIG_ARCH_OMAP34XX
+#define OMAP_MDR1_DISABLE 0x07
+#define OMAP_MDR1_MODE13X 0x03
+#define OMAP_MDR1_MODE16X 0x00
+#define OMAP_MODE13X_SPEED 230400
+#endif
+
+#define CONSOLE_NAME console=
+
+#define UART_CLK (4800)
+#define QUART_CLK (1843200)
+
+#define QUART (0x3)
+
+#define SLEEP_TIMEOUT (5 * HZ)
+#define RX_TIMEOUT (3 * HZ)
+
+struct uart_dma_info {
+ int dma_enabled;
+ int rx_dma_bufsize;
+ int rx_timeout;
+ };
+
+struct omap_uart_state {
+ int clocked;
+ struct clk *ick;
+ struct clk *fck;
+ int num;
+ int can_sleep;
+
+ void __iomem *wk_st;
+ void __iomem *wk_en;
+ u32 wk_mask;
+ u32 padconf;
+
+#ifdef CONFIG_PM
+ struct timer_list timer;
+ u32 timeout;
+ int context_valid;
+ /* Registers to be saved/restored for OFF-mode */
+ u16 dll;
+ u16 dlh;
+ u16 ier;
+ u16 sysc;
+ u16 scr;
+ u16 wer;
+#endif
+};
+
+struct uart_omap_dma {
+ u8 uart_dma_tx;
+ u8 uart_dma_rx;
+ int rx_dma_channel;
+ int tx_dma_channel;
+ /* Physical adress of RX DMA buffer */
+ dma_addr_t rx_buf_dma_phys;
+ /* Physical adress of TX DMA buffer */
+ dma_addr_t tx_buf_dma_phys;
+ /*
+* Buffer for rx dma.It is not required for tx because the buffer
+* comes from port structure
+*/
+ unsigned intuart_base;
+ unsigned char *rx_buf;
+ unsigned intprev_rx_dma_pos;
+ int tx_buf_size;
+ int tx_dma_state;
+ int rx_dma_state;
+ spinlock_t tx_lock;
+ spinlock_t rx_lock;
+ /* timer to poll activity on rx dma */
+ struct timer_list rx_timer;
+ int rx_buf_size;
+ int rx_timeout;
+};
+
+struct uart_omap_port {
+ struct uart_portport;
+ struct uart_omap_dmauart_dma;
+ struct platform_device *pdev;
+
+ unsigned char ier;
+ unsigned char lcr;
+ unsigned char mcr;
+ unsigned char fcr;
+ unsigned char efr;
+
+ int use_dma;
+ int is_buf_dma_alloced;
+ /*
+* Some bits in registers are cleared on a read, so they must
+* be saved whenever the register is read but the bits will not
+* be immediately processed.
+*/
+ unsigned intlsr_break_flag;
+#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
+ unsigned char msr_saved_flags;
+ charname[20];
+
[PATCHv1 2/3] OMAP UART: Add platform data for omap-serial driver.
From: Govindraj R govindraj.r...@ti.com
This patch adds platform data support for omap-serial driver.
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 140 +++
1 file changed, 140 insertions(+)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 021130d..0730f9d 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -13,6 +13,9 @@
* Copyright (C) 2009 Texas Instruments
* Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
*
+ * Copyright (C) 2009 Texas Instruments
+ * Added support for Omap-Serial driver - Govindraj R govindraj.r...@ti.com
+ *
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
* for more details.
@@ -29,6 +32,10 @@
#include mach/clock.h
#include mach/control.h
+#ifdef CONFIG_SERIAL_OMAP
+#include mach/dma.h
+#include mach/omap-serial.h
+#endif
#include prm.h
#include pm.h
#include prm-regbits-34xx.h
@@ -37,6 +44,7 @@
#define DEFAULT_TIMEOUT (5 * HZ)
+#ifdef CONFIG_SERIAL_8250
struct omap_uart_state {
int num;
int can_sleep;
@@ -648,3 +656,135 @@ void __init omap_serial_init(void)
}
}
}
+#endif
+
+#ifdef CONFIG_SERIAL_OMAP
+
+static struct uart_dma_info uart1_dma_state = {
+#ifdef CONFIG_SERIAL_OMAP_DMA_UART1
+ .dma_enabled= 1,
+ .rx_dma_bufsize = 4096,
+ .rx_timeout = 1,
+#endif
+};
+
+static struct uart_dma_info uart2_dma_state = {
+#ifdef CONFIG_SERIAL_OMAP_DMA_UART2
+ .dma_enabled= 1,
+ .rx_dma_bufsize = 4096,
+ .rx_timeout = 1,
+#endif
+};
+
+static struct uart_dma_info uart3_dma_state = {
+#ifdef CONFIG_SERIAL_OMAP_DMA_UART3
+ .dma_enabled= 1,
+ .rx_dma_bufsize = 4096,
+ .rx_timeout = 1,
+#endif
+};
+
+static struct resource omap2_uart1_resources[] = {
+ {
+ .start = OMAP_UART1_BASE,
+ .end= OMAP_UART1_BASE + 0x3ff,
+ .flags = IORESOURCE_MEM,
+ }, {
+ /* UART1 IRQ - 72*/
+ .start = INT_24XX_UART1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ /* UART1 TX DMA CHANNEL -S_DMA_48- */
+ .start = OMAP24XX_DMA_UART1_TX,
+ .flags = IORESOURCE_DMA,
+ }, {
+ /* UART1 RX DMA CHANNEL -S_DMA_49- */
+ .start = OMAP24XX_DMA_UART1_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+
+static struct resource omap2_uart2_resources[] = {
+ {
+ .start = OMAP_UART2_BASE,
+ .end= OMAP_UART2_BASE + 0x3ff,
+ .flags = IORESOURCE_MEM,
+ }, {
+ /* UART2 IRQ - 73*/
+ .start = INT_24XX_UART2_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ /* UART2 TX DMA CHANNEL -S_DMA_50- */
+ .start = OMAP24XX_DMA_UART2_TX,
+ .flags = IORESOURCE_DMA,
+ }, {
+ /* UART2 RX DMA CHANNEL -S_DMA_51- */
+ .start = OMAP24XX_DMA_UART2_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+
+static struct resource omap2_uart3_resources[] = {
+ {
+ .start = OMAP_UART3_BASE,
+ .end= OMAP_UART3_BASE + 0x3ff,
+ .flags = IORESOURCE_MEM,
+ }, {
+ /* UART3 IRQ - 74*/
+ .start = INT_24XX_UART3_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ /* UART3 TX DMA CHANNEL -S_DMA_52- */
+ .start = OMAP24XX_DMA_UART3_TX,
+ .flags = IORESOURCE_DMA,
+ }, {
+ /* UART3 RX DMA CHANNEL -S_DMA_53- */
+ .start = OMAP24XX_DMA_UART3_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+
+/* OMAP UART platform structure */
+static struct platform_device uart1_device = {
+ .name = omap-uart,
+ .id = 1,
+ .num_resources = ARRAY_SIZE(omap2_uart1_resources),
+ .resource = omap2_uart1_resources,
+ .dev= {
+ .platform_data = uart1_dma_state,
+ },
+};
+static struct platform_device uart2_device = {
+ .name = omap-uart,
+ .id = 2,
+ .num_resources = ARRAY_SIZE(omap2_uart2_resources),
+ .resource = omap2_uart2_resources,
+ .dev= {
+ .platform_data = uart2_dma_state,
+ },
+};
+static struct platform_device
[PATCHv1 3/3] OMAP UART: Add omap-serial driver support in omap_3430sdp_defconfig
From: Govindraj R govindraj.r...@ti.com This patch adds omap-serial driver support for 3430SDP. Signed-off-by: Govindraj R govindraj.r...@ti.com --- arch/arm/configs/omap_3430sdp_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig index 8a4a7e2..787d52e 100644 --- a/arch/arm/configs/omap_3430sdp_defconfig +++ b/arch/arm/configs/omap_3430sdp_defconfig @@ -880,6 +880,7 @@ CONFIG_SERIAL_8250_RSA=y # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y +# CONFIG_SERIAL_OMAP is not set CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set # CONFIG_LEGACY_PTYS is not set -- 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] video: omap2: dss: RET on idle, enable/disable dss clocks only when needed.
On Wed, 2009-09-23 at 17:44 +0200, ext Kevin Hilman wrote: Tomi Valkeinen tomi.valkei...@nokia.com writes: On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote: Tomi Valkeinen tomi.valkei...@nokia.com writes: Hi, On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, If you disable the clocks to allow RET, you also allow OFF mode. And resuming from OFF mode hasn't been implemented for DSI, if I recall right. And when I was testing it, it didn't seem to be trivial with the DSI PLL. You can limiting the pwrdm next state to RET when being called from cpuidle. No, you _must_ limit it to RET. Otherwise the DSI will break down. So we can either keep the dsi code as it is now, or explicitely disable OFF mode and then apply your patch. But your patch alone won't work. Or could add a hack to this patch so that 'enable_off_mode' doesn't affect DSS_MOD until DSS has off-mode support. Is this something that the driver can do with the current PM API? The thing is, most of the DSS has off-mode support, only DSI and RFBI is missing the support. So optimally we would allow full PM normally, but when DSI display is in use, only allow RET. There's not an official API for this, but for testing, you could just set the next state for the DSS_MOD to be off. This would be overridden whenever someone changes the enable_off_mode flag. In general, we don't want drivers restricting states at that level. We'd rather the drivers use the OMAP PM layer to define/declare its constraints. If I want to disable OFF mode for DSS with constraints, doesn't it mean that I need to dig out a magic number, and use it as the max wakeup latency, and that latency will then limit DSS from going to OFF mode? In the long run I think we anyway need to somehow dynamically manage the power state. I haven't measured it but I believe resuming from OFF will have a bit of a penalty, as (I think) DSI PLL etc. will have to reinitialized. But it would still be good to allow RET whenever possible, and OFF only after some period of inactivity. This is the purpose of latency constraints. These can be used when the latency of going OFF will cause a problem. I think this is a different problem. My understanding of the PM latency functionality is that they control how quickly MPU responds to interrupts, or how quickly the HW module is awake after clk_enable(). That's only part of the story. The problem here is that there's bunch of DSI initialization that needs to be done after the DSS module has woken up. The DSI PLL needs to be configured and locked, complex IO has to be configured etc. I don't know how long those take (should make some measurements at some point), but I imagine they are not anywhere near instant. And the latency from those things is what I'm concerned about. So it would be beneficial if the DSS driver could define easily what DSS PM level is allowed. Actually, the OMAP PM layer is meant to handle device wakeup latencies as well. See Documentation/arm/OMAP/omap_pm, and the set_max_dev_wakeup_lat() hook in particular. For example, if you know that DSS wakeup from OFF takes X usecs and the driver has set a max device wakeup latency X, then DSS will never go to OFF. The same can be done to prevent RET for even faster wakeup. The doc says set_max_dev_wakeup_lat() function to constrain the device wakeup latency (from clk_enable() to accessibility). I understood accessibility meaning that the HW registers can be accessed, and also as registers should be accessible after clk_enable(), it would mean that clk_enable will block at most the defined wakeup latency. If it is not like that, and the driver initialization is included, how does the PM layer know how long it takes for the DSS driver to reconfigure the DSS hardware from OFF mode? Tomi -- 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
Build break on mainline tree for 3430 SDP
Build break compiling Linus' git tree for 3430 SDP. I get this with the default SDP config. Haven't looked at the code yet to find a fix. - Anand CC arch/arm/mach-omap2/board-3430sdp.o In file included from arch/arm/mach-omap2/board-3430sdp.c:41: arch/arm/plat-omap/include/mach/keypad.h:38:1: warning: KEY redefined In file included from include/linux/i2c/twl4030.h:29, from arch/arm/mach-omap2/board-3430sdp.c:22: include/linux/input/matrix_keypad.h:10:1: warning: this is the location of the previous definition In file included from arch/arm/mach-omap2/board-3430sdp.c:41: arch/arm/plat-omap/include/mach/keypad.h:39:1: warning: PERSISTENT_KEY redefined In file included from arch/arm/mach-omap2/board-3430sdp.c:22: include/linux/i2c/twl4030.h:356:1: warning: this is the location of the previous definition arch/arm/mach-omap2/board-3430sdp.c:94: error: unknown field 'keymap' specified in initializer arch/arm/mach-omap2/board-3430sdp.c:94: warning: the address of 'sdp3430_keymap' will always evaluate as 'true' arch/arm/mach-omap2/board-3430sdp.c:95: error: unknown field 'keymapsize' specified in initializer arch/arm/mach-omap2/board-3430sdp.c:95: warning: excess elements in struct initializer arch/arm/mach-omap2/board-3430sdp.c:95: warning: (near initialization for 'sdp3430_kp_data') make[1]: *** [arch/arm/mach-omap2/board-3430sdp.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 -- 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] dspbridge: Remove duplicates
From: Andy Shevchenko ext-andriy.shevche...@nokia.com includecheck found few duplicates. So, clean up them. Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com --- drivers/dsp/bridge/rmgr/disp.c |1 - drivers/dsp/bridge/rmgr/drv_interface.c |1 - drivers/dsp/bridge/rmgr/proc.c |1 - drivers/dsp/bridge/wmd/io_sm.c |1 - 4 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/disp.c b/drivers/dsp/bridge/rmgr/disp.c index d6ddf6e..0645398 100644 --- a/drivers/dsp/bridge/rmgr/disp.c +++ b/drivers/dsp/bridge/rmgr/disp.c @@ -59,7 +59,6 @@ #include dspbridge/dbc.h /* --- OS Adaptation Layer */ -#include dspbridge/dev.h #include dspbridge/mem.h #include dspbridge/sync.h diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c b/drivers/dsp/bridge/rmgr/drv_interface.c index f68978a..0f70257 100644 --- a/drivers/dsp/bridge/rmgr/drv_interface.c +++ b/drivers/dsp/bridge/rmgr/drv_interface.c @@ -93,7 +93,6 @@ #include dspbridge/resourcecleanup.h #include dspbridge/chnl.h #include dspbridge/proc.h -#include dspbridge/cfg.h #include dspbridge/dev.h #include dspbridge/drvdefs.h #include dspbridge/drv.h diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index c3add40..c720f79 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -138,7 +138,6 @@ #include dspbridge/dbdcd.h #include dspbridge/msg.h #include dspbridge/wmdioctl.h -#include dspbridge/drv.h /* --- This */ #include dspbridge/proc.h diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c index 1d478ad..fefa065 100644 --- a/drivers/dsp/bridge/wmd/io_sm.c +++ b/drivers/dsp/bridge/wmd/io_sm.c @@ -77,7 +77,6 @@ #include _tiomap.h #include tiomap_io.h #include _tiomap_pwr.h -#include tiomap_io.h /* --- Platform Manager */ #include dspbridge/cod.h -- 1.5.6.5 -- 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 01/19] OMAP2: Add funcs for writing SMS_ROT_* registers
SMS_ROT_* registers are used by VRFB rotation engine.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/sdrc.c | 16
arch/arm/plat-omap/include/mach/sdrc.h |9 -
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index 9e3bd4f..6a5a2c5 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -133,3 +133,19 @@ void __init omap2_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
(1 SDRC_POWER_PAGEPOLICY_SHIFT);
sdrc_write_reg(l, SDRC_POWER);
}
+
+void omap2_sms_write_rot_control(u32 val, unsigned ctx)
+{
+ sms_write_reg(val, SMS_ROT_CONTROL(ctx));
+}
+
+void omap2_sms_write_rot_size(u32 val, unsigned ctx)
+{
+ sms_write_reg(val, SMS_ROT_SIZE(ctx));
+}
+
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
+{
+ sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
+}
+
diff --git a/arch/arm/plat-omap/include/mach/sdrc.h
b/arch/arm/plat-omap/include/mach/sdrc.h
index 1c09c78..3b157ce 100644
--- a/arch/arm/plat-omap/include/mach/sdrc.h
+++ b/arch/arm/plat-omap/include/mach/sdrc.h
@@ -88,7 +88,10 @@
/* SMS register offsets - read/write with sms_{read,write}_reg() */
-#define SMS_SYSCONFIG 0x010
+#define SMS_SYSCONFIG 0x010
+#define SMS_ROT_CONTROL(context) (0x180 + 0x10 * context)
+#define SMS_ROT_SIZE(context) (0x184 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context) (0x188 + 0x10 * context)
/* REVISIT: fill in other SMS registers here */
@@ -121,6 +124,10 @@ int omap2_sdrc_get_params(unsigned long r,
struct omap_sdrc_params **sdrc_cs0,
struct omap_sdrc_params **sdrc_cs1);
+void omap2_sms_write_rot_control(u32 val, unsigned ctx);
+void omap2_sms_write_rot_size(u32 val, unsigned ctx);
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
+
#ifdef CONFIG_ARCH_OMAP2
struct memory_timings {
--
1.6.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 02/19] OMAP: OMAPFB: split omapfb.h
Split arch/arm/plat-omap/include/mach/omapfb.h into two files: include/linux/omapfb.h - ioctls etc for userspace and some kernel stuff for board files drivers/video/omap/omapfb.h - for omapfb internal use This cleans up omapfb.h and also makes it easier for the upcoming new DSS driver to co-exist with the old driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/io.c |2 +- arch/arm/plat-omap/fb.c |2 +- arch/arm/plat-omap/include/mach/omapfb.h | 398 -- drivers/video/omap/blizzard.c|2 +- drivers/video/omap/dispc.c |2 +- drivers/video/omap/hwa742.c |2 +- drivers/video/omap/lcd_2430sdp.c |3 +- drivers/video/omap/lcd_ams_delta.c |3 +- drivers/video/omap/lcd_apollon.c |3 +- drivers/video/omap/lcd_h3.c |2 +- drivers/video/omap/lcd_h4.c |2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |3 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c|3 +- drivers/video/omap/lcd_omap3beagle.c |3 +- drivers/video/omap/lcd_omap3evm.c|3 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c |2 +- drivers/video/omap/lcd_palmtt.c |2 +- drivers/video/omap/lcd_palmz71.c |2 +- drivers/video/omap/lcdc.c|3 +- drivers/video/omap/omapfb.h | 227 + drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c|3 +- drivers/video/omap/sossi.c |2 +- include/linux/omapfb.h | 197 +++ 30 files changed, 461 insertions(+), 426 deletions(-) delete mode 100644 arch/arm/plat-omap/include/mach/omapfb.h create mode 100644 drivers/video/omap/omapfb.h create mode 100644 include/linux/omapfb.h diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index ed2a48a..6fbde33 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -14,6 +14,7 @@ #include linux/platform_device.h #include linux/input.h #include linux/clk.h +#include linux/omapfb.h #include linux/spi/spi.h #include linux/spi/ads7846.h @@ -32,7 +33,6 @@ #include mach/keypad.h #include mach/common.h #include mach/dsp_common.h -#include mach/omapfb.h #include mach/hwa742.h #include mach/lcd_mipid.h #include mach/mmc.h diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 7574b6f..4a08ad3 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -22,13 +22,13 @@ #include linux/init.h #include linux/io.h #include linux/clk.h +#include linux/omapfb.h #include asm/tlb.h #include asm/mach/map.h #include mach/mux.h -#include mach/omapfb.h #include mach/sram.h #include mach/sdrc.h #include mach/gpmc.h diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c index 3746222..40615a6 100644 --- a/arch/arm/plat-omap/fb.c +++ b/arch/arm/plat-omap/fb.c @@ -28,13 +28,13 @@ #include linux/platform_device.h #include linux/bootmem.h #include linux/io.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach/map.h #include mach/board.h #include mach/sram.h -#include mach/omapfb.h #if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE) diff --git a/arch/arm/plat-omap/include/mach/omapfb.h b/arch/arm/plat-omap/include/mach/omapfb.h deleted file mode 100644 index b226bdf..000 --- a/arch/arm/plat-omap/include/mach/omapfb.h +++ /dev/null @@ -1,398 +0,0 @@ -/* - * File: arch/arm/plat-omap/include/mach/omapfb.h - * - * Framebuffer driver for TI OMAP boards - * - * Copyright (C) 2004 Nokia Corporation - * Author: Imre Deak imre.d...@nokia.com - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - */ - -#ifndef __OMAPFB_H -#define __OMAPFB_H - -#include asm/ioctl.h -#include asm/types.h - -/* IOCTL
[PATCH 04/19] OMAP: Add VRAM manager
Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:
- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations
The upcoming DSS2 uses VRAM manager.
VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/io.c |2 +
arch/arm/plat-omap/include/mach/vram.h | 63 +++
arch/arm/plat-omap/sram.c |8 +
drivers/video/Kconfig |1 +
drivers/video/Makefile |1 +
drivers/video/omap2/Kconfig|2 +
drivers/video/omap2/Makefile |1 +
drivers/video/omap2/vram.c | 655
8 files changed, 733 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vram.h
create mode 100644 drivers/video/omap2/Kconfig
create mode 100644 drivers/video/omap2/Makefile
create mode 100644 drivers/video/omap2/vram.c
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a08ad3..e5dd736 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -33,6 +33,7 @@
#include mach/sdrc.h
#include mach/gpmc.h
#include mach/serial.h
+#include mach/vram.h
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdev is ready */
#include clock.h
@@ -246,6 +247,7 @@ void __init omap2_map_common_io(void)
omap2_check_revision();
omap_sram_init();
omapfb_reserve_sdram();
+ omap_vram_reserve_sdram();
}
/*
diff --git a/arch/arm/plat-omap/include/mach/vram.h
b/arch/arm/plat-omap/include/mach/vram.h
new file mode 100644
index 000..fe72f81
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vram.h
@@ -0,0 +1,63 @@
+/*
+ * VRAM manager for OMAP
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRAM_H__
+#define __OMAP_VRAM_H__
+
+#include linux/autoconf.h
+#include linux/types.h
+
+#define OMAP_VRAM_MEMTYPE_SDRAM0
+#define OMAP_VRAM_MEMTYPE_SRAM 1
+#define OMAP_VRAM_MEMTYPE_MAX 1
+
+extern int omap_vram_add_region(unsigned long paddr, size_t size);
+extern int omap_vram_free(unsigned long paddr, size_t size);
+extern int omap_vram_alloc(int mtype, size_t size, unsigned long *paddr);
+extern int omap_vram_reserve(unsigned long paddr, size_t size);
+extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
+ unsigned long *largest_free_block);
+
+#ifdef CONFIG_OMAP2_VRAM
+extern void omap_vram_set_sdram_vram(u32 size, u32 start);
+extern void omap_vram_set_sram_vram(u32 size, u32 start);
+
+extern void omap_vram_reserve_sdram(void);
+extern unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+ unsigned long size_avail);
+#else
+static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
+static inline void omap_vram_set_sram_vram(u32 size, u32 start) { }
+
+static inline void omap_vram_reserve_sdram(void) { }
+static inline unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+ unsigned long size_avail)
+{
+ return 0;
+}
+#endif
+
+#endif
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 925f647..cda311b 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -28,6 +28,7 @@
#include mach/sram.h
#include mach/board.h
#include mach/cpu.h
+#include mach/vram.h
#include mach/control.h
@@
[PATCH 10/19] OMAP: DSS2: DPI driver
This implements MIPI DPI interface.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/dpi.c | 388 +
1 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/dpi.c
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
new file mode 100644
index 000..b6543c8
--- /dev/null
+++ b/drivers/video/omap2/dss/dpi.c
@@ -0,0 +1,388 @@
+/*
+ * linux/drivers/video/omap2/dss/dpi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME DPI
+
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/errno.h
+
+#include mach/board.h
+#include mach/display.h
+#include mach/cpu.h
+
+#include dss.h
+
+static struct {
+ int update_enabled;
+} dpi;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
+ unsigned long *fck, int *lck_div, int *pck_div)
+{
+ struct dsi_clock_info cinfo;
+ int r;
+
+ r = dsi_pll_calc_pck(is_tft, pck_req, cinfo);
+ if (r)
+ return r;
+
+ r = dsi_pll_program(cinfo);
+ if (r)
+ return r;
+
+ dss_select_clk_source(0, 1);
+
+ dispc_set_lcd_divisor(cinfo.lck_div, cinfo.pck_div);
+
+ *fck = cinfo.dsi1_pll_fclk;
+ *lck_div = cinfo.lck_div;
+ *pck_div = cinfo.pck_div;
+
+ return 0;
+}
+#else
+static int dpi_set_dispc_clk(bool is_tft, unsigned long pck_req,
+ unsigned long *fck, int *lck_div, int *pck_div)
+{
+ struct dispc_clock_info cinfo;
+ int r;
+
+ r = dispc_calc_clock_div(is_tft, pck_req, cinfo);
+ if (r)
+ return r;
+
+ r = dispc_set_clock_div(cinfo);
+ if (r)
+ return r;
+
+ *fck = cinfo.fck;
+ *lck_div = cinfo.lck_div;
+ *pck_div = cinfo.pck_div;
+
+ return 0;
+}
+#endif
+
+static int dpi_set_mode(struct omap_dss_device *dssdev)
+{
+ struct omap_video_timings *t = dssdev-panel.timings;
+ int lck_div, pck_div;
+ unsigned long fck;
+ unsigned long pck;
+ bool is_tft;
+ int r = 0;
+
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+ dispc_set_pol_freq(dssdev-panel.config, dssdev-panel.acbi,
+ dssdev-panel.acb);
+
+ is_tft = (dssdev-panel.config OMAP_DSS_LCD_TFT) != 0;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+ r = dpi_set_dsi_clk(is_tft, t-pixel_clock * 1000,
+ fck, lck_div, pck_div);
+#else
+ r = dpi_set_dispc_clk(is_tft, t-pixel_clock * 1000,
+ fck, lck_div, pck_div);
+#endif
+ if (r)
+ goto err0;
+
+ pck = fck / lck_div / pck_div / 1000;
+
+ if (pck != t-pixel_clock) {
+ DSSWARN(Could not find exact pixel clock.
+ Requested %d kHz, got %lu kHz\n,
+ t-pixel_clock, pck);
+
+ t-pixel_clock = pck;
+ }
+
+ dispc_set_lcd_timings(t);
+
+err0:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ return r;
+}
+
+static int dpi_basic_init(struct omap_dss_device *dssdev)
+{
+ bool is_tft;
+
+ is_tft = (dssdev-panel.config OMAP_DSS_LCD_TFT) != 0;
+
+ dispc_set_parallel_interface_mode(OMAP_DSS_PARALLELMODE_BYPASS);
+ dispc_set_lcd_display_type(is_tft ? OMAP_DSS_LCD_DISPLAY_TFT :
+ OMAP_DSS_LCD_DISPLAY_STN);
+ dispc_set_tft_data_lines(dssdev-phy.dpi.data_lines);
+
+ return 0;
+}
+
+static int dpi_display_enable(struct omap_dss_device *dssdev)
+{
+ int r;
+
+ r = omap_dss_start_device(dssdev);
+ if (r) {
+ DSSERR(failed to start device\n);
+ goto err0;
+ }
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED) {
+ DSSERR(display already enabled\n);
+ r = -EINVAL;
+ goto err1;
+ }
+
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+ r = dpi_basic_init(dssdev);
+ if (r)
+ goto err2;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+ dss_clk_enable(DSS_CLK_FCK2);
+ r = dsi_pll_init(0, 1);
+
[PATCH 13/19] OMAP: DSS2: SDI driver
SDI (Serial Display Interface) implements TI Flatlink 3G display
interface.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/sdi.c | 261 +
1 files changed, 261 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/sdi.c
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
new file mode 100644
index 000..a9c727e
--- /dev/null
+++ b/drivers/video/omap2/dss/sdi.c
@@ -0,0 +1,261 @@
+/*
+ * linux/drivers/video/omap2/dss/sdi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME SDI
+
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/err.h
+
+#include mach/board.h
+#include mach/display.h
+#include dss.h
+
+static struct {
+ bool skip_init;
+ bool update_enabled;
+} sdi;
+
+static void sdi_basic_init(void)
+{
+ dispc_set_parallel_interface_mode(OMAP_DSS_PARALLELMODE_BYPASS);
+
+ dispc_set_lcd_display_type(OMAP_DSS_LCD_DISPLAY_TFT);
+ dispc_set_tft_data_lines(24);
+ dispc_lcd_enable_signal_polarity(1);
+}
+
+static int sdi_display_enable(struct omap_dss_device *dssdev)
+{
+ struct omap_video_timings *t = dssdev-panel.timings;
+ struct dispc_clock_info cinfo;
+ u16 lck_div, pck_div;
+ unsigned long fck;
+ unsigned long pck;
+ int r;
+
+ r = omap_dss_start_device(dssdev);
+ if (r) {
+ DSSERR(failed to start device\n);
+ goto err0;
+ }
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED) {
+ DSSERR(dssdev already enabled\n);
+ r = -EINVAL;
+ goto err1;
+ }
+
+ /* In case of skip_init sdi_init has already enabled the clocks */
+ if (!sdi.skip_init)
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+ sdi_basic_init();
+
+ /* 15.5.9.1.2 */
+ dssdev-panel.config |= OMAP_DSS_LCD_RF | OMAP_DSS_LCD_ONOFF;
+
+ dispc_set_pol_freq(dssdev-panel.config, dssdev-panel.acbi,
+ dssdev-panel.acb);
+
+ if (!sdi.skip_init)
+ r = dispc_calc_clock_div(1, t-pixel_clock * 1000,
+ cinfo);
+ else
+ r = dispc_get_clock_div(cinfo);
+
+ if (r)
+ goto err2;
+
+ fck = cinfo.fck;
+ lck_div = cinfo.lck_div;
+ pck_div = cinfo.pck_div;
+
+ pck = fck / lck_div / pck_div / 1000;
+
+ if (pck != t-pixel_clock) {
+ DSSWARN(Could not find exact pixel clock. Requested %d kHz,
+ got %lu kHz\n,
+ t-pixel_clock, pck);
+
+ t-pixel_clock = pck;
+ }
+
+
+ dispc_set_lcd_timings(t);
+
+ r = dispc_set_clock_div(cinfo);
+ if (r)
+ goto err2;
+
+ if (!sdi.skip_init) {
+ dss_sdi_init(dssdev-phy.sdi.datapairs);
+ dss_sdi_enable();
+ mdelay(2);
+ }
+
+ dispc_enable_lcd_out(1);
+
+ if (dssdev-driver-enable) {
+ r = dssdev-driver-enable(dssdev);
+ if (r)
+ goto err3;
+ }
+
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ sdi.skip_init = 0;
+
+ return 0;
+err3:
+ dispc_enable_lcd_out(0);
+err2:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+err1:
+ omap_dss_stop_device(dssdev);
+err0:
+ return r;
+}
+
+static int sdi_display_resume(struct omap_dss_device *dssdev);
+
+static void sdi_display_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-state == OMAP_DSS_DISPLAY_DISABLED)
+ return;
+
+ if (dssdev-state == OMAP_DSS_DISPLAY_SUSPENDED)
+ sdi_display_resume(dssdev);
+
+ if (dssdev-driver-disable)
+ dssdev-driver-disable(dssdev);
+
+ dispc_enable_lcd_out(0);
+
+ dss_sdi_disable();
+
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+ dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+
+ omap_dss_stop_device(dssdev);
+}
+
+static int sdi_display_suspend(struct omap_dss_device *dssdev)
+{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return -EINVAL;
+
+ if (dssdev-driver-suspend)
+
[PATCH 19/19] MAINTAINERS: Add OMAP2/3 DSS and OMAPFB maintainer
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- MAINTAINERS | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7c1c0b0..7245dae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3778,6 +3778,23 @@ L: linux-omap@vger.kernel.org S: Maintained F: drivers/video/omap/ +OMAP DISPLAY SUBSYSTEM SUPPORT (DSS2) +M: Tomi Valkeinen tomi.valkei...@nokia.com +L: linux-fbdev-de...@lists.sourceforge.net (moderated for non-subscribers) +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/video/omap2/dss/ +F: drivers/video/omap2/vrfb.c +F: drivers/video/omap2/vram.c +F: Documentation/arm/OMAP/DSS + +OMAP FRAMEBUFFER SUPPORT (FOR DSS2) +M: Tomi Valkeinen tomi.valkei...@nokia.com +L: linux-fbdev-de...@lists.sourceforge.net (moderated for non-subscribers) +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/video/omap2/omapfb/ + OMAP MMC SUPPORT M: Jarkko Lavinen jarkko.lavi...@nokia.com L: linux-omap@vger.kernel.org -- 1.6.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 17/19] OMAP: DSS2: Taal DSI command mode panel driver
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |2 +
drivers/video/omap2/displays/panel-taal.c | 900 +
3 files changed, 908 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-taal.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 396905d..79d2861 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -19,4 +19,10 @@ config PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config PANEL_TAAL
+tristate Taal DSI Panel
+depends on OMAP2_DSS_DSI
+help
+ Taal DSI command mode panel from TPO.
+
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index a26bbd2..d44e765 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C) += panel-samsung-lte430wq-f0c.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+
+obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
new file mode 100644
index 000..84f0d47
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -0,0 +1,900 @@
+/*
+ * Taal DSI command mode panel
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+/*#define DEBUG*/
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/jiffies.h
+#include linux/sched.h
+#include linux/backlight.h
+#include linux/fb.h
+#include linux/interrupt.h
+#include linux/gpio.h
+#include linux/completion.h
+
+#include mach/display.h
+
+/* DSI Virtual channel. Hardcoded for now. */
+#define TCH 0
+
+#define DCS_READ_NUM_ERRORS0x05
+#define DCS_READ_POWER_MODE0x0a
+#define DCS_READ_MADCTL0x0b
+#define DCS_READ_PIXEL_FORMAT 0x0c
+#define DCS_SLEEP_IN 0x10
+#define DCS_SLEEP_OUT 0x11
+#define DCS_DISPLAY_OFF0x28
+#define DCS_DISPLAY_ON 0x29
+#define DCS_COLUMN_ADDR0x2a
+#define DCS_PAGE_ADDR 0x2b
+#define DCS_MEMORY_WRITE 0x2c
+#define DCS_TEAR_OFF 0x34
+#define DCS_TEAR_ON0x35
+#define DCS_MEM_ACC_CTRL 0x36
+#define DCS_PIXEL_FORMAT 0x3a
+#define DCS_BRIGHTNESS 0x51
+#define DCS_CTRL_DISPLAY 0x53
+#define DCS_WRITE_CABC 0x55
+#define DCS_READ_CABC 0x56
+#define DCS_GET_ID10xda
+#define DCS_GET_ID20xdb
+#define DCS_GET_ID30xdc
+
+struct taal_data {
+ struct backlight_device *bldev;
+
+ unsigned long hw_guard_end; /* next value of jiffies when we can
+* issue the next sleep in/out command
+*/
+ unsigned long hw_guard_wait; /* max guard time in jiffies */
+
+ struct omap_dss_device *dssdev;
+
+ bool enabled;
+ u8 rotate;
+ bool mirror;
+
+ bool te_enabled;
+ bool use_ext_te;
+ struct completion te_completion;
+
+ bool use_dsi_bl;
+
+ bool cabc_broken;
+ unsigned cabc_mode;
+
+ bool intro_printed;
+};
+
+static void hw_guard_start(struct taal_data *td, int guard_msec)
+{
+ td-hw_guard_wait = msecs_to_jiffies(guard_msec);
+ td-hw_guard_end = jiffies + td-hw_guard_wait;
+}
+
+static void hw_guard_wait(struct taal_data *td)
+{
+ unsigned long wait = td-hw_guard_end - jiffies;
+
+ if ((long)wait 0 wait = td-hw_guard_wait) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(wait);
+ }
+}
+
+static int taal_dcs_read_1(u8 dcs_cmd, u8 *data)
+{
+ int r;
+ u8 buf[1];
+
+ r = dsi_vc_dcs_read(TCH, dcs_cmd, buf, 1);
+
+ if (r 0)
+ return r;
+
+ *data = buf[0];
+
+ return 0;
+}
+
+static int taal_dcs_write_0(u8 dcs_cmd)
+{
+ return dsi_vc_dcs_write(TCH, dcs_cmd, 1);
+}
+
+static int taal_dcs_write_1(u8 dcs_cmd, u8 param)
+{
+ u8 buf[2];
+
[PATCH 16/19] OMAP: DSS2: Add DPI panel drivers
- Generic panel
- Samsung LTE430WQ-F0C LCD Panel
- Sharp LS037V7DW01 LCD Panel
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/Kconfig|1 +
drivers/video/omap2/Makefile |1 +
drivers/video/omap2/displays/Kconfig | 22 +++
drivers/video/omap2/displays/Makefile |3 +
drivers/video/omap2/displays/panel-generic.c | 104 +
.../omap2/displays/panel-samsung-lte430wq-f0c.c| 113 +++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 153
7 files changed, 397 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/Kconfig
create mode 100644 drivers/video/omap2/displays/Makefile
create mode 100644 drivers/video/omap2/displays/panel-generic.c
create mode 100644 drivers/video/omap2/displays/panel-samsung-lte430wq-f0c.c
create mode 100644 drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 3e60d7e..d877c36 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -6,3 +6,4 @@ config OMAP2_VRFB
source drivers/video/omap2/dss/Kconfig
source drivers/video/omap2/omapfb/Kconfig
+source drivers/video/omap2/displays/Kconfig
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 3ba6ef5..d853d05 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
obj-y += dss/
obj-y += omapfb/
+obj-y += displays/
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
new file mode 100644
index 000..396905d
--- /dev/null
+++ b/drivers/video/omap2/displays/Kconfig
@@ -0,0 +1,22 @@
+menu OMAP2/3 Display Device Drivers
+depends on OMAP2_DSS
+
+config PANEL_GENERIC
+tristate Generic Panel
+help
+ Generic panel driver.
+ Used for DVI output for Beagle and OMAP3 SDP.
+
+config PANEL_SAMSUNG_LTE430WQ_F0C
+tristate Samsung LTE430WQ-F0C LCD Panel
+depends on OMAP2_DSS
+help
+ LCD Panel used on Overo Palo43
+
+config PANEL_SHARP_LS037V7DW01
+tristate Sharp LS037V7DW01 LCD Panel
+depends on OMAP2_DSS
+help
+ LCD Panel used in TI's SDP3430 and EVM boards
+
+endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
new file mode 100644
index 000..a26bbd2
--- /dev/null
+++ b/drivers/video/omap2/displays/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
+obj-$(CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C) += panel-samsung-lte430wq-f0c.o
+obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
new file mode 100644
index 000..738147e
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -0,0 +1,104 @@
+/*
+ * Generic panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include mach/display.h
+
+static struct omap_video_timings generic_panel_timings = {
+ /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = 640,
+ .y_res = 480,
+ .pixel_clock= 23500,
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 7,
+};
+
+static int generic_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT;
+ dssdev-panel.timings = generic_panel_timings;
+
+ return 0;
+}
+
+static void generic_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int generic_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void generic_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+}
+
+static int generic_panel_suspend(struct omap_dss_device *dssdev)
+{
+ generic_panel_disable(dssdev);
+
[PATCH 12/19] OMAP: DSS2: RFBI driver
RFBI (Remote FrameBuffer Interface) implements MIPI DBI interface.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/rfbi.c | 1310
1 files changed, 1310 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/rfbi.c
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
new file mode 100644
index 000..9dd2349
--- /dev/null
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -0,0 +1,1310 @@
+/*
+ * linux/drivers/video/omap2/dss/rfbi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME RFBI
+
+#include linux/kernel.h
+#include linux/dma-mapping.h
+#include linux/vmalloc.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/kfifo.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+#include linux/seq_file.h
+
+#include mach/board.h
+#include mach/display.h
+#include dss.h
+
+/*#define MEASURE_PERF*/
+
+#define RFBI_BASE 0x48050800
+
+struct rfbi_reg { u16 idx; };
+
+#define RFBI_REG(idx) ((const struct rfbi_reg) { idx })
+
+#define RFBI_REVISION RFBI_REG(0x)
+#define RFBI_SYSCONFIG RFBI_REG(0x0010)
+#define RFBI_SYSSTATUS RFBI_REG(0x0014)
+#define RFBI_CONTROL RFBI_REG(0x0040)
+#define RFBI_PIXEL_CNT RFBI_REG(0x0044)
+#define RFBI_LINE_NUMBER RFBI_REG(0x0048)
+#define RFBI_CMD RFBI_REG(0x004c)
+#define RFBI_PARAM RFBI_REG(0x0050)
+#define RFBI_DATA RFBI_REG(0x0054)
+#define RFBI_READ RFBI_REG(0x0058)
+#define RFBI_STATUSRFBI_REG(0x005c)
+
+#define RFBI_CONFIG(n) RFBI_REG(0x0060 + (n)*0x18)
+#define RFBI_ONOFF_TIME(n) RFBI_REG(0x0064 + (n)*0x18)
+#define RFBI_CYCLE_TIME(n) RFBI_REG(0x0068 + (n)*0x18)
+#define RFBI_DATA_CYCLE1(n)RFBI_REG(0x006c + (n)*0x18)
+#define RFBI_DATA_CYCLE2(n)RFBI_REG(0x0070 + (n)*0x18)
+#define RFBI_DATA_CYCLE3(n)RFBI_REG(0x0074 + (n)*0x18)
+
+#define RFBI_VSYNC_WIDTH RFBI_REG(0x0090)
+#define RFBI_HSYNC_WIDTH RFBI_REG(0x0094)
+
+#define RFBI_CMD_FIFO_LEN_BYTES (16 * sizeof(struct update_param))
+
+#define REG_FLD_MOD(idx, val, start, end) \
+ rfbi_write_reg(idx, FLD_MOD(rfbi_read_reg(idx), val, start, end))
+
+/* To work around an RFBI transfer rate limitation */
+#define OMAP_RFBI_RATE_LIMIT1
+
+enum omap_rfbi_cycleformat {
+ OMAP_DSS_RFBI_CYCLEFORMAT_1_1 = 0,
+ OMAP_DSS_RFBI_CYCLEFORMAT_2_1 = 1,
+ OMAP_DSS_RFBI_CYCLEFORMAT_3_1 = 2,
+ OMAP_DSS_RFBI_CYCLEFORMAT_3_2 = 3,
+};
+
+enum omap_rfbi_datatype {
+ OMAP_DSS_RFBI_DATATYPE_12 = 0,
+ OMAP_DSS_RFBI_DATATYPE_16 = 1,
+ OMAP_DSS_RFBI_DATATYPE_18 = 2,
+ OMAP_DSS_RFBI_DATATYPE_24 = 3,
+};
+
+enum omap_rfbi_parallelmode {
+ OMAP_DSS_RFBI_PARALLELMODE_8 = 0,
+ OMAP_DSS_RFBI_PARALLELMODE_9 = 1,
+ OMAP_DSS_RFBI_PARALLELMODE_12 = 2,
+ OMAP_DSS_RFBI_PARALLELMODE_16 = 3,
+};
+
+enum update_cmd {
+ RFBI_CMD_UPDATE = 0,
+ RFBI_CMD_SYNC = 1,
+};
+
+static int rfbi_convert_timings(struct rfbi_timings *t);
+static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
+static void process_cmd_fifo(void);
+
+static struct {
+ void __iomem*base;
+
+ unsigned long l4_khz;
+
+ enum omap_rfbi_datatype datatype;
+ enum omap_rfbi_parallelmode parallelmode;
+
+ enum omap_rfbi_te_mode te_mode;
+ int te_enabled;
+
+ void (*framedone_callback)(void *data);
+ void *framedone_callback_data;
+
+ struct omap_dss_device *dssdev[2];
+
+ struct kfifo *cmd_fifo;
+ spinlock_tcmd_lock;
+ struct completion cmd_done;
+ atomic_t cmd_fifo_full;
+ atomic_t cmd_pending;
+#ifdef MEASURE_PERF
+ unsigned perf_bytes;
+ ktime_t perf_setup_time;
+ ktime_t perf_start_time;
+#endif
+} rfbi;
+
+struct update_region {
+ u16 x;
+ u16 y;
+ u16 w;
+ u16 h;
+};
+
+struct update_param {
+ u8 rfbi_module;
+ u8 cmd;
+
+ union {
+ struct update_region r;
+ struct completion *sync;
+ } par;
+};
+
+static inline
[PATCH 18/19] OMAP: SDP: Enable DSS2 for OMAP3 SDP board
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/configs/omap_3430sdp_defconfig | 29 +-
arch/arm/mach-omap2/board-3430sdp.c | 167 ---
2 files changed, 177 insertions(+), 19 deletions(-)
diff --git a/arch/arm/configs/omap_3430sdp_defconfig
b/arch/arm/configs/omap_3430sdp_defconfig
index 8a4a7e2..59e26e4 100644
--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -1336,10 +1336,33 @@ CONFIG_FB_CFB_IMAGEBLIT=y
#
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
-CONFIG_FB_OMAP=y
-# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_LCD_VGA is not set
# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
-CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
+CONFIG_OMAP2_VRAM=y
+CONFIG_OMAP2_VRFB=y
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=4
+CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
+# CONFIG_OMAP2_DSS_RFBI is not set
+CONFIG_OMAP2_DSS_VENC=y
+# CONFIG_OMAP2_DSS_SDI is not set
+# CONFIG_OMAP2_DSS_DSI is not set
+# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
+CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
+CONFIG_FB_OMAP2=y
+CONFIG_FB_OMAP2_DEBUG_SUPPORT=y
+# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
+CONFIG_FB_OMAP2_NUM_FBS=3
+
+#
+# OMAP2/3 Display Device Drivers
+#
+CONFIG_PANEL_GENERIC=y
+# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set
+CONFIG_PANEL_SHARP_LS037V7DW01=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bd57ec7..f5af39a 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -36,6 +36,7 @@
#include mach/common.h
#include mach/dma.h
#include mach/gpmc.h
+#include mach/display.h
#include mach/control.h
#include mach/keypad.h
@@ -148,31 +149,152 @@ static struct spi_board_info sdp3430_spi_board_info[]
__initdata = {
},
};
-static struct platform_device sdp3430_lcd_device = {
- .name = sdp2430_lcd,
- .id = -1,
+
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+static int dvi_enabled;
+
+static void __init sdp3430_display_init(void)
+{
+ int r;
+
+ enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
+ backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+
+ r = gpio_request(enable_gpio, LCD reset);
+ if (r) {
+ printk(KERN_ERR failed to get LCD reset GPIO\n);
+ goto err0;
+ }
+
+ r = gpio_request(backlight_gpio, LCD Backlight);
+ if (r) {
+ printk(KERN_ERR failed to get LCD backlight GPIO\n);
+ goto err1;
+ }
+
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+
+ return;
+err1:
+ gpio_free(enable_gpio);
+err0:
+ return;
+}
+
+static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ if (dvi_enabled) {
+ printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
+ return -EINVAL;
+ }
+
+ gpio_direction_output(enable_gpio, 1);
+ gpio_direction_output(backlight_gpio, 1);
+
+ lcd_enabled = 1;
+
+ return 0;
+}
+
+static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ lcd_enabled = 0;
+
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+}
+
+static int sdp3430_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ if (lcd_enabled) {
+ printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
+ return -EINVAL;
+ }
+
+ dvi_enabled = 1;
+
+ return 0;
+}
+
+static void sdp3430_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ dvi_enabled = 0;
+}
+
+static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+
+static struct omap_dss_device sdp3430_lcd_device = {
+ .name = lcd,
+ .driver_name= sharp_ls_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 16,
+ .platform_enable= sdp3430_panel_enable_lcd,
+ .platform_disable = sdp3430_panel_disable_lcd,
};
-static struct regulator_consumer_supply sdp3430_vdac_supply = {
- .supply = vdac,
- .dev= sdp3430_lcd_device.dev,
+static struct omap_dss_device sdp3430_dvi_device = {
+ .name = dvi,
+ .driver_name= generic_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .platform_enable=
RE: Build break on mainline tree for 3430 SDP
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Thursday, September 24, 2009 4:38 PM To: linux-omap@vger.kernel.org Subject: Build break on mainline tree for 3430 SDP Build break compiling Linus' git tree for 3430 SDP. I get this with the default SDP config. Haven't looked at the code yet to find a fix. - Anand CC arch/arm/mach-omap2/board-3430sdp.o In file included from arch/arm/mach-omap2/board-3430sdp.c:41: arch/arm/plat-omap/include/mach/keypad.h:38:1: warning: KEY redefined In file included from include/linux/i2c/twl4030.h:29, from arch/arm/mach-omap2/board-3430sdp.c:22: include/linux/input/matrix_keypad.h:10:1: warning: this is the location of the previous definition In file included from arch/arm/mach-omap2/board-3430sdp.c:41: arch/arm/plat-omap/include/mach/keypad.h:39:1: warning: PERSISTENT_KEY redefined In file included from arch/arm/mach-omap2/board-3430sdp.c:22: include/linux/i2c/twl4030.h:356:1: warning: this is the location of the previous definition arch/arm/mach-omap2/board-3430sdp.c:94: error: unknown field 'keymap' specified in initializer arch/arm/mach-omap2/board-3430sdp.c:94: warning: the address of 'sdp3430_keymap' will always evaluate as 'true' arch/arm/mach-omap2/board-3430sdp.c:95: error: unknown field 'keymapsize' specified in initializer arch/arm/mach-omap2/board-3430sdp.c:95: warning: excess elements in struct initializer arch/arm/mach-omap2/board-3430sdp.c:95: warning: (near initialization for 'sdp3430_kp_data') make[1]: *** [arch/arm/mach-omap2/board-3430sdp.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 I had found similar issues on 2.6.30. Had submitted a patch to remove duplicate definition of KET and PERSISTENT_KEY. Look for patch title Remove duplicate definitions on JUN 16. (Unfortunately marc.info is not showing patches for last 2 weeks in June) http://markmail.org/search/?q=sanjeev#query:sanjeev%20from%3A%22Sanjeev%20Premi%22%20list%3Aorg.kernel.vger.linux-omap+page:2+mid:t7fonfanbf7736fz+state:results Best regards, Sanjeev -- 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 -- 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 05/19] OMAP: Add support for VRFB rotation engine
VRFB rotation engine is a block in OMAP2/3 that offers 12 independent
contexts that can be used for framebuffer rotation.
Each context has a backend area of real memory, where it stores the
pixels in undisclosed format. This memory is offered to users via 4
virtual memory areas, which see the same memory area in different
rotation angles (0, 90, 180 and 270 degrees).
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/plat-omap/include/mach/vrfb.h | 46 ++
drivers/video/omap2/Kconfig|3 +
drivers/video/omap2/Makefile |1 +
drivers/video/omap2/vrfb.c | 277
4 files changed, 327 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vrfb.h
create mode 100644 drivers/video/omap2/vrfb.c
diff --git a/arch/arm/plat-omap/include/mach/vrfb.h
b/arch/arm/plat-omap/include/mach/vrfb.h
new file mode 100644
index 000..8790612
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vrfb.h
@@ -0,0 +1,46 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRFB_H__
+#define __OMAP_VRFB_H__
+
+#define OMAP_VRFB_LINE_LEN 2048
+
+struct vrfb {
+ u8 context;
+ void __iomem *vaddr[4];
+ unsigned long paddr[4];
+ u16 xoffset;
+ u16 yoffset;
+ u8 bytespp;
+};
+
+extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_suspend_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_resume_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp);
+extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height,
+ unsigned bytespp, bool yuv_mode);
+extern void omap_vrfb_restore_context(void);
+
+#endif /* __VRFB_H */
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 7a6c4c9..ac8b650 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -1,2 +1,5 @@
config OMAP2_VRAM
bool
+
+config OMAP2_VRFB
+ bool
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 7fdf7bd..aa3751b 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_OMAP2_VRAM) += vram.o
+obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
new file mode 100644
index 000..8726689
--- /dev/null
+++ b/drivers/video/omap2/vrfb.c
@@ -0,0 +1,277 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/ioport.h
+#include linux/io.h
+#include linux/bitops.h
+#include linux/mutex.h
+
+#include mach/io.h
+#include mach/vrfb.h
+#include mach/sdrc.h
+/*#define DEBUG*/
+
+#ifdef DEBUG
+#define DBG(format, ...) pr_debug(VRFB: format, ## __VA_ARGS__)
+#else
+#define DBG(format, ...)
+#endif
+
+#define SMS_ROT_VIRT_BASE(context, rot) \
+ (((context = 4) ? 0xD000 : 0x7000) \
++ (0x400 * (context)) \
++ (0x100 * (rot)))
+
+#define OMAP_VRFB_SIZE (2048 * 2048 * 4)
+
+#define VRFB_PAGE_WIDTH_EXP5 /* Assuming SDRAM pagesize= 1024 */
+#define VRFB_PAGE_HEIGHT_EXP 5 /* 1024 = 2^5 * 2^5 */
+#define VRFB_PAGE_WIDTH(1 VRFB_PAGE_WIDTH_EXP)
+#define VRFB_PAGE_HEIGHT (1 VRFB_PAGE_HEIGHT_EXP)
+#define SMS_IMAGEHEIGHT_OFFSET 16
+#define
[PATCH 03/19] OMAP: OMAPFB: add omapdss device
The upcoming new display subsystem driver is divided to two devices,
omapdss and omapfb, of which omapdss handles the actual hardware.
This patch adds a dummy omapdss platform device for the current omapfb
driver, which is then used to get the clocks. This will make it possible
for the current and the new display drivers to co-exist.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/clock24xx.c |8
arch/arm/mach-omap2/clock34xx.c | 14 +++---
drivers/video/omap/dispc.c | 19 ---
3 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index bc5d3ac..8cb8368 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -116,10 +116,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, mdm_ick, mdm_ick, CK_243X),
CLK(NULL, mdm_osc_ck, mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK(omapfb, ick, dss_ick, CK_243X | CK_242X),
- CLK(omapfb, dss1_fck, dss1_fck, CK_243X | CK_242X),
- CLK(omapfb, dss2_fck, dss2_fck, CK_243X | CK_242X),
- CLK(omapfb, tv_fck, dss_54m_fck, CK_243X | CK_242X),
+ CLK(omapdss, ick, dss_ick, CK_243X | CK_242X),
+ CLK(omapdss, dss1_fck, dss1_fck, CK_243X | CK_242X),
+ CLK(omapdss, dss2_fck, dss2_fck, CK_243X | CK_242X),
+ CLK(omapdss, tv_fck, dss_54m_fck, CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_243X | CK_242X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index fafcd32..1fa91e4 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -236,13 +236,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_343X),
CLK(NULL, sha11_ick,sha11_ick, CK_343X),
CLK(NULL, des1_ick, des1_ick, CK_343X),
- CLK(omapfb, dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
- CLK(omapfb, dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2),
- CLK(omapfb, tv_fck, dss_tv_fck,CK_343X),
- CLK(omapfb, video_fck,dss_96m_fck, CK_343X),
- CLK(omapfb, dss2_fck, dss2_alwon_fck, CK_343X),
- CLK(omapfb, ick, dss_ick_3430es1, CK_3430ES1),
- CLK(omapfb, ick, dss_ick_3430es2, CK_3430ES2),
+ CLK(omapdss, dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
+ CLK(omapdss, dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2),
+ CLK(omapdss, tv_fck, dss_tv_fck,CK_343X),
+ CLK(omapdss, video_fck,dss_96m_fck, CK_343X),
+ CLK(omapdss, dss2_fck, dss2_alwon_fck, CK_343X),
+ CLK(omapdss, ick, dss_ick_3430es1, CK_3430ES1),
+ CLK(omapdss, ick, dss_ick_3430es2, CK_3430ES2),
CLK(NULL, cam_mclk, cam_mclk, CK_343X),
CLK(NULL, cam_ick, cam_ick, CK_343X),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 66e57df..9edfb15 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -24,6 +24,7 @@
#include linux/vmalloc.h
#include linux/clk.h
#include linux/io.h
+#include linux/platform_device.h
#include mach/sram.h
#include mach/board.h
@@ -188,6 +189,11 @@ static struct {
struct omapfb_color_key color_key;
} dispc;
+static struct platform_device omapdss_device = {
+ .name = omapdss,
+ .id = -1,
+};
+
static void enable_lcd_clocks(int enable);
static void inline dispc_write_reg(int idx, u32 val)
@@ -907,20 +913,20 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
static int get_dss_clocks(void)
{
- dispc.dss_ick = clk_get(dispc.fbdev-dev, ick);
+ dispc.dss_ick = clk_get(omapdss_device.dev, ick);
if (IS_ERR(dispc.dss_ick)) {
dev_err(dispc.fbdev-dev, can't get ick\n);
return PTR_ERR(dispc.dss_ick);
}
- dispc.dss1_fck = clk_get(dispc.fbdev-dev, dss1_fck);
+ dispc.dss1_fck = clk_get(omapdss_device.dev, dss1_fck);
if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev-dev, can't get dss1_fck\n);
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
- dispc.dss_54m_fck = clk_get(dispc.fbdev-dev, tv_fck);
+ dispc.dss_54m_fck = clk_get(omapdss_device.dev, tv_fck);
if (IS_ERR(dispc.dss_54m_fck)) {
dev_err(dispc.fbdev-dev, can't get tv_fck\n);
[PATCH 06/19] OMAP: DSS2: Documentation for DSS2
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- Documentation/arm/OMAP/DSS | 317 1 files changed, 317 insertions(+), 0 deletions(-) create mode 100644 Documentation/arm/OMAP/DSS diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS new file mode 100644 index 000..0af0e9e --- /dev/null +++ b/Documentation/arm/OMAP/DSS @@ -0,0 +1,317 @@ +OMAP2/3 Display Subsystem +- + +This is an almost total rewrite of the OMAP FB driver in drivers/video/omap +(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, +TV-out and multiple display support, but there are lots of small improvements +also. + +The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB, +panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live +currently side by side, you can choose which one to use. + +Features + + +Working and tested features include: + +- MIPI DPI (parallel) output +- MIPI DSI output in command mode +- MIPI DBI (RFBI) output +- SDI output +- TV output +- All pieces can be compiled as a module or inside kernel +- Use DISPC to update any of the outputs +- Use CPU to update RFBI or DSI output +- OMAP DISPC planes +- RGB16, RGB24 packed, RGB24 unpacked +- YUV2, UYVY +- Scaling +- Adjusting DSS FCK to find a good pixel clock +- Use DSI DPLL to create DSS FCK + +Tested boards include: +- OMAP3 SDP board +- Beagle board +- N810 + +omapdss driver +-- + +The DSS driver does not itself have any support for Linux framebuffer, V4L or +such like the current ones, but it has an internal kernel API that upper level +drivers can use. + +The DSS driver models OMAP's overlays, overlay managers and displays in a +flexible way to enable non-common multi-display configuration. In addition to +modelling the hardware overlays, omapdss supports virtual overlays and overlay +managers. These can be used when updating a display with CPU or system DMA. + +Panel and controller drivers + + +The drivers implement panel or controller specific functionality and are not +usually visible to users except through omapfb driver. They register +themselves to the DSS driver. + +omapfb driver +- + +The omapfb driver implements arbitrary number of standard linux framebuffers. +These framebuffers can be routed flexibly to any overlays, thus allowing very +dynamic display architecture. + +The driver exports some omapfb specific ioctls, which are compatible with the +ioctls in the old driver. + +The rest of the non standard features are exported via sysfs. Whether the final +implementation will use sysfs, or ioctls, is still open. + +V4L2 drivers + + +V4L2 is being implemented in TI. + +From omapdss point of view the V4L2 drivers should be similar to framebuffer +driver. + +Architecture + + +Some clarification what the different components do: + +- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the + pixel data for the image. Framebuffer has width and height and color + depth. +- Overlay defines where the pixels are read from and where they go on the + screen. The overlay may be smaller than framebuffer, thus displaying only + part of the framebuffer. The position of the overlay may be changed if + the overlay is smaller than the display. +- Overlay manager combines the overlays in to one image and feeds them to + display. +- Display is the actual physical display device. + +A framebuffer can be connected to multiple overlays to show the same pixel data +on all of the overlays. Note that in this case the overlay input sizes must be +the same, but, in case of video overlays, the output size can be different. Any +framebuffer can be connected to any overlay. + +An overlay can be connected to one overlay manager. Also DISPC overlays can be +connected only to DISPC overlay managers, and virtual overlays can be only +connected to virtual overlays. + +An overlay manager can be connected to one display. There are certain +restrictions which kinds of displays an overlay manager can be connected: + +- DISPC TV overlay manager can be only connected to TV display. +- Virtual overlay managers can only be connected to DBI or DSI displays. +- DISPC LCD overlay manager can be connected to all displays, except TV + display. + +Sysfs +- +The sysfs interface is mainly used for testing. I don't think sysfs +interface is the best for this in the final version, but I don't quite know +what would be the best interfaces for these things. + +The sysfs interface is divided to two parts: DSS and FB. + +/sys/class/graphics/fb? directory: +mirror 0=off, 1=on +rotate Rotation 0-3 for 0, 90, 180, 270 degrees +rotate_type0 = DMA rotation, 1 = VRFB rotation +overlays List of overlay numbers to which framebuffer pixels go +phys_addr Physical
[PATCH 00/19] OMAP: DSS2: Intro
This patch set implement new display subsystem driver (DSS2) and omapfb driver for OMAP2/3. The patches have been reviewed on linux-omap and linux-fbdev-devel mailing lists. The patches can also be found from http://gitorious.org/linux-omap-dss2/linux The patches include DSS documentation patch that includes more instructions for module parameters, sysfs files etc. The patches enable DSS2 for OMAP3430 SDP board and support for other boards can be sent after the DSS2 has been merged. DSS2 is used in various boards, for example Nokia N900, Beagle Board and Overo. I don't currently have any OMAP2 board to test DSS2, but it has worked on OMAP2 and the possible fixes needed should be minimal. OMAP1 is not supported, and so the old DSS needs to be used on OMAP1 boards. DSS2 is partly based on the old omapfb driver by Imre Deak, and Imre has also contributed to DSS2 quite a bit. Ville Syrjälä has been contributing to scaling and tv-out work. Also some contributions have been made by Hardik Shah, Vaibhav Hiremath, and perhaps some others that I have forgotten =). --- Changes in v4: - Rebased on latest linux tree - Add maintainers Changes in v3: - Rebased on mainstream linux - Remove Beagle and Overo board changes Changes in v2: - Split the commits more to make them smaller - Print error if fclk is too low for scaling - Indent SDP, Beagle, Overo board files - DSI: return -EIO instead of -1 - VRFB: Move to drivers/video/omap2/ - VRAM: Move to drivers/video/omap2/ - VRFB: use omap2_sms_write_*() functions instead of omap_writel - SDI: Remove custom pinmuxing. Will be added later properly. - VENC: indentation changes - Add Taal DSI panel driver --- [PATCH 01/19] OMAP2: Add funcs for writing SMS_ROT_* registers [PATCH 02/19] OMAP: OMAPFB: split omapfb.h [PATCH 03/19] OMAP: OMAPFB: add omapdss device [PATCH 04/19] OMAP: Add VRAM manager [PATCH 05/19] OMAP: Add support for VRFB rotation engine [PATCH 06/19] OMAP: DSS2: Documentation for DSS2 [PATCH 07/19] OMAP: DSS2: Display Subsystem Driver core [PATCH 08/19] OMAP: DSS2: Add more core files [PATCH 09/19] OMAP: DSS2: DISPC [PATCH 10/19] OMAP: DSS2: DPI driver [PATCH 11/19] OMAP: DSS2: Video encoder driver [PATCH 12/19] OMAP: DSS2: RFBI driver [PATCH 13/19] OMAP: DSS2: SDI driver [PATCH 14/19] OMAP: DSS2: DSI driver [PATCH 15/19] OMAP: DSS2: omapfb driver [PATCH 16/19] OMAP: DSS2: Add DPI panel drivers [PATCH 17/19] OMAP: DSS2: Taal DSI command mode panel driver [PATCH 18/19] OMAP: SDP: Enable DSS2 for OMAP3 SDP board [PATCH 19/19] MAINTAINERS: Add OMAP2/3 DSS and OMAPFB maintainer --- Documentation/arm/OMAP/DSS | 317 ++ MAINTAINERS| 17 + arch/arm/configs/omap_3430sdp_defconfig| 29 +- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-3430sdp.c| 167 +- arch/arm/mach-omap2/clock24xx.c|8 +- arch/arm/mach-omap2/clock34xx.c| 14 +- arch/arm/mach-omap2/io.c |4 +- arch/arm/mach-omap2/sdrc.c | 16 + arch/arm/plat-omap/fb.c| 41 +- arch/arm/plat-omap/include/mach/display.h | 540 +++ arch/arm/plat-omap/include/mach/omapfb.h | 398 --- arch/arm/plat-omap/include/mach/sdrc.h |9 +- arch/arm/plat-omap/include/mach/vram.h | 63 + arch/arm/plat-omap/include/mach/vrfb.h | 46 + arch/arm/plat-omap/sram.c |8 + drivers/video/Kconfig |1 + drivers/video/Makefile |1 + drivers/video/omap/Kconfig |5 +- drivers/video/omap/blizzard.c |2 +- drivers/video/omap/dispc.c | 21 +- drivers/video/omap/hwa742.c|2 +- drivers/video/omap/lcd_2430sdp.c |3 +- drivers/video/omap/lcd_ams_delta.c |3 +- drivers/video/omap/lcd_apollon.c |3 +- drivers/video/omap/lcd_h3.c|2 +- drivers/video/omap/lcd_h4.c|2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |3 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c |3 +- drivers/video/omap/lcd_omap3beagle.c |3 +- drivers/video/omap/lcd_omap3evm.c |3 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c|2 +- drivers/video/omap/lcd_palmtt.c|2 +- drivers/video/omap/lcd_palmz71.c |2 +-
[PATCH 11/19] OMAP: DSS2: Video encoder driver
VENC (video encoder) driver implements OMAP's analog S-Video/Composite
TV-out.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/video/omap2/dss/venc.c | 797
1 files changed, 797 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/venc.c
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
new file mode 100644
index 000..cf7827e
--- /dev/null
+++ b/drivers/video/omap2/dss/venc.c
@@ -0,0 +1,797 @@
+/*
+ * linux/drivers/video/omap2/dss/venc.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * VENC settings from TI's DSS driver
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME VENC
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/string.h
+#include linux/seq_file.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+
+#include mach/display.h
+#include mach/cpu.h
+
+#include dss.h
+
+#define VENC_BASE 0x48050C00
+
+/* Venc registers */
+#define VENC_REV_ID0x00
+#define VENC_STATUS0x04
+#define VENC_F_CONTROL 0x08
+#define VENC_VIDOUT_CTRL 0x10
+#define VENC_SYNC_CTRL 0x14
+#define VENC_LLEN 0x1C
+#define VENC_FLENS 0x20
+#define VENC_HFLTR_CTRL0x24
+#define VENC_CC_CARR_WSS_CARR 0x28
+#define VENC_C_PHASE 0x2C
+#define VENC_GAIN_U0x30
+#define VENC_GAIN_V0x34
+#define VENC_GAIN_Y0x38
+#define VENC_BLACK_LEVEL 0x3C
+#define VENC_BLANK_LEVEL 0x40
+#define VENC_X_COLOR 0x44
+#define VENC_M_CONTROL 0x48
+#define VENC_BSTAMP_WSS_DATA 0x4C
+#define VENC_S_CARR0x50
+#define VENC_LINE210x54
+#define VENC_LN_SEL0x58
+#define VENC_L21__WC_CTL 0x5C
+#define VENC_HTRIGGER_VTRIGGER 0x60
+#define VENC_SAVID__EAVID 0x64
+#define VENC_FLEN__FAL 0x68
+#define VENC_LAL__PHASE_RESET 0x6C
+#define VENC_HS_INT_START_STOP_X 0x70
+#define VENC_HS_EXT_START_STOP_X 0x74
+#define VENC_VS_INT_START_X0x78
+#define VENC_VS_INT_STOP_X__VS_INT_START_Y 0x7C
+#define VENC_VS_INT_STOP_Y__VS_EXT_START_X 0x80
+#define VENC_VS_EXT_STOP_X__VS_EXT_START_Y 0x84
+#define VENC_VS_EXT_STOP_Y 0x88
+#define VENC_AVID_START_STOP_X 0x90
+#define VENC_AVID_START_STOP_Y 0x94
+#define VENC_FID_INT_START_X__FID_INT_START_Y 0xA0
+#define VENC_FID_INT_OFFSET_Y__FID_EXT_START_X 0xA4
+#define VENC_FID_EXT_START_Y__FID_EXT_OFFSET_Y 0xA8
+#define VENC_TVDETGP_INT_START_STOP_X 0xB0
+#define VENC_TVDETGP_INT_START_STOP_Y 0xB4
+#define VENC_GEN_CTRL 0xB8
+#define VENC_OUTPUT_CONTROL0xC4
+#define VENC_OUTPUT_TEST 0xC8
+#define VENC_DAC_B__DAC_C 0xC8
+
+struct venc_config {
+ u32 f_control;
+ u32 vidout_ctrl;
+ u32 sync_ctrl;
+ u32 llen;
+ u32 flens;
+ u32 hfltr_ctrl;
+ u32 cc_carr_wss_carr;
+ u32 c_phase;
+ u32 gain_u;
+ u32 gain_v;
+ u32 gain_y;
+ u32 black_level;
+ u32 blank_level;
+ u32 x_color;
+ u32 m_control;
+ u32 bstamp_wss_data;
+ u32 s_carr;
+ u32 line21;
+ u32 ln_sel;
+ u32 l21__wc_ctl;
+ u32 htrigger_vtrigger;
+ u32 savid__eavid;
+ u32 flen__fal;
+ u32 lal__phase_reset;
+ u32 hs_int_start_stop_x;
+ u32 hs_ext_start_stop_x;
+ u32 vs_int_start_x;
+ u32 vs_int_stop_x__vs_int_start_y;
+ u32 vs_int_stop_y__vs_ext_start_x;
+ u32 vs_ext_stop_x__vs_ext_start_y;
+ u32 vs_ext_stop_y;
+
[PATCH] omap3: ehci: remove chargepump hack
omap3: ehci: remove chargepump hack
This hack was for a very early development board that is no longer
in use. Remove it. No board should require it.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 5f913c3..5571f44 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -486,7 +486,6 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .chargepump = true,
.phy_reset = true,
.reset_gpio_port[0] = 57,
.reset_gpio_port[1] = 61,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index aa403e6..f81141f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -406,7 +406,6 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .chargepump = false,
.phy_reset = true,
.reset_gpio_port[0] = -EINVAL,
.reset_gpio_port[1] = 147,
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 62a6f32..a2fcd06 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -299,7 +299,6 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .chargepump = false,
.phy_reset = true,
.reset_gpio_port[0] = -EINVAL,
.reset_gpio_port[1] = 135,
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 9f115dc..fd4a951 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -389,7 +389,6 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .chargepump = false,
.phy_reset = true,
.reset_gpio_port[0] = 16,
.reset_gpio_port[1] = -EINVAL,
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index d16172d..46e376f 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -389,7 +389,6 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .chargepump = false,
.phy_reset = true,
.reset_gpio_port[0] = -EINVAL,
.reset_gpio_port[1] = OVERO_GPIO_USBH_NRESET,
diff --git a/arch/arm/plat-omap/include/mach/usb.h
b/arch/arm/plat-omap/include/mach/usb.h
index d1b14cc..a4068a4 100644
--- a/arch/arm/plat-omap/include/mach/usb.h
+++ b/arch/arm/plat-omap/include/mach/usb.h
@@ -14,7 +14,6 @@ enum ehci_hcd_omap_mode {
struct ehci_hcd_omap_platform_data {
enum ehci_hcd_omap_mode port_mode[OMAP3_HS_USB_PORTS];
- unsignedchargepump:1;
unsignedphy_reset:1;
/* have to be valid if phy_reset is true and portx is in phy mode */
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 36fb183..f2771cf 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -169,9 +169,6 @@ struct ehci_hcd_omap {
/* phy reset workaround */
int phy_reset;
- /* vbus internal chargepump workaround */
- int chargepump;
-
/* desired phy_mode: TLL, PHY */
enum ehci_hcd_omap_mode port_mode[OMAP3_HS_USB_PORTS];
@@ -423,25 +420,6 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
gpio_set_value(omap-reset_gpio_port[1], 1);
}
- if (omap-chargepump) {
-
- /* Refer ISSUE2: LINK assumes external charge pump */
-
- /* use Port1 VBUS to charge externally Port2:
-* So for PHY mode operation use Port2 only
-*/
- ehci_omap_writel(omap-ehci_base, EHCI_INSNREG05_ULPI,
- /* OTG ctrl reg*/
- (0xa EHCI_INSNREG05_ULPI_REGADD_SHIFT) |
- /* Write */
- (2 EHCI_INSNREG05_ULPI_OPSEL_SHIFT) |
- /* Port1 */
- (1 EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) |
- /* Start */
- (1 EHCI_INSNREG05_ULPI_CONTROL_SHIFT) |
- (0x26));
- }
-
return 0;
err_sys_status:
--
Re: [PATCH] omap3: ehci: remove chargepump hack
On Thu, Sep 24, 2009 at 02:06:57PM +0200, ext Anand Gadiyar wrote: omap3: ehci: remove chargepump hack This hack was for a very early development board that is no longer in use. Remove it. No board should require it. do we have anyone using it besides development boards ? -- balbi -- 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] omap3: ehci: remove chargepump hack
On Thu, Sep 24, 2009 at 02:19:52PM +0200, ext Gadiyar, Anand wrote: On Thu, Sep 24, 2009 at 02:06:57PM +0200, ext Anand Gadiyar wrote: omap3: ehci: remove chargepump hack This hack was for a very early development board that is no longer in use. Remove it. No board should require it. do we have anyone using it besides development boards ? Not sure I understand the question. If you meant is anyone other than development boards using the chargepump hack, then the short answer is no. The chargepump hack was only for one particular reference design board - the very first version of it. Only 6-odd boards were made which needed that hack. It's long gone from internal codebases, as are the boards. As far as I know, no board in the wild will need it. If you look at the patch, only the 3430 SDP board set this flag to true, and all others were false. I confirm that all later versions of the expansion board in use with the 3430SDP do not require this hack. So there's no point having it around. good, so: Acked-by: Felipe Balbi felipe.ba...@nokia.com -- balbi -- 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: [OMAP3] ALSA driver 'suspend/resume' handlers
-Original Message- From: Shilimkar, Santosh Sent: Thursday, September 24, 2009 2:24 AM To: Jarkko Nikula; hari n Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: RE: [OMAP3] ALSA driver 'suspend/resume' handlers Hari/Jarkko, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Thursday, September 24, 2009 12:16 PM To: hari n Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [OMAP3] ALSA driver 'suspend/resume' handlers On Wed, 23 Sep 2009 00:02:01 -0500 hari n hari.z...@gmail.com wrote: It appears OMAP ALSA driver does not seem to disable and idle the SDMA channel on a 'suspend' call. The problem seems to be with the 'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in 'omap_pcm_trigger()'. ALSA audio driver uses self linking and the function 'omap_stop_dma()', only unlinks the channels, but DOES NOT disable an active channel for linked channels. Good finding, definitely I was expecting that it will stop the transfer. I worder what's the background for current omap_stop_dma implementation? I would expect that omap_stop_dma would just stop the logical channel without touching the channel linking etc. as there is own API for chained transfers and thus omap_stop_dma could be used for non-chained transfers or 'hacking' with chained transfers. This means after a return from the 'omap_stop_dma()', there can still be an active DMA transaction on the channel. Is this the intent Or a bug? I can think of situations, where in, we may want to complete the DMA transfer and then disable the channel. In such a case, we need to wait until the channel is inactive. I don't know, probably there is no driver expecting that transfer will complete after the omap_stop_dma is called or they explicitly do some PIO based FIFO flush for their devices? The problem with the current implementation is that after the audio platform trigger (suspend) is called, SOC core calls the CPU DAI trigger (suspend) and this stops the McBSP. Depending on the current DMA pointer, this may leave the DMA channel in active state, since DMA is configured for DEST HW Synchronization and and the this never gets asserted after the McBSP is stopped.. This is true. Then the question is will the operation recover after the stream is resumed and after the low-level dma and mcbsp contexts are restored and operation started again. I see two ways to resolve this issue: a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend) until the DMA channel is inactive (i.e buffer transfer complete). But, i believe 'trigger' is supposed to be an atomic operation, so we may need to wait in a worker thread. And we need to flag the McBSP stop based on DMA transfer completion. b) Explicitly disable the DMA channel in 'omap_stop_dma(). Option 'b' above may mean losing some data on resume, if we hit 'OFF' state during suspend. This may not be a big deal for audio (loss of few secs audio), but for other drivers (ex: USB data file transfer?), this may not be acceptable. 'Option 'a' means more rework in audio driver, but no changes in DAM driver and no loss of data. Yeah, trigger callback is atomic and can be called from the interrupt context as well. Option 'a' doesn't help losing of audio samples since the soc-core is first muting the codec. Current Audio driver also does not seem to support 'OFF' mode during suspend. It seems to assume that all DMA and McBSP configurations are retained in a suspend to resume transition. It's true, this has not got so much attention. I think I was expecting that low-level mcbsp and dma modules will take care of their context back-up and restore and that's enough for audio as long as audio will inform those modules with _start/_stop calls. I don't see any problem if suspend and resume callbacks are added into omap-pcm.c and omap-mcbsp.c calling e.g. omap_mcbsp_config if needed. omap_stop_dma() should be issued when we really want to stop the DMA transfer and issuing this with an outstanding transfer is a BUG in ALSA driver. Having said that, there is also bug in the DMA driver which doesn't disable the channel in linking cases. Since we use always hardware synchronized method, hardware will take care of draining the buffer so no loss of data. So option B should be ok and USB case also would work as mentioned above. USB is not a valid use case to discuss here. Mentor OTG controller has its internal DMA and so does EHCI/OHCI host controller. USB on OMAP3 _does_not_ use system DMA. Regrads Santosh -- 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
Any Nokia N900 support planning?
Hi guys, I would like to buy a N900 as it will became available. Is there any plan to support it with linux-omap? Is there someone already working on it? In case I would like to help :) Thanks, Stefano -- Stefano Panella, Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692452 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- 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: Build break on mainline tree for 3430 SDP
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Thursday, September 24, 2009 6:08 AM To: linux-omap@vger.kernel.org Subject: Build break on mainline tree for 3430 SDP Build break compiling Linus' git tree for 3430 SDP. I get this with the default SDP config. Haven't looked at the code yet to find a fix. - Anand CC arch/arm/mach-omap2/board-3430sdp.o In file included from arch/arm/mach-omap2/board-3430sdp.c:41: arch/arm/plat-omap/include/mach/keypad.h:38:1: warning: KEY redefined In file included from include/linux/i2c/twl4030.h:29, from arch/arm/mach-omap2/board-3430sdp.c:22: include/linux/input/matrix_keypad.h:10:1: warning: this is the location of the previous definition In file included from arch/arm/mach-omap2/board-3430sdp.c:41: arch/arm/plat-omap/include/mach/keypad.h:39:1: warning: PERSISTENT_KEY redefined In file included from arch/arm/mach-omap2/board-3430sdp.c:22: include/linux/i2c/twl4030.h:356:1: warning: this is the location of the previous definition arch/arm/mach-omap2/board-3430sdp.c:94: error: unknown field 'keymap' specified in initializer arch/arm/mach-omap2/board-3430sdp.c:94: warning: the address of 'sdp3430_keymap' will always evaluate as 'true' arch/arm/mach-omap2/board-3430sdp.c:95: error: unknown field 'keymapsize' specified in initializer arch/arm/mach-omap2/board-3430sdp.c:95: warning: excess elements in struct initializer arch/arm/mach-omap2/board-3430sdp.c:95: warning: (near initialization for 'sdp3430_kp_data') make[1]: *** [arch/arm/mach-omap2/board-3430sdp.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Linus tree has more up-to-date commit on include/linux/i2c/twl4030.h That changes the keymap interface. const struct matrix_keymap_data *keymap_data; See the highlighted line below. All boards may have to adapt to the new keymap interface. commit 9d8340687c524ce61e3c9c76758c4c81303acfc0 Author: David Brownell dbrown...@users.sourceforge.net Date: Tue Aug 25 19:24:14 2009 -0700 Input: add twl4030_keypad driver Add a driver for the keypad controller on TWL4030 family chips. These support up to an 8x8 key matrix. The TWL4030 multifunction chips are mostly used on OMAP3 (or OMAP 2430) based boards. [d...@mail.ru: switch to matrix-keypad framework, fix changing keymap from userspace] Reviewed-by: Trilok Soni soni.tri...@gmail.com Signed-off-by: David Brownell dbrown...@users.sourceforge.net Signed-off-by: Dmitry Torokhov d...@mail.ru -- 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 -- 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: Any Nokia N900 support planning?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Stefano Panella Sent: Thursday, September 24, 2009 8:23 AM To: linux-omap@vger.kernel.org Subject: Any Nokia N900 support planning? Hi guys, I would like to buy a N900 as it will became available. Is there any plan to support it with linux-omap? I thought Rx51 board supported on linux-omap is N900 !! Is there someone already working on it? In case I would like to help :) Thanks, Stefano -- Stefano Panella, Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692452 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- 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 -- 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 8/10] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
Hi Russell,
-Original Message-
From: Russell King [mailto:r...@arm.linux.org.uk]
Sent: Wednesday, September 23, 2009 3:26 PM
To: C.A, Subramaniam
Cc: linux-omap@vger.kernel.org; Hiroshi DOYU;
t...@atomide.com; Kanigeri, Hari; Gupta, Ramesh
Subject: Re: [PATCH 8/10] omap mailbox: OMAP4-Mailbox - Adds
code changes to support OMAP4 mailbox.
On Tue, Sep 22, 2009 at 08:03:32PM +0530, C.A, Subramaniam wrote:
@@ -70,10 +88,9 @@ static inline void mbox_write_reg(u32
val, size_t ofs)
static int omap2_mbox_startup(struct omap_mbox *mbox)
{
unsigned int l;
-
mbox_ick_handle = clk_get(NULL, mailboxes_ick);
if (IS_ERR(mbox_ick_handle)) {
- printk(Could not get mailboxes_ick\n);
+ printk(KERN_ERR Could not get mailboxes_ick\n);
return -ENODEV;
Good idea: Print the error code so people can diagnose why
things fail.
printk(KERN_ERR Could not get mailboxes_ick: %d\n,
PTR_ERR(mbox_ick_handle));
And wonder why this hasn't been spotted before.
Rule: always propagate error codes when you have one to propagate.
return PTR_ERR(mbox_ick_handle);
Thank you for your comments. I will send a revised patch.
Regards
Subbu--
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 8/10 v3] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
Hi all,
This is the revised version of the patch incorporating Russell's comments.
Regards
Subbu
From 0c7c506f0a47acc8444bed83fa56ad2aa76c3b7c Mon Sep 17 00:00:00 2001
From: C A Subramaniam subramaniam...@ti.com
Date: Thu, 24 Sep 2009 19:16:39 +0530
Subject: [PATCH 8/10 v3] omap mailbox: OMAP4-Mailbox - Adds code changes to
support OMAP4 mailbox.
This patch adds code changes in the mailbox driver module to
add support for OMAP4 mailbox.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: C A Subramaniam subramaniam...@ti.com
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 123 +++--
arch/arm/plat-omap/mailbox.c | 25 +++--
2 files changed, 125 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 6f71f37..fee4ee7 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -18,21 +18,36 @@
#include mach/mailbox.h
#include mach/irqs.h
+#define DRV_NAME omap2-mailbox
+
#define MAILBOX_REVISION 0x000
#define MAILBOX_SYSCONFIG 0x010
#define MAILBOX_SYSSTATUS 0x014
#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
#define MAILBOX_FIFOSTATUS(m) (0x080 + 4 * (m))
#define MAILBOX_MSGSTATUS(m) (0x0c0 + 4 * (m))
+
+#ifdef CONFIG_ARCH_OMAP4
+#define MAILBOX_IRQSTATUS(u) (0x104 + 10 * (u))
+#define MAILBOX_IRQENABLE(u) (0x108 + 10 * (u))
+#define MAILBOX_IRQENABLE_CLR(u) (0x10c + 10 * (u))
+#else
#define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u))
#define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u))
+#endif
-#define MAILBOX_IRQ_NEWMSG(u) (1 (2 * (u)))
-#define MAILBOX_IRQ_NOTFULL(u) (1 (2 * (u) + 1))
+#define MAILBOX_IRQ_NEWMSG(m) (1 (2 * (m)))
+#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1))
+#ifdef CONFIG_ARCH_OMAP4
+#define MBOX_REG_SIZE 0x130
+#else
#define MBOX_REG_SIZE 0x120
+#endif
+
#define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32))
+
static void __iomem *mbox_base;
struct omap_mbox2_fifo {
@@ -49,6 +64,9 @@ struct omap_mbox2_priv {
u32 newmsg_bit;
u32 notfull_bit;
u32 ctx[MBOX_NR_REGS];
+#ifdef CONFIG_ARCH_OMAP4
+ unsigned long irqdisable;
+#endif
};
static struct clk *mbox_ick_handle;
@@ -70,11 +88,11 @@ static inline void mbox_write_reg(u32 val, size_t ofs)
static int omap2_mbox_startup(struct omap_mbox *mbox)
{
unsigned int l;
-
mbox_ick_handle = clk_get(NULL, mailboxes_ick);
if (IS_ERR(mbox_ick_handle)) {
- printk(Could not get mailboxes_ick\n);
- return -ENODEV;
+ printk(KERN_ERR Could not get mailboxes_ick: %d\n,
+ PTR_ERR(mbox_ick_handle));
+ return PTR_ERR(mbox_ick_handle);
}
clk_enable(mbox_ick_handle);
@@ -85,7 +103,6 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
l = mbox_read_reg(MAILBOX_SYSCONFIG);
l |= 0x0011;
mbox_write_reg(l, MAILBOX_SYSCONFIG);
-
omap2_mbox_enable_irq(mbox, IRQ_RX);
return 0;
@@ -95,6 +112,7 @@ static void omap2_mbox_shutdown(struct omap_mbox *mbox)
{
clk_disable(mbox_ick_handle);
clk_put(mbox_ick_handle);
+ mbox_ick_handle = NULL;
}
/* Mailbox FIFO handle functions */
@@ -123,7 +141,7 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
{
struct omap_mbox2_fifo *fifo =
((struct omap_mbox2_priv *)mbox-priv)-tx_fifo;
- return (mbox_read_reg(fifo-fifo_stat));
+ return mbox_read_reg(fifo-fifo_stat);
}
/* Mailbox IRQ handle functions */
@@ -143,10 +161,9 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
{
struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv;
u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
-
- l = mbox_read_reg(p-irqenable);
+ l = mbox_read_reg(p-irqdisable);
l = ~bit;
- mbox_write_reg(l, p-irqenable);
+ mbox_write_reg(l, p-irqdisable);
}
static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
@@ -156,6 +173,8 @@ static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
mbox_write_reg(bit, p-irqstatus);
+ /* Flush post writing */
+mbox_read_reg(p-irqstatus);
}
static int omap2_mbox_is_irq(struct omap_mbox *mbox,
@@ -166,7 +185,7 @@ static int omap2_mbox_is_irq(struct omap_mbox *mbox,
u32 enable = mbox_read_reg(p-irqenable);
u32 status = mbox_read_reg(p-irqstatus);
- return (enable status bit);
+ return (int)(enable status bit);
}
static void omap2_mbox_save_ctx(struct omap_mbox *mbox)
@@ -219,9 +238,12 @@ static struct omap_mbox_ops omap2_mbox_ops = {
*/
/* FIXME: the following
From: Sanjeev Premi pr...@ti.com
Currently there are multiple mechanisms for identifying silicon revisions. Most places the comparison is against omap_rev() as a whole number. This patch implements the comparison against the omap_revision bits alone. This makes the test independent of silicon in use. This patch doesn't remove all existing mechanisms for the check to maintain stability. The migration can follow in phases. [1] http://marc.info/?l=linux-omapm=125197467922935w=2 Sanjeev Premi (1): OMAP3: Common mechanism to identify cpu revision arch/arm/mach-omap2/clock34xx.c |4 +- arch/arm/mach-omap2/control.c |6 ++-- arch/arm/mach-omap2/pm34xx.c | 17 +- arch/arm/plat-omap/include/mach/cpu.h | 55 + 4 files changed, 69 insertions(+), 13 deletions(-) -- 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/1] OMAP3: Common mechanism to identify cpu revision
There are multiple mechanisms to identify the cpu revisions.
Most common is use of omap_rev(). This, however, does a
absolute comparison of omap_revision - which includes
CPU id, CPU rev and CPU class. This comparison fails for
OMAP35x processors.
This patch defines generic functions that use only the
CPU rev bits in omap_revision to identify the revision
information.
Usage will change from (for example):
if (omap_rev() OMAP3430_REV_ES2_0)
to:
if (cpu_is_omap34xx() omap_rev_gt_2_0())
Specific check for cpu_is_xxx() will not be needed for
files specific to silicon e.g. pm34xx.c, clock34xx.c, etc.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/clock34xx.c |4 +-
arch/arm/mach-omap2/control.c |6 ++--
arch/arm/mach-omap2/pm34xx.c | 17 +-
arch/arm/plat-omap/include/mach/cpu.h | 55 +
4 files changed, 69 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index e0df0ce..074c593 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -815,7 +815,7 @@ static int omap3_dpll4_set_rate(struct clk *clk, unsigned
long rate)
* on 3430ES1 prevents us from changing DPLL multipliers or dividers
* on DPLL4.
*/
- if (omap_rev() == OMAP3430_REV_ES1_0) {
+ if (omap_rev_is_1_0()) {
printk(KERN_ERR clock: DPLL4 cannot change rate due to
silicon 'Limitation 2.5' on 3430ES1.\n);
return -EINVAL;
@@ -1157,7 +1157,7 @@ int __init omap2_clk_init(void)
* Update this if there are further clock changes between ES2
* and production parts
*/
- if (omap_rev() == OMAP3430_REV_ES1_0) {
+ if (omap_rev_is_1_0()) {
/* No 3430ES1-only rates exist, so no RATE_IN_3430ES1 */
cpu_clkflg |= CK_3430ES1;
} else {
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index c9407c0..089e714 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -209,8 +209,8 @@ void omap3_save_scratchpad_contents(void)
/* Populate the Scratchpad contents */
scratchpad_contents.boot_config_ptr = 0x0;
- if (omap_rev() != OMAP3430_REV_ES3_0
- omap_rev() != OMAP3430_REV_ES3_1)
+ if (cpu_is_omap34xx()
+!omap_rev_is_3_0() !omap_rev_is_3_1())
scratchpad_contents.public_restore_ptr =
virt_to_phys(get_restore_pointer());
else
@@ -271,7 +271,7 @@ void omap3_save_scratchpad_contents(void)
* of AUTO_CNT = 1 prior to any transition to OFF mode.
*/
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
-(omap_rev() = OMAP3430_REV_ES3_0))
+cpu_is_omap34xx() omap_rev_ge_3_0())
sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER)
~(SDRC_POWER_AUTOCOUNT_MASK|
SDRC_POWER_CLKCTRL_MASK)) |
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c1d58a7..7a1eb95 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,6 +28,7 @@
#include linux/clk.h
#include linux/usb/musb.h
+#include mach/cpu.h
#include mach/sram.h
#include mach/prcm.h
#include mach/clockdomain.h
@@ -108,7 +109,7 @@ static void omap3_enable_io_chain(void)
{
int timeout = 0;
- if (omap_rev() = OMAP3430_REV_ES3_1) {
+ if (omap_rev_ge_3_1()) {
prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN, WKUP_MOD, PM_WKEN);
/* Do a readback to assure write has been done */
prm_read_mod_reg(WKUP_MOD, PM_WKEN);
@@ -129,7 +130,7 @@ static void omap3_enable_io_chain(void)
static void omap3_disable_io_chain(void)
{
- if (omap_rev() = OMAP3430_REV_ES3_1)
+ if (omap_rev_ge_3_1())
prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN, WKUP_MOD, PM_WKEN);
}
@@ -248,7 +249,7 @@ static int _prcm_int_handle_wakeup(void)
c = prcm_clear_mod_irqs(WKUP_MOD, 1);
c += prcm_clear_mod_irqs(CORE_MOD, 1);
c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
- if (omap_rev() OMAP3430_REV_ES1_0) {
+ if (omap_rev_gt_1_0()) {
c += prcm_clear_mod_irqs(CORE_MOD, 3);
c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
}
@@ -432,7 +433,7 @@ void omap_sram_idle(void)
* of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
* Hence store/restore the SDRC_POWER register here.
*/
- if (omap_rev() = OMAP3430_REV_ES3_0
+ if (omap_rev_ge_3_0()
omap_type() != OMAP2_DEVICE_TYPE_GP
core_next_state == PWRDM_POWER_OFF)
sdrc_pwr =
Re: [PATCH] video: omap2: dss: RET on idle, enable/disable dss clocks only when needed.
Tomi Valkeinen wrote: On Wed, 2009-09-23 at 17:44 +0200, ext Kevin Hilman wrote: Tomi Valkeinen tomi.valkei...@nokia.com writes: On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote: Tomi Valkeinen tomi.valkei...@nokia.com writes: Hi, On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, If you disable the clocks to allow RET, you also allow OFF mode. And resuming from OFF mode hasn't been implemented for DSI, if I recall right. And when I was testing it, it didn't seem to be trivial with the DSI PLL. You can limiting the pwrdm next state to RET when being called from cpuidle. No, you _must_ limit it to RET. Otherwise the DSI will break down. So we can either keep the dsi code as it is now, or explicitely disable OFF mode and then apply your patch. But your patch alone won't work. Or could add a hack to this patch so that 'enable_off_mode' doesn't affect DSS_MOD until DSS has off-mode support. Is this something that the driver can do with the current PM API? The thing is, most of the DSS has off-mode support, only DSI and RFBI is missing the support. So optimally we would allow full PM normally, but when DSI display is in use, only allow RET. There's not an official API for this, but for testing, you could just set the next state for the DSS_MOD to be off. This would be overridden whenever someone changes the enable_off_mode flag. In general, we don't want drivers restricting states at that level. We'd rather the drivers use the OMAP PM layer to define/declare its constraints. If I want to disable OFF mode for DSS with constraints, doesn't it mean that I need to dig out a magic number, and use it as the max wakeup latency, and that latency will then limit DSS from going to OFF mode? Yes, the various wakeup times for RET and OFF should be measured so that smart decisions can be made. In the long run I think we anyway need to somehow dynamically manage the power state. I haven't measured it but I believe resuming from OFF will have a bit of a penalty, as (I think) DSI PLL etc. will have to reinitialized. But it would still be good to allow RET whenever possible, and OFF only after some period of inactivity. This is the purpose of latency constraints. These can be used when the latency of going OFF will cause a problem. I think this is a different problem. My understanding of the PM latency functionality is that they control how quickly MPU responds to interrupts, or how quickly the HW module is awake after clk_enable(). That's only part of the story. The problem here is that there's bunch of DSI initialization that needs to be done after the DSS module has woken up. The DSI PLL needs to be configured and locked, complex IO has to be configured etc. I don't know how long those take (should make some measurements at some point), but I imagine they are not anywhere near instant. And the latency from those things is what I'm concerned about. So it would be beneficial if the DSS driver could define easily what DSS PM level is allowed. Actually, the OMAP PM layer is meant to handle device wakeup latencies as well. See Documentation/arm/OMAP/omap_pm, and the set_max_dev_wakeup_lat() hook in particular. For example, if you know that DSS wakeup from OFF takes X usecs and the driver has set a max device wakeup latency X, then DSS will never go to OFF. The same can be done to prevent RET for even faster wakeup. The doc says set_max_dev_wakeup_lat() function to constrain the device wakeup latency (from clk_enable() to accessibility). I understood accessibility meaning that the HW registers can be accessed, and also as registers should be accessible after clk_enable(), it would mean that clk_enable will block at most the defined wakeup latency. Not exactly, clk_enable() doesn't actually block. Rather, the max latencies are intended to be used when considering which C-state to enter. If a C-state has a wakeup latency longer than any of the latency constraints set (MPU or device) then that C-state will not be entered. In this way you effectively prevent OFF mode (deeper C-state) by setting a max latency which is shorter than the wakeup latency of OFF mode. Right now you could do it simply by setting a max MPU wakeup latency, but we really need to measure the various device wakeup latencies so we can use them as well. If it is not like that, and the driver initialization is included, how does the PM layer know how long it takes for the DSS driver to reconfigure the DSS hardware from OFF mode? Currently it doesn't, but if you were measure it, we can use those numbers in the decision making process. 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
[PATCH 0/1] Common mechanism to identify Si revision
Currently there are multiple mechanisms for identifying silicon revisions. Most places the comparison is against omap_rev() as a whole number. This patch implements the comparison against the omap_revision bits alone. This makes the test independent of silicon in use. This patch doesn't remove all existing mechanisms for the check to maintain stability. The migration can follow in phases. [1] http://marc.info/?l=linux-omapm=125197467922935w=2 Sanjeev Premi (1): OMAP3: Common mechanism to identify cpu revision arch/arm/mach-omap2/clock34xx.c |4 +- arch/arm/mach-omap2/control.c |6 ++-- arch/arm/mach-omap2/pm34xx.c | 17 +- arch/arm/plat-omap/include/mach/cpu.h | 55 + 4 files changed, 69 insertions(+), 13 deletions(-) -- 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][RFC] OMAP3630: Create architecture macros and config entries.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Tuesday, September 22, 2009 5:18 PM To: Gadiyar, Anand; Aguirre Rodriguez, Sergio Alberto; Cousson, Benoit; Pais, Allen; linux-omap@vger.kernel.org Cc: Raju, Veeramanikandan; Bongale, Hariprasad Subject: RE: [PATCH][RFC] OMAP3630: Create architecture macros and config entries. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Tuesday, September 22, 2009 12:12 AM To: Aguirre Rodriguez, Sergio Alberto; Cousson, Benoit; Pais, Allen; linux-omap@vger.kernel.org Cc: Raju, Veeramanikandan; Bongale, Hariprasad Subject: RE: [PATCH][RFC] OMAP3630: Create architecture macros and config entries. snip -- snip --- snip I respectfully tend to disagree with this, since there are some components inside the chip that aren't specifically fixes, so IMHO they need to start from scratch about silicon revisions because of that. If there are many common points between 34xx/35xx/36xx, then rename the reused functions/defines to omap3, instead of omap34xx/omap35xx/omap36xx. [sp] We had same discussion in context of OMAP3517. And the Where the IPs and features etc have been more than just fixes. I will be submitting a patch later today; that will illustrate that cpu_is_xxx() changes are usually limited. [sp] Do take a look at the patch-set I just submitted: Common mechanism to identify Si revision ~sanjeev Regards, Sergio I agree with Sergio. While it is definitely possible to write code treating the 3430 and the 3630 as the same, they are not the same animal. We will need to distinguish between the two at more than a few locations in code, and we might as well add the ability to do that now. I see a need to distinguish between 3430 and 3630 in several locations - there are changes in hardware IPs that are not reflected in the IP revision information (meaning we cannot always go by CPU_HAS_FEATURE() ), and we will need some kind of a cpu_is_* check for sure. [sp] See my response above. Also, we seem to be at a juncture where may seemlingly similar but Different silicons are coming up. I believe it is the *best* time to come up with a framework where the IP/feature based checks can be Streamlined. Best regards, Sanjeev Regards, Anand -- 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 -- 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 -- 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 00/12] Omap fixes for 2.6.32-rc1
Hi all, Here are some omap fixes for review. Regards, Tony --- Ajay Kumar Gupta (1): omap: Add missing mux pin for EHCI phy reset line Angelo Arrifano (2): omap: Fix a OMAP_MPUIO_VBASE typo for 850 omap: Fix wrong jtag_id for 850 Hiroshi DOYU (2): omap: mailbox: Flush posted write when acking mailbox irq omap: mailbox: Execute softreset at startup Jarkko Nikula (1): omap: Fix MMC gpio_wp for BeagleBoard C2 and above Sanjeev Premi (1): omap: iovmm: Fix compiler warning Tobias Klauser (1): omap: rng: Use resource_size instead of manual calculation Tony Lindgren (4): omap: Fix matrix_keymap_data usage omap: Fix 44xx compile omap: Fix mcspi compile for 2420 omap: Fix compile for arch/arm/mach-omap2 arch/arm/mach-omap1/id.c |2 - arch/arm/mach-omap2/board-3430sdp.c | 10 +++- arch/arm/mach-omap2/board-ldp.c | 10 +++- arch/arm/mach-omap2/board-omap3beagle.c |7 ++- arch/arm/mach-omap2/board-omap3evm.c | 10 +++- arch/arm/mach-omap2/board-omap3pandora.c | 10 +++- arch/arm/mach-omap2/board-rx51-peripherals.c | 10 +++- arch/arm/mach-omap2/board-zoom2.c| 10 +++- arch/arm/mach-omap2/cm4xxx.c | 17 +-- arch/arm/mach-omap2/devices.c| 65 +++--- arch/arm/mach-omap2/io.c |4 +- arch/arm/mach-omap2/mailbox.c| 33 +++-- arch/arm/mach-omap2/mux.c|4 ++ arch/arm/mach-omap2/serial.c |6 +- arch/arm/plat-omap/gpio.c|2 - arch/arm/plat-omap/include/mach/keypad.h |5 +- arch/arm/plat-omap/include/mach/mux.h|2 + arch/arm/plat-omap/iovmm.c |5 +- drivers/char/hw_random/omap-rng.c|4 +- 19 files changed, 146 insertions(+), 70 deletions(-) -- Signature -- 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 01/12] omap: Fix compile for arch/arm/mach-omap2
Patch 941132606c7611246d2034cb7b01f9270c2d1ede split IO_ADDRESS
into OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS except for the omap4
code to avoid merge conflicts with the omap4 code that was queued
earlier.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/serial.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3a529c7..faada9f 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -110,7 +110,7 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
#ifdef CONFIG_ARCH_OMAP4
- .membase= IO_ADDRESS(OMAP_UART4_BASE),
+ .membase= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
.mapbase= OMAP_UART4_BASE,
.irq= 70,
.flags = UPF_BOOT_AUTOCONF,
@@ -126,7 +126,7 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
#ifdef CONFIG_ARCH_OMAP4
static struct plat_serial8250_port serial_platform_data3[] = {
{
- .membase= IO_ADDRESS(OMAP_UART4_BASE),
+ .membase= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
.mapbase= OMAP_UART4_BASE,
.irq= 70,
.flags = UPF_BOOT_AUTOCONF,
--
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 02/12] omap: Fix mcspi compile for 2420
Commit 7869c0b9ed44404bbc675ef76f8ccb3be5496f39 added support for
additional McSPI ports. Unfortunately that broke compile for 2420.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 65 ++---
1 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index bcfcfc7..faf7a1e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -355,29 +355,60 @@ static struct platform_device omap2_mcspi4 = {
};
#endif
-static void omap_init_mcspi(void)
+#ifdef CONFIG_ARCH_OMAP4
+static inline void omap4_mcspi_fixup(void)
{
- if (cpu_is_omap44xx()) {
- omap2_mcspi1_resources[0].start = OMAP4_MCSPI1_BASE;
- omap2_mcspi1_resources[0].end = OMAP4_MCSPI1_BASE + 0xff;
- omap2_mcspi2_resources[0].start = OMAP4_MCSPI2_BASE;
- omap2_mcspi2_resources[0].end = OMAP4_MCSPI2_BASE + 0xff;
- omap2_mcspi3_resources[0].start = OMAP4_MCSPI3_BASE;
- omap2_mcspi3_resources[0].end = OMAP4_MCSPI3_BASE + 0xff;
- omap2_mcspi4_resources[0].start = OMAP4_MCSPI4_BASE;
- omap2_mcspi4_resources[0].end = OMAP4_MCSPI4_BASE + 0xff;
- }
- platform_device_register(omap2_mcspi1);
- platform_device_register(omap2_mcspi2);
+ omap2_mcspi1_resources[0].start = OMAP4_MCSPI1_BASE;
+ omap2_mcspi1_resources[0].end = OMAP4_MCSPI1_BASE + 0xff;
+ omap2_mcspi2_resources[0].start = OMAP4_MCSPI2_BASE;
+ omap2_mcspi2_resources[0].end = OMAP4_MCSPI2_BASE + 0xff;
+ omap2_mcspi3_resources[0].start = OMAP4_MCSPI3_BASE;
+ omap2_mcspi3_resources[0].end = OMAP4_MCSPI3_BASE + 0xff;
+ omap2_mcspi4_resources[0].start = OMAP4_MCSPI4_BASE;
+ omap2_mcspi4_resources[0].end = OMAP4_MCSPI4_BASE + 0xff;
+}
+#else
+static inline void omap4_mcspi_fixup(void)
+{
+}
+#endif
+
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
defined(CONFIG_ARCH_OMAP4)
- if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx())
- platform_device_register(omap2_mcspi3);
+static inline void omap2_mcspi3_init(void)
+{
+ platform_device_register(omap2_mcspi3);
+}
+#else
+static inline void omap2_mcspi3_init(void)
+{
+}
#endif
+
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
- if (cpu_is_omap343x() || cpu_is_omap44xx())
- platform_device_register(omap2_mcspi4);
+static inline void omap2_mcspi4_init(void)
+{
+ platform_device_register(omap2_mcspi4);
+}
+#else
+static inline void omap2_mcspi4_init(void)
+{
+}
#endif
+
+static void omap_init_mcspi(void)
+{
+ if (cpu_is_omap44xx())
+ omap4_mcspi_fixup();
+
+ platform_device_register(omap2_mcspi1);
+ platform_device_register(omap2_mcspi2);
+
+ if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx())
+ omap2_mcspi3_init();
+
+ if (cpu_is_omap343x() || cpu_is_omap44xx())
+ omap2_mcspi4_init();
}
#else
--
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 03/12] omap: Fix 44xx compile
Looks like these patches were not tested that well..
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/cm4xxx.c | 17 ++---
arch/arm/mach-omap2/io.c |4 ++--
arch/arm/mach-omap2/serial.c |2 +-
3 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cm4xxx.c b/arch/arm/mach-omap2/cm4xxx.c
index e4ebd6d..4af76bb 100644
--- a/arch/arm/mach-omap2/cm4xxx.c
+++ b/arch/arm/mach-omap2/cm4xxx.c
@@ -22,7 +22,6 @@
#include asm/atomic.h
#include cm.h
-#include cm-regbits-4xxx.h
/* XXX move this to cm.h */
/* MAX_MODULE_READY_TIME: max milliseconds for module to leave idle */
@@ -50,19 +49,7 @@
*/
int omap4_cm_wait_idlest_ready(u32 prcm_mod, u8 prcm_dev_offs)
{
- int i = 0;
- u8 cm_id;
- u16 prcm_mod_offs;
- u32 mask = OMAP4_PRCM_CM_CLKCTRL_IDLEST_MASK;
-
- cm_id = prcm_mod OMAP4_PRCM_MOD_CM_ID_SHIFT;
- prcm_mod_offs = prcm_mod OMAP4_PRCM_MOD_OFFS_MASK;
-
- while (((omap4_cm_read_mod_reg(cm_id, prcm_mod_offs, prcm_dev_offs,
- OMAP4_CM_CLKCTRL_DREG) mask) != 0)
- (i++ MAX_MODULE_READY_TIME))
- udelay(1);
-
- return (i MAX_MODULE_READY_TIME) ? 0 : -EBUSY;
+ /* FIXME: Add clock manager related code */
+ return 0;
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 7574b6f..e3a3bad 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -294,10 +294,10 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
else if (cpu_is_omap34xx())
hwmods = omap34xx_hwmods;
- omap_hwmod_init(hwmods);
- omap2_mux_init();
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once the clkdev is ready */
/* The OPP tables have to be registered before a clk init */
+ omap_hwmod_init(hwmods);
+ omap2_mux_init();
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index faada9f..ae21868 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -579,7 +579,7 @@ static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS]
= {
{
.pdev = {
.name = serial8250,
- .id = 3
+ .id = 3,
.dev= {
.platform_data = serial_platform_data3,
},
--
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] OMAP: timekeeping: time should not stop during suspend
During suspend, the kernel timekeeping subsystem is shut down. Before
suspend and upon resume, it uses a weak function
read_persistent_clock() to determine the amount of time that elapsed
during suspend.
This function was not implemented on OMAP, so from the timekeeping
subsystem perspective (and thus userspace as well) it appeared that no
time elapsed during suspend.
This patch uses the 32k sync timer as a the persistent clock the 32k
sync timer value converted to seconds.
NOTE: This does *NOT* handle wrapping of the 32k sync timer, so
wrapping of the 32k sync timer during suspend may cause
problems. Also, there are not interrupts when the 32k sync
timer wraps, so something else has to be done.
Reported-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Tested on OMAP3 using PM branch.
If no issues, I will queue for 2.6.32-rc fixes
arch/arm/plat-omap/common.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index b3f70e6..3e4325b 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -178,6 +178,21 @@ unsigned long long sched_clock(void)
return ret;
}
+/**
+ * read_persistent_clock - Return time in seconds from the persistent clock.
+ */
+unsigned long read_persistent_clock(void)
+{
+ unsigned long long ret;
+ cycle_t cycles;
+
+ cycles = clocksource_32k.read(clocksource_32k);
+ ret = (cycles * clocksource_32k.mult_orig) clocksource_32k.shift;
+ do_div(ret, NSEC_PER_SEC);
+
+ return (unsigned long)ret;
+}
+
static int __init omap_init_clocksource_32k(void)
{
static char err[] __initdata = KERN_ERR
--
1.6.4.3
--
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 04/12] omap: Add missing mux pin for EHCI phy reset line
From: Ajay Kumar Gupta ajay.gu...@ti.com
GPIO135 is used as EHCI (port2) phy reset pin on Multi Media Daughter card
connected to OMAP3EVM.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c |2 ++
arch/arm/plat-omap/include/mach/mux.h |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 2daa595..339ba80 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -472,6 +472,8 @@ MUX_CFG_34XX(G25_34XX_GPIO86_OUT, 0x0fc,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX(AG4_34XX_GPIO134_OUT, 0x160,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(AF4_34XX_GPIO135_OUT, 0x162,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX(AE4_34XX_GPIO136_OUT, 0x164,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX(AF6_34XX_GPIO140_UP, 0x16c,
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 98dfab6..4bcf8a5 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -846,6 +846,7 @@ enum omap34xx_index {
L8_34XX_GPIO63,
G25_34XX_GPIO86_OUT,
AG4_34XX_GPIO134_OUT,
+ AF4_34XX_GPIO135_OUT,
AE4_34XX_GPIO136_OUT,
AF6_34XX_GPIO140_UP,
AE6_34XX_GPIO141,
--
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 06/12] omap: mailbox: Flush posted write when acking mailbox irq
From: Hiroshi DOYU hiroshi.d...@nokia.com The only way to flush posted write to L4 bus is to do a read back of the same register right after the write. This seems to be mostly needed in interrupt handlers to avoid causing spurious interrupts. The earlier fix has been to mark the L4 bus as strongly ordered memory, which solves the problem, but causes performance penalties. Similar to the fix, 03803a71041e3bc3c077f4e7b92f6ceaa9426df3 Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/mailbox.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 5bf9a2f..f3fefca 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -176,6 +176,9 @@ static void omap2_mbox_ack_irq(struct omap_mbox *mbox, u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit; mbox_write_reg(bit, p-irqstatus); + + /* Flush posted write for irq status to avoid spurious interrupts */ + mbox_read_reg(p-irqstatus); } static int omap2_mbox_is_irq(struct omap_mbox *mbox, -- 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 07/12] omap: iovmm: Fix compiler warning
From: Sanjeev Premi pr...@ti.com This patch fixes these compiler warnings: arch/arm/plat-omap/iovmm.c: In function 'vmap_sg': arch/arm/plat-omap/iovmm.c:202: warning: passing argument 1 of 'flush_cache_vmap' makes integer from pointer without a cast arch/arm/plat-omap/iovmm.c:202: warning: passing argument 2 of 'flush_cache_vmap' makes integer from pointer without a cast arch/arm/plat-omap/iovmm.c: In function 'sgtable_fill_vmalloc': arch/arm/plat-omap/iovmm.c:393: warning: passing argument 1 of 'flush_cache_vmap' makes integer from pointer without a cast arch/arm/plat-omap/iovmm.c:393: warning: passing argument 2 of 'flush_cache_vmap' makes integer from pointer without a cast Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/iovmm.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 6fc52fc..57f7122 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -199,7 +199,8 @@ static void *vmap_sg(const struct sg_table *sgt) va += bytes; } - flush_cache_vmap(new-addr, new-addr + total); + flush_cache_vmap((unsigned long)new-addr, + (unsigned long)(new-addr + total)); return new-addr; err_out: @@ -390,7 +391,7 @@ static void sgtable_fill_vmalloc(struct sg_table *sgt, void *_va) } va_end = _va + PAGE_SIZE * i; - flush_cache_vmap(_va, va_end); + flush_cache_vmap((unsigned long)_va, (unsigned long)va_end); } static inline void sgtable_drain_vmalloc(struct sg_table *sgt) -- 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 08/12] omap: Fix wrong jtag_id for 850
From: Angelo Arrifano mik...@gmail.com
Original message:
The previous value of the jtag_id was set for the omap730. For the
omap850, this value is different, and this was causing
autodetection to fail.
Reported-by:
Cory Maccarrone darkstar6...@gmail.com
Angelo Arrifano mik...@gmail.com
Alistair Buxton a.j.bux...@gmail.com
Signed-off-by: Angelo Arrifano mik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/id.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c
index 4ef26fa..e5dcdf7 100644
--- a/arch/arm/mach-omap1/id.c
+++ b/arch/arm/mach-omap1/id.c
@@ -38,7 +38,7 @@ static struct omap_id omap_ids[] __initdata = {
{ .jtag_id = 0xb574, .die_rev = 0x2, .omap_id = 0x03310315, .type =
0x0310},
{ .jtag_id = 0x355f, .die_rev = 0x0, .omap_id = 0x0332, .type =
0x07300100},
{ .jtag_id = 0xb55f, .die_rev = 0x0, .omap_id = 0x0332, .type =
0x07300300},
- { .jtag_id = 0xb55f, .die_rev = 0x0, .omap_id = 0x03320500, .type =
0x0850},
+ { .jtag_id = 0xb62c, .die_rev = 0x1, .omap_id = 0x03320500, .type =
0x0850},
{ .jtag_id = 0xb470, .die_rev = 0x0, .omap_id = 0x03310100, .type =
0x1510},
{ .jtag_id = 0xb576, .die_rev = 0x0, .omap_id = 0x0332, .type =
0x1610},
{ .jtag_id = 0xb576, .die_rev = 0x2, .omap_id = 0x03320100, .type =
0x1611},
--
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 09/12] omap: Fix a OMAP_MPUIO_VBASE typo for 850
From: Angelo Arrifano mik...@gmail.com
This was crashing omap850 devices.
Reported-by:
Alistair Buxton a.j.bux...@gmail.com
Signed-off-by: Angelo Arrifano mik...@gmail.com
Signed-obb-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 693839c..71ebd7f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -250,7 +250,7 @@ static struct gpio_bank gpio_bank_730[7] = {
#ifdef CONFIG_ARCH_OMAP850
static struct gpio_bank gpio_bank_850[7] = {
- { OMAP1_MPUIO_BASE, INT_850_MPUIO, IH_MPUIO_BASE,
METHOD_MPUIO },
+ { OMAP1_MPUIO_VBASE, INT_850_MPUIO, IH_MPUIO_BASE,
METHOD_MPUIO },
{ OMAP850_GPIO1_BASE, INT_850_GPIO_BANK1, IH_GPIO_BASE,
METHOD_GPIO_850 },
{ OMAP850_GPIO2_BASE, INT_850_GPIO_BANK2, IH_GPIO_BASE + 32,
METHOD_GPIO_850 },
{ OMAP850_GPIO3_BASE, INT_850_GPIO_BANK3, IH_GPIO_BASE + 64,
METHOD_GPIO_850 },
--
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 10/12] omap: Fix matrix_keymap_data usage
Otherwise we'll get compile errors like:
arch/arm/plat-omap/include/mach/keypad.h:38:1: warning: KEY redefined
arch/arm/plat-omap/include/mach/keypad.h:39:1: warning: PERSISTENT_KEY
redefined
...
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c | 10 +++---
arch/arm/mach-omap2/board-ldp.c | 10 +++---
arch/arm/mach-omap2/board-omap3evm.c | 10 +++---
arch/arm/mach-omap2/board-omap3pandora.c | 10 +++---
arch/arm/mach-omap2/board-rx51-peripherals.c | 10 +++---
arch/arm/mach-omap2/board-zoom2.c| 10 +++---
arch/arm/plat-omap/include/mach/keypad.h |5 ++---
7 files changed, 44 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bd57ec7..efaf053 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -54,7 +54,7 @@
#define TWL4030_MSECURE_GPIO 22
-static int sdp3430_keymap[] = {
+static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
KEY(0, 2, KEY_A),
@@ -88,11 +88,15 @@ static int sdp3430_keymap[] = {
0
};
+static struct matrix_keymap_data board_map_data = {
+ .keymap = board_keymap,
+ .keymap_size= ARRAY_SIZE(board_keymap),
+};
+
static struct twl4030_keypad_data sdp3430_kp_data = {
+ .keymap_data= board_map_data,
.rows = 5,
.cols = 6,
- .keymap = sdp3430_keymap,
- .keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
};
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index ec6854c..d110a7f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -80,7 +80,7 @@ static struct platform_device ldp_smsc911x_device = {
},
};
-static int ldp_twl4030_keymap[] = {
+static int board_keymap[] = {
KEY(0, 0, KEY_1),
KEY(1, 0, KEY_2),
KEY(2, 0, KEY_3),
@@ -101,11 +101,15 @@ static int ldp_twl4030_keymap[] = {
0
};
+static struct matrix_keymap_data board_map_data = {
+ .keymap = board_keymap,
+ .keymap_size= ARRAY_SIZE(board_keymap),
+};
+
static struct twl4030_keypad_data ldp_kp_twl4030_data = {
+ .keymap_data= board_map_data,
.rows = 6,
.cols = 6,
- .keymap = ldp_twl4030_keymap,
- .keymapsize = ARRAY_SIZE(ldp_twl4030_keymap),
.rep= 1,
};
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index d50b9be..e4ec0c5 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -159,7 +159,7 @@ static struct twl4030_usb_data omap3evm_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
-static int omap3evm_keymap[] = {
+static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
KEY(0, 2, KEY_A),
@@ -178,11 +178,15 @@ static int omap3evm_keymap[] = {
KEY(3, 3, KEY_P)
};
+static struct matrix_keymap_data board_map_data = {
+ .keymap = board_keymap,
+ .keymap_size= ARRAY_SIZE(board_keymap),
+};
+
static struct twl4030_keypad_data omap3evm_kp_data = {
+ .keymap_data= board_map_data,
.rows = 4,
.cols = 4,
- .keymap = omap3evm_keymap,
- .keymapsize = ARRAY_SIZE(omap3evm_keymap),
.rep= 1,
};
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index b43f6e3..7f6bf87 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -133,7 +133,7 @@ static void __init pandora_keys_gpio_init(void)
omap_set_gpio_debounce_time(32 * 5, GPIO_DEBOUNCE_TIME);
}
-static int pandora_keypad_map[] = {
+static int board_keymap[] = {
/* col, row, code */
KEY(0, 0, KEY_9),
KEY(0, 1, KEY_0),
@@ -180,11 +180,15 @@ static int pandora_keypad_map[] = {
KEY(5, 2, KEY_FN),
};
+static struct matrix_keymap_data board_map_data = {
+ .keymap = board_keymap,
+ .keymap_size= ARRAY_SIZE(board_keymap),
+};
+
static struct twl4030_keypad_data pandora_kp_data = {
+ .keymap_data= board_map_data,
.rows = 8,
.cols = 6,
- .keymap = pandora_keypad_map,
- .keymapsize = ARRAY_SIZE(pandora_keypad_map),
.rep= 1,
};
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e6e8290..b45ad31 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -36,7 +36,7 @@
#define
[PATCH 11/12] omap: Fix MMC gpio_wp for BeagleBoard C2 and above
From: Jarkko Nikula jhnik...@gmail.com
Earlier BeagleBoards were using pad AH8 muxed to GPIO29 for MMC write-protect.
However, this signal has been changed to pad AG9 in board revision C2.
Fix this by adding mux configuration for pad AG9, runtime check for board
revisions and set the gpio number and pad muxing accordingly.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3beagle.c |7 ++-
arch/arm/mach-omap2/mux.c |2 ++
arch/arm/plat-omap/include/mach/mux.h |1 +
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 500c995..70df6b4 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -139,8 +139,13 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ if (system_rev = 0x20 system_rev = 0x34301000) {
+ omap_cfg_reg(AG9_34XX_GPIO23);
+ mmc[0].gpio_wp = 23;
+ } else {
+ omap_cfg_reg(AH8_34XX_GPIO29);
+ }
/* gpio + 0 is mmc0_cd (input/IRQ) */
- omap_cfg_reg(AH8_34XX_GPIO29);
mmc[0].gpio_cd = gpio + 0;
twl4030_mmc_init(mmc);
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 339ba80..b5fac32 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -460,6 +460,8 @@ MUX_CFG_34XX(AF26_34XX_GPIO0, 0x1e0,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(AF22_34XX_GPIO9, 0xa18,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX(AG9_34XX_GPIO23, 0x5ee,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(U8_34XX_GPIO54_OUT, 0x0b4,
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 4bcf8a5..0f49d2d 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -840,6 +840,7 @@ enum omap34xx_index {
*/
AF26_34XX_GPIO0,
AF22_34XX_GPIO9,
+ AG9_34XX_GPIO23,
AH8_34XX_GPIO29,
U8_34XX_GPIO54_OUT,
U8_34XX_GPIO54_DOWN,
--
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 12/12] omap: rng: Use resource_size instead of manual calculation
From: Tobias Klauser tklau...@distanz.ch
Use the resource_size function instead of manually calculating the
resource size. This reduces the chance of introducing off-by-one-errors.
Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
drivers/char/hw_random/omap-rng.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 00dd3de..06aad08 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -116,7 +116,7 @@ static int __devinit omap_rng_probe(struct platform_device
*pdev)
if (!res)
return -ENOENT;
- mem = request_mem_region(res-start, res-end - res-start + 1,
+ mem = request_mem_region(res-start, resource_size(res),
pdev-name);
if (mem == NULL) {
ret = -EBUSY;
@@ -124,7 +124,7 @@ static int __devinit omap_rng_probe(struct platform_device
*pdev)
}
dev_set_drvdata(pdev-dev, mem);
- rng_base = ioremap(res-start, res-end - res-start + 1);
+ rng_base = ioremap(res-start, resource_size(res));
if (!rng_base) {
ret = -ENOMEM;
goto err_ioremap;
--
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
