Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
On Tue, 16 Nov 2010 08:16:07 -0800 Kevin Hilman khil...@deeprootsystems.com wrote: Yes, I'm not a big fan of the init function called multiple times either, but I really want to minimize what board files have to do. Historically, we tend to add all the init functions to every board file, and this is getting cumbersome to understand and maintain. What we need is for common code to take care of sensible defaults for all boards, and then only boards with non-default behavior have to have custom code. The other way is to have the board code register its customization into the OPP subsystem, and then when the OPP subsystem is initialized, it takes those customizations into account. But in that specific case, it's not clear how those customizations could easily be expressed, so maybe that multiple call strategy is the simplest solution. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi,
Tomi Valkeinen wrote:
On Tue, 2010-11-16 at 12:22 +0100, ext Taneja, Archit wrote:
Hi,
Tomi Valkeinen wrote:
Hi,
[snip]
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 586944d..3e6eec1 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -434,6 +434,7 @@ struct omap_dss_device {
struct omap_overlay_manager *manager;
enum omap_dss_display_state state;
+ enum omap_channel channel;
Isn't this the same as dssdev-manager-id?
Yes, this channel stuff is a bit confusing, even the enum omap_channel
is badly named (should at least have dss in it). But
omap_overlay_manager should represent the output pipe, so I don't
think there's need for channel field in dss_device.
The panel somehow needs to tell which manager it is connected to. We
went with with the way of declaring a new member 'channel' and setting
that parameter up in the board file.
The current way to relate the manager and device is done by checking
the dssdev-type in dss_recheck_connections() and then calling set_device()
This is not sufficient any more since two of the managers can support
similar types of displays.
So in the channel approach the following happens:
-mgr-id's are initialized at bootup.
-devices and managers are connected using 'channel'.
-mgr-id automatically becomes equal to channel.
Can we set something like dssdev-manager-id in the board file itself?
Right, now I see.
The dss_recheck_connections() felt like a hack when I wrote it =).
Clearly we need some way to define in the board file which
panel connects to which manager.
It wasn't needed probably for OMAP3 since all non-venc panels connect
to LCD and venc to VENC type.
Now that I think of it, what channel would we mention if the panel is
used in dsi l4 update mode or dma mode? It should have no manager at all.
Perhaps move the channel-field up, just below enum
omap_display_type type. The lines in the beginning of
omap_dss_device are things which define the interface etc,
and later there are miscallaneous dynamic things. And this belongs to the
former.
Now, if we have the channel defined in this way in the
omap_dss_device, I'm wondering if:
1) the manager pointer is needed at all, as the channel tells which manager
it is? 2) if we keep the manager pointer (as a helper shortcut),
should the code use generally use dssdev-channel or dssdev-manager-id?
I think manager-id makes more sense considering your logic below.
3) having this channel field requires a change to every board
file, because the channel has to be defined?
Yes, that is something that has to be done for all 'DIGIT'
panels across all boards.
And answering to myself, I guess the manager pointer is
needed, because
DSS2 supports (at least in theory) multiple panels in the
same interface (not at the same time, of course). This means
that we could have to panels, with the same interface and
channel, but only one would be in use. So the one in use
should have manager pointing to the correct manager, and the
other would have manager NULL.
Yes, passing dssdev-channel would make things worse if 2 panels
are connected to same interface.
And thus perhaps using dssdev-channel only for connecting
the right manager to right panel, and using
dssdev-manager-id for other uses would be the best? The
values would of course be the same, but at least we'd get a
crash if somehow an unconnected display is being used for configuration.
Even in the current kernel on 3430sdp, the board file adds sharp_ls, venc and
generic panels
If I boot up with venc as default display, mgr0 has dvi as its display and mgr1
has tv.
So if I try to enable sharp_ls panel I get a crash when we first try to access
dssdev-manager
in dpi_display_enable(). We should have a way to prevent enabling a panel if it
isn't connected
to a manager. We should also have a way to allow a panel to have no channel at
all (something like
OMAP_DSS_CHANNEL_NONE) if we are using something like dsi l4 update.
I won't add this extra channel now though, we need to think of a better way
later.
Does this make sense?
Yes, it does, I'll make these changes, and more if you can think of any.
Archit--
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: Serial: Define register access modes in LCR
From: Andrei Emeltchenko andrei.emeltche...@nokia.com
Access to some registers depends on register access mode
Three different modes are available for OMAP (at least)
• Operational mode LCR_REG[7] = 0x0
• Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF
• Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF
Define access modes and remove redefinitions and magic numbers
in serial drivers (and later in bluetooth driver).
Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com
---
arch/arm/mach-omap2/serial.c | 12
arch/arm/plat-omap/include/plat/omap-serial.h |9 --
drivers/serial/8250.c | 26 +-
drivers/serial/omap-serial.c | 34
include/linux/serial_reg.h|7 +
5 files changed, 43 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index
edd7c99de38dde5bf877788fb4e48055c0d9fbfa..14c87157d70758d4203593f78f2eaf4c2f2cca68
100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -218,7 +218,7 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
return;
lcr = serial_read_reg(uart, UART_LCR);
- serial_write_reg(uart, UART_LCR, 0xBF);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
uart-dll = serial_read_reg(uart, UART_DLL);
uart-dlh = serial_read_reg(uart, UART_DLM);
serial_write_reg(uart, UART_LCR, lcr);
@@ -226,7 +226,7 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
uart-sysc = serial_read_reg(uart, UART_OMAP_SYSC);
uart-scr = serial_read_reg(uart, UART_OMAP_SCR);
uart-wer = serial_read_reg(uart, UART_OMAP_WER);
- serial_write_reg(uart, UART_LCR, 0x80);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
uart-mcr = serial_read_reg(uart, UART_MCR);
serial_write_reg(uart, UART_LCR, lcr);
@@ -250,19 +250,19 @@ static void omap_uart_restore_context(struct
omap_uart_state *uart)
else
serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
efr = serial_read_reg(uart, UART_EFR);
serial_write_reg(uart, UART_EFR, UART_EFR_ECB);
serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
serial_write_reg(uart, UART_IER, 0x0);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
serial_write_reg(uart, UART_DLL, uart-dll);
serial_write_reg(uart, UART_DLM, uart-dlh);
serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
serial_write_reg(uart, UART_IER, uart-ier);
- serial_write_reg(uart, UART_LCR, 0x80);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
serial_write_reg(uart, UART_MCR, uart-mcr);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
serial_write_reg(uart, UART_EFR, efr);
serial_write_reg(uart, UART_LCR, UART_LCR_WLEN8);
serial_write_reg(uart, UART_OMAP_SCR, uart-scr);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index
6a17880146111ddfabef564583e464c1c75bb379..b3e0bad9b77eb5138fe01253bd99bfc62bd6ac2d
100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -33,15 +33,6 @@
#define OMAP_MODE13X_SPEED 230400
-/*
- * LCR = 0XBF: Switch to Configuration Mode B.
- * In configuration mode b allow access
- * to EFR,DLL,DLH.
- * Reference OMAP TRM Chapter 17
- * Section: 1.4.3 Mode Selection
- */
-#define OMAP_UART_LCR_CONF_MDB 0XBF
-
/* WER = 0x7F
* Enable module level wakeup in WER reg
*/
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index
4d8e14b7aa931bcf3de11c6e5805005e0bf413ca..aaf9907e6014f547f28a617504125e6ffd177cbe
100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -653,13 +653,13 @@ static void serial8250_set_sleep(struct uart_8250_port
*p, int sleep)
{
if (p-capabilities UART_CAP_SLEEP) {
if (p-capabilities UART_CAP_EFR) {
- serial_outp(p, UART_LCR, 0xBF);
+ serial_outp(p, UART_LCR, UART_LCR_CONF_MODE_B);
serial_outp(p, UART_EFR, UART_EFR_ECB);
serial_outp(p, UART_LCR, 0);
}
serial_outp(p, UART_IER, sleep ? UART_IERX_SLEEP : 0);
if (p-capabilities UART_CAP_EFR) {
- serial_outp(p, UART_LCR, 0xBF);
+ serial_outp(p, UART_LCR, UART_LCR_CONF_MODE_B);
Re: [PATCH] OMAP: Serial: Define register access modes in LCR
On Wed, Nov 17, 2010 at 2:01 PM, Emeltchenko Andrei
andrei.emeltchenko.n...@gmail.com wrote:
From: Andrei Emeltchenko andrei.emeltche...@nokia.com
Access to some registers depends on register access mode
Three different modes are available for OMAP (at least)
• Operational mode LCR_REG[7] = 0x0
• Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF
• Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF
Define access modes and remove redefinitions and magic numbers
in serial drivers (and later in bluetooth driver).
Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com
---
arch/arm/mach-omap2/serial.c | 12
arch/arm/plat-omap/include/plat/omap-serial.h | 9 --
drivers/serial/8250.c | 26 +-
drivers/serial/omap-serial.c | 34
include/linux/serial_reg.h | 7 +
5 files changed, 43 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index
edd7c99de38dde5bf877788fb4e48055c0d9fbfa..14c87157d70758d4203593f78f2eaf4c2f2cca68
100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -218,7 +218,7 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
return;
lcr = serial_read_reg(uart, UART_LCR);
- serial_write_reg(uart, UART_LCR, 0xBF);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
uart-dll = serial_read_reg(uart, UART_DLL);
uart-dlh = serial_read_reg(uart, UART_DLM);
serial_write_reg(uart, UART_LCR, lcr);
@@ -226,7 +226,7 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
uart-sysc = serial_read_reg(uart, UART_OMAP_SYSC);
uart-scr = serial_read_reg(uart, UART_OMAP_SCR);
uart-wer = serial_read_reg(uart, UART_OMAP_WER);
- serial_write_reg(uart, UART_LCR, 0x80);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
uart-mcr = serial_read_reg(uart, UART_MCR);
serial_write_reg(uart, UART_LCR, lcr);
@@ -250,19 +250,19 @@ static void omap_uart_restore_context(struct
omap_uart_state *uart)
else
serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
efr = serial_read_reg(uart, UART_EFR);
serial_write_reg(uart, UART_EFR, UART_EFR_ECB);
serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
serial_write_reg(uart, UART_IER, 0x0);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
serial_write_reg(uart, UART_DLL, uart-dll);
serial_write_reg(uart, UART_DLM, uart-dlh);
serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
serial_write_reg(uart, UART_IER, uart-ier);
- serial_write_reg(uart, UART_LCR, 0x80);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
serial_write_reg(uart, UART_MCR, uart-mcr);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
serial_write_reg(uart, UART_EFR, efr);
serial_write_reg(uart, UART_LCR, UART_LCR_WLEN8);
serial_write_reg(uart, UART_OMAP_SCR, uart-scr);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index
6a17880146111ddfabef564583e464c1c75bb379..b3e0bad9b77eb5138fe01253bd99bfc62bd6ac2d
100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -33,15 +33,6 @@
#define OMAP_MODE13X_SPEED 230400
-/*
- * LCR = 0XBF: Switch to Configuration Mode B.
- * In configuration mode b allow access
- * to EFR,DLL,DLH.
- * Reference OMAP TRM Chapter 17
- * Section: 1.4.3 Mode Selection
- */
-#define OMAP_UART_LCR_CONF_MDB 0XBF
-
/* WER = 0x7F
* Enable module level wakeup in WER reg
*/
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index
4d8e14b7aa931bcf3de11c6e5805005e0bf413ca..aaf9907e6014f547f28a617504125e6ffd177cbe
100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -653,13 +653,13 @@ static void serial8250_set_sleep(struct uart_8250_port
*p, int sleep)
{
if (p-capabilities UART_CAP_SLEEP) {
if (p-capabilities UART_CAP_EFR) {
- serial_outp(p, UART_LCR, 0xBF);
+ serial_outp(p, UART_LCR, UART_LCR_CONF_MODE_B);
serial_outp(p, UART_EFR, UART_EFR_ECB);
serial_outp(p, UART_LCR, 0);
}
serial_outp(p, UART_IER, sleep ? UART_IERX_SLEEP : 0);
if (p-capabilities
Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
- Original Message -
From: Grant Erickson maratho...@gmail.com
To: Hemanth V heman...@ti.com
Cc: Tony Lindgren t...@atomide.com; linux-omap@vger.kernel.org
Sent: Tuesday, November 16, 2010 11:15 PM
Subject: Re: [PATCH] Add OMAP Support for Generic PWM Devices using
Dual-mode Timers
Boards can register such devices using platform data such as in the
following
example:
static struct omap2_pwm_platform_config pwm_config = {
.timer_id = 10, // GPT10_PWM_EVT
Since only specific GPTs can be configured for PWM, can some check
we added in probe function?
Yes, that check is already present in the probe function:
pwm-dm_timer = omap_dm_timer_request_specific(pdata-timer_id);
if (pwm-dm_timer == NULL) {
status = -ENOENT;
goto err_free;
}
Since only GPT8 to GPT11 can be configured for PWM output on OMAP3,
I was thinking if a suitable check can be added.
Thanks
Hemanth
--
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/7] crypto: updates omap sham device related platform code
Hi,
This patch was already applied months ago.
It appeared by mistake as git format-patch took it somehow.
Please ignore it...
- Dmitry
On 16/11/10 19:19, ext Tony Lindgren wrote:
* Dmitry Kasatkin dmitry.kasat...@nokia.com [101110 09:20]:
- registration with multi OMAP kernels support
- clocks
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/devices.c | 58
+++-
arch/arm/plat-omap/include/plat/omap34xx.h |5 ++
5 files changed, 56 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index d932b14..1820a55 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1836,7 +1836,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, vlynq_ick,vlynq_ick, CK_242X),
CLK(NULL, vlynq_fck,vlynq_fck, CK_242X),
CLK(NULL, des_ick, des_ick, CK_242X),
-CLK(NULL, sha_ick, sha_ick, CK_242X),
+CLK(omap-sham,ick, sha_ick, CK_242X),
CLK(omap_rng, ick, rng_ick, CK_242X),
CLK(NULL, aes_ick, aes_ick, CK_242X),
CLK(NULL, pka_ick, pka_ick, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 0438b6e..5884ac6 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1924,7 +1924,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, sdma_ick, sdma_ick, CK_243X),
CLK(NULL, sdrc_ick, sdrc_ick, CK_243X),
CLK(NULL, des_ick, des_ick, CK_243X),
-CLK(NULL, sha_ick, sha_ick, CK_243X),
+CLK(omap-sham,ick, sha_ick, CK_243X),
CLK(omap_rng, ick, rng_ick, CK_243X),
CLK(NULL, aes_ick, aes_ick, CK_243X),
CLK(NULL, pka_ick, pka_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 9cba556..52638df 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3360,7 +3360,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(mmci-omap-hs.2, ick, mmchs3_ick,CK_3430ES2 | CK_AM35XX),
CLK(NULL, icr_ick, icr_ick, CK_343X),
CLK(NULL, aes2_ick, aes2_ick, CK_343X),
-CLK(NULL, sha12_ick,sha12_ick, CK_343X),
+CLK(omap-sham,ick, sha12_ick, CK_343X),
CLK(NULL, des2_ick, des2_ick, CK_343X),
CLK(mmci-omap-hs.1, ick, mmchs2_ick,CK_3XXX),
CLK(mmci-omap-hs.0, ick, mmchs1_ick,CK_3XXX),
This looks OK.
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..beac46c 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,6 +26,7 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
+#include plat/dma.h
#include mux.h
@@ -453,8 +454,10 @@ static void omap_init_mcspi(void)
static inline void omap_init_mcspi(void) {}
#endif
-#ifdef CONFIG_OMAP_SHA1_MD5
-static struct resource sha1_md5_resources[] = {
+#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
+
+#ifdef CONFIG_ARCH_OMAP24XX
+static struct resource omap2_sham_resources[] = {
{
.start = OMAP24XX_SEC_SHA1MD5_BASE,
.end= OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
@@ -465,20 +468,55 @@ static struct resource sha1_md5_resources[] = {
.flags = IORESOURCE_IRQ,
}
};
+static int omap2_sham_resources_sz = ARRAY_SIZE(omap2_sham_resources);
+#else
+#define omap2_sham_resourcesNULL
+#define omap2_sham_resources_sz 0
+#endif
-static struct platform_device sha1_md5_device = {
-.name = OMAP SHA1/MD5,
+#ifdef CONFIG_ARCH_OMAP34XX
+static struct resource omap3_sham_resources[] = {
+{
+.start = OMAP34XX_SEC_SHA1MD5_BASE,
+.end= OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
+.flags = IORESOURCE_MEM,
+},
+{
+.start = INT_34XX_SHA1MD52_IRQ,
+.flags = IORESOURCE_IRQ,
+},
+{
+.start = OMAP34XX_DMA_SHA1MD5_RX,
+.flags = IORESOURCE_DMA,
+}
+};
+static int omap3_sham_resources_sz = ARRAY_SIZE(omap3_sham_resources);
+#else
+#define omap3_sham_resourcesNULL
+#define omap3_sham_resources_sz 0
+#endif
+
+static struct platform_device sham_device = {
+.name = omap-sham,
Re: [PATCH] omap3: feature: fix OMAP3_IVA_MASK
Tony Lindgren wrote, on 11/16/2010 03:27 PM: * Nishanth Menonn...@ti.com [101105 17:29]: From: Arno Steffenarno.stef...@googlemail.com OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT Signed-off-by: Arno Steffenarno.stef...@googlemail.com --- Sending on behalf of Arno - he pointed at the change and everything except for the patch ;) Reported here: http://marc.info/?l=linux-omapm=128896969832702w=2 Hmm, until we have an official verbal-patch-to-unified-diff translator, I guess the right thing to do here is to make it be: From: Nishanth Menonn...@ti.com OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT Reported-by: Arno Steffenarno.stef...@googlemail.com Signed-off-by: Nishanth Menonn...@ti.com Can you please repost or confirm that's OK for you? I would prefer if Arno resubmit the patch under his name - but if he cannot do so, I can take ownership. Arno, please comment. Tony arch/arm/mach-omap2/control.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index b6c6b7c..5325297 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -309,7 +309,7 @@ #define FEAT_SGX_NONE 2 #define OMAP3_IVA_SHIFT 12 -#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT) +#define OMAP3_IVA_MASK (1 OMAP3_IVA_SHIFT) #define FEAT_IVA0 #define FEAT_IVA_NONE 1 -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Nishanth Menon -- 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: prcm: switch to a chained IRQ handler mechanism
From: Thomas Petazzoni t-petazz...@ti.com
Until this patch, the PRCM interrupt was handled through a normal,
single interrupt handler. However, the PRCM notifies various types of
events, which might be of interest to different drivers. In
preparation for the usage of the PRCM interrupt by those drivers, we
switch to a chained interrupt handler model, so that each driver will
be able to register its own interrupt handler on a particular
interrupt line, depending on the event the driver is interested in.
Signed-off-by: Thomas Petazzoni t-petazz...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 191 +---
arch/arm/plat-omap/include/plat/irqs.h | 38 ++-
2 files changed, 161 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index d068348..77a9a49 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/delay.h
#include linux/slab.h
+#include linux/irq.h
#include plat/sram.h
#include plat/clockdomain.h
@@ -243,7 +244,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
return c;
}
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
{
int c;
@@ -255,64 +256,10 @@ static int _prcm_int_handle_wakeup(void)
c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
}
- return c;
-}
-
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
-{
- u32 irqenable_mpu, irqstatus_mpu;
- int c = 0;
-
- irqenable_mpu = prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQENABLE_MPU_OFFSET);
- irqstatus_mpu = prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- irqstatus_mpu = irqenable_mpu;
-
- do {
- if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
-OMAP3430_IO_ST_MASK)) {
- c = _prcm_int_handle_wakeup();
-
- /*
-* Is the MPU PRCM interrupt handler racing with the
-* IVA2 PRCM interrupt handler ?
-*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
-but no wakeup sources are marked\n);
- } else {
- /* XXX we need to expand our PRCM interrupt handler */
- WARN(1, prcm: WARNING: PRCM interrupt received, but
-no code to handle it (%08x)\n, irqstatus_mpu);
- }
-
- prm_write_mod_reg(irqstatus_mpu, OCP_MOD,
- OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-
- irqstatus_mpu = prm_read_mod_reg(OCP_MOD,
- OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- irqstatus_mpu = irqenable_mpu;
-
- } while (irqstatus_mpu);
-
- return IRQ_HANDLED;
+ if (c)
+ return IRQ_HANDLED;
+ else
+ return IRQ_NONE;
}
static void restore_control_register(u32 val)
@@ -998,11 +945,104 @@ void omap_push_sram_idle(void)
save_secure_ram_context_sz);
}
+static void prcm_irq_ack(unsigned irq)
+{
+ int prcm_irq = irq - OMAP_PRCM_IRQ_BASE;
+
+ prm_write_mod_reg((1 prcm_irq), OCP_MOD,
+ OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+}
+
+static void prcm_irq_mask(unsigned irq)
+{
+ int prcm_irq = irq - OMAP_PRCM_IRQ_BASE;
+
+ prm_rmw_mod_reg_bits((1 prcm_irq), 0, OCP_MOD,
+OMAP3_PRM_IRQENABLE_MPU_OFFSET);
+}
+
+static void prcm_irq_unmask(unsigned irq)
+{
+ int prcm_irq = irq - OMAP_PRCM_IRQ_BASE;
+
+ prm_rmw_mod_reg_bits(0, (1 prcm_irq), OCP_MOD,
+OMAP3_PRM_IRQENABLE_MPU_OFFSET);
+}
+
Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
On Tue, 2010-11-16 at 21:10 +0100, ext Tony Lindgren wrote: * Kevin Hilman khil...@deeprootsystems.com [101116 11:45]: Tony Lindgren t...@atomide.com writes: * Tomi Valkeinen tomi.valkei...@nokia.com [101116 05:41]: On Tue, 2010-11-16 at 07:09 +0100, ext Nilofer, Samreen wrote: Hi, Any more comments on this patch? I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not looked kindly at. Shouldn't they be enabled in the arch/arm/configs config file, if they are wanted? Tony, do you have opinnion on this? Should DSS features be enabled by default in the Kconfig files, or only in the board config file? The best thing would be to have DSS y if ARCH_OMAP2PLUS or similar, then have all the features built in and pass the configuration options in platform_data. That still allows disabling certain features with Kconfig if needed for memory consumption etc. But the omap2plus_defconfig should just work on all the boards. Personally, I'd much rather see DSS core and optional features default to being built as a module. Other than a splash screen, there's no reason DSS is needed for a minimal boot. Sure a module would be even better. My point is that the selection of all the features should be enabled by default and the board options come from platform_data. Ok, let's build DSS all panel drivers as modules by default. Somehow I've gotten the impression from linux ml that enabling features by default is bad. But perhaps it's more about intervening features than normal drivers. Samreen, will you change the patch to set DSS panel drivers to be built as modules by default? Optimally all display interfaces should be enabled, but I believe at least SDI and DSI are currently slightly broken, because they prevent DSS from initializing if SDI/DSI regulator is not defined in the board file. So perhaps we should start with only DPI and VENC enabled (plus all the DPI panels). Also, this patch could be based on top of Bryan Wu's new generic panel patch set, which I'll perhaps apply today to my tree if I find no more to comment about. 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
Re: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
On Wed, 2010-11-17 at 10:23 +0800, ext Bryan Wu wrote:
Generic DPI panel driver includes the driver and 4 similar panel
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 348
4 files changed, 394 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
snip
+static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
+{
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
+ struct panel_config *panel_config = NULL;
+ struct panel_drv_data *drv_data = NULL;
+ int i;
+
+ dev_dbg(dssdev-dev, probe\n);
+
+ if (!panel_data || !panel_data-name)
+ return -EINVAL;
+
+ for (i = 0; i ARRAY_SIZE(generic_dpi_panels); i++) {
+ if (strcmp(panel_data-name, generic_dpi_panels[i].name) == 0) {
+ panel_config = generic_dpi_panels[i];
+ break;
+ }
+ }
+
+ if (!panel_config)
+ return -EINVAL;
+
+ dssdev-panel.config = panel_config-config;
+ dssdev-panel.timings = panel_config-timings;
+ dssdev-panel.acb = panel_config-acb;
+ dssdev-panel.acbi = panel_config-acbi;
+
+ drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL);
+ if (!drv_data)
+ return -ENOMEM;
+
+ drv_data-dssdev = dssdev;
+ drv_data-panel_config = panel_config;
+
+ dev_set_drvdata(dssdev-dev, drv_data);
+
+ return 0;
+}
+
+static void generic_dpi_panel_remove(struct omap_dss_device *dssdev)
+{
+}
You need to free the drv_data here.
Perhaps this will be the last fix =).
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
RE: [PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #7)
Acked-by: Archit Taneja arc...@ti.com bryan...@canonical.com wrote: There are 4 duplicated DPI panel drivers in DSS2 display driver. They are similar and a generic DPI panel driver can support all them with specific panel configuration. And new DPI panel driver can be easily supported by adding panel configurations into generic panel DPI driver. This patchset introduces a generic panel DPI driver, remove 3 panel drivers and enable generic panel DPI driver in board files. And it is based on 2.6.37-rc2. Building with omap2plus_defconfig is successful. Keep sharp_ls_panel, since it contains blacklight control code which will be moved out later. Bryan Wu (3): OMAP: DSS2: Add generic DPI panel display driver OMAP: use generic DPI panel driver in board files OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers arch/arm/mach-omap2/board-3430sdp.c| 12 +- arch/arm/mach-omap2/board-am3517evm.c | 23 +- arch/arm/mach-omap2/board-cm-t35.c | 23 +- arch/arm/mach-omap2/board-devkit8000.c | 26 +- arch/arm/mach-omap2/board-igep0020.c | 12 +- arch/arm/mach-omap2/board-omap3beagle.c| 12 +- arch/arm/mach-omap2/board-omap3evm.c | 12 +- arch/arm/mach-omap2/board-omap3stalker.c | 23 +- .../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++ drivers/video/omap2/displays/Kconfig | 22 +- drivers/video/omap2/displays/Makefile |4 +- drivers/video/omap2/displays/panel-generic-dpi.c | 348 drivers/video/omap2/displays/panel-generic.c | 174 -- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 - .../video/omap2/displays/panel-toppoly-tdo35s.c| 164 - 15 files changed, 497 insertions(+), 560 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c delete mode 100644 drivers/video/omap2/displays/panel-generic.c delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi,
Tomi Valkeinen wrote:
Hi,
Tomi Valkeinen wrote:
On Tue, 2010-11-16 at 12:22 +0100, ext Taneja, Archit wrote:
Hi,
Tomi Valkeinen wrote:
Hi,
[snip]
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 586944d..3e6eec1 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -434,6 +434,7 @@ struct omap_dss_device {
struct omap_overlay_manager *manager;
enum omap_dss_display_state state;
+ enum omap_channel channel;
Isn't this the same as dssdev-manager-id?
Yes, this channel stuff is a bit confusing, even the enum omap_channel
is badly named (should at least have dss in it). But
omap_overlay_manager should represent the output pipe, so I don't
think there's need for channel field in dss_device.
The panel somehow needs to tell which manager it is connected to. We
went with with the way of declaring a new member 'channel' and
setting that parameter up in the board file.
The current way to relate the manager and device is done by checking
the dssdev-type in dss_recheck_connections() and then calling set_device()
This is not sufficient any more since two of the managers can support
similar types of displays.
So in the channel approach the following happens:
-mgr-id's are initialized at bootup.
-devices and managers are connected using 'channel'.
-mgr-id automatically becomes equal to channel.
Can we set something like dssdev-manager-id in the board file itself?
Right, now I see.
The dss_recheck_connections() felt like a hack when I wrote it =).
Clearly we need some way to define in the board file which panel connects to
which manager.
It wasn't needed probably for OMAP3 since all non-venc panels
connect to LCD and venc to VENC type.
Now that I think of it, what channel would we mention if the
panel is used in dsi l4 update mode or dma mode? It should
have no manager at all.
Perhaps move the channel-field up, just below enum omap_display_type
type. The lines in the beginning of omap_dss_device are things which
define the interface etc, and later there are miscallaneous dynamic
things. And this belongs to the former.
Now, if we have the channel defined in this way in the
omap_dss_device, I'm wondering if:
1) the manager pointer is needed at all, as the channel tells which
manager it is? 2) if we keep the manager pointer (as a helper
shortcut), should the code use generally use
dssdev-channel or dssdev-manager-id?
I think manager-id makes more sense considering your logic below.
3) having this channel field requires a change to every board file,
because the channel has to be defined?
Yes, that is something that has to be done for all 'DIGIT'
panels across all boards.
And answering to myself, I guess the manager pointer is needed, because
DSS2 supports (at least in theory) multiple panels in the same
interface (not at the same time, of course). This means that we could
have to panels, with the same interface and channel, but only one
would be in use. So the one in use should have manager pointing to the
correct manager, and the other would have manager NULL.
Yes, passing dssdev-channel would make things worse if 2
panels are connected to same interface.
And thus perhaps using dssdev-channel only for connecting the right
manager to right panel, and using
dssdev-manager-id for other uses would be the best? The
values would of course be the same, but at least we'd get a crash if
somehow an unconnected display is being used for configuration.
Even in the current kernel on 3430sdp, the board file adds
sharp_ls, venc and generic panels If I boot up with venc as
default display, mgr0 has dvi as its display and mgr1 has tv.
So if I try to enable sharp_ls panel I get a crash when we
first try to access dssdev-manager in dpi_display_enable().
We should have a way to prevent enabling a panel if it isn't
connected to a manager. We should also have a way to allow a
panel to have no channel at all (something like
OMAP_DSS_CHANNEL_NONE) if we are using something like dsi l4 update.
I won't add this extra channel now though, we need to think
of a better way later.
Also, do you think when a display unsets a manager and sets a new manager
the channel should be changed? Or should it purely be a one time thing
for choosing the correct manager and not use it anywhere else?
Thanks,
Archit
Does this make sense?
Yes, it does, I'll make these changes, and more if you can
think of any.
Archit--
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
Re: [PATCH] omap: prcm: switch to a chained IRQ handler mechanism
Hi Thomas,
On 11/17/2010 1:16 PM, Thomas Petazzoni wrote:
From: Thomas Petazzonit-petazz...@ti.com
[...]
static int __init omap3_pm_init(void)
That code is purely OMAP3 specific, do you think it might scale well on
OMAP4?
BTW, you should maybe change the subject with OMAP3: prcm: ... to
reflect that.
{
struct power_state *pwrst, *tmp;
struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
- int ret;
+ int ret, i;
if (!cpu_is_omap34xx())
return -ENODEV;
@@ -1013,19 +1053,34 @@ static int __init omap3_pm_init(void)
* supervised mode for powerdomains */
prcm_setup_regs();
- ret = request_irq(INT_34XX_PRCM_MPU_IRQ,
- (irq_handler_t)prcm_interrupt_handler,
- IRQF_DISABLED, prcm, NULL);
+ for (i = OMAP_PRCM_IRQ_BASE; i OMAP_PRCM_IRQ_END; i++) {
+ set_irq_chip(i,prcm_irq_chip);
+ set_irq_handler(i, handle_level_irq);
+ set_irq_flags(i, IRQF_VALID);
+ }
+
+ set_irq_chained_handler(INT_34XX_PRCM_MPU_IRQ, prcm_irq_handler);
+
+ ret = request_irq(INT_34XX_PRCM_WKUP_EN, _prcm_int_handle_wakeup,
+ IRQF_NO_SUSPEND, prcm_wkup, NULL);
if (ret) {
printk(KERN_ERR request_irq failed to register for 0x%x\n,
OK, I know, this is not your code, but it might be good to get rid of
the printk(KERN_ERR... and use pr_err instead.
- INT_34XX_PRCM_MPU_IRQ);
+ INT_34XX_PRCM_WKUP_EN);
goto err1;
}
+ ret = request_irq(INT_34XX_PRCM_IO_EN, _prcm_int_handle_wakeup,
+ IRQF_NO_SUSPEND, prcm_io, NULL);
+ if (ret) {
+ printk(KERN_ERR request_irq failed to register for 0x%x\n,
+ INT_34XX_PRCM_IO_EN);
+ goto err2;
+ }
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\n);
- goto err2;
+ goto err3;
}
(void) clkdm_for_each(clkdms_setup, NULL);
@@ -1033,7 +1088,7 @@ static int __init omap3_pm_init(void)
mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
if (mpu_pwrdm == NULL) {
printk(KERN_ERR Failed to get mpu_pwrdm\n);
- goto err2;
+ goto err3;
}
neon_pwrdm = pwrdm_lookup(neon_pwrdm);
@@ -1080,7 +1135,9 @@ static int __init omap3_pm_init(void)
err1:
return ret;
err2:
- free_irq(INT_34XX_PRCM_MPU_IRQ, NULL);
+ free_irq(INT_34XX_PRCM_WKUP_EN, NULL);
+err3:
+ free_irq(INT_34XX_PRCM_IO_EN, NULL);
list_for_each_entry_safe(pwrst, tmp,pwrst_list, node) {
list_del(pwrst-node);
kfree(pwrst);
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 65e20a6..6c5eb1c 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -363,7 +363,43 @@
#define OMAP_MAX_GPIO_LINES 192
#define IH_GPIO_BASE (128 + IH2_BASE)
#define IH_MPUIO_BASE (OMAP_MAX_GPIO_LINES + IH_GPIO_BASE)
-#define OMAP_IRQ_END (IH_MPUIO_BASE + 16)
+#define OMAP_MPUIO_IRQ_END (IH_MPUIO_BASE + 16)
+
+/* 32 IRQs for the PRCM */
+#define OMAP_PRCM_IRQ_BASE (OMAP_MPUIO_IRQ_END)
+#define INT_34XX_PRCM_WKUP_EN (OMAP_PRCM_IRQ_BASE + 0)
+#define INT_34XX_PRCM_EVGENON_EN (OMAP_PRCM_IRQ_BASE + 2)
+#define INT_34XX_PRCM_EVGENOFF_EN (OMAP_PRCM_IRQ_BASE + 3)
+#define INT_34XX_PRCM_TRANSITION_EN(OMAP_PRCM_IRQ_BASE + 4)
+#define INT_34XX_PRCM_CORE_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 5)
+#define INT_34XX_PRCM_PERIPH_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 6)
+#define INT_34XX_PRCM_MPU_DPLL_RECAL_EN_EN (OMAP_PRCM_IRQ_BASE + 7)
+#define INT_34XX_PRCM_IVA2_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 8)
+#define INT_34XX_PRCM_IO_EN(OMAP_PRCM_IRQ_BASE + 9)
+#define INT_34XX_PRCM_VP1_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 10)
+#define INT_34XX_PRCM_VP1_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 11)
+#define INT_34XX_PRCM_VP1_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 12)
+#define INT_34XX_PRCM_VP1_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 13)
+#define INT_34XX_PRCM_VP1_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 14)
+#define INT_34XX_PRCM_VP1_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 15)
+#define INT_34XX_PRCM_VP2_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 16)
+#define INT_34XX_PRCM_VP2_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 17)
+#define INT_34XX_PRCM_VP2_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 18)
+#define INT_34XX_PRCM_VP2_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 19)
+#define INT_34XX_PRCM_VP2_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 20)
+#define INT_34XX_PRCM_VP2_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 21)
+#define INT_34XX_PRCM_VC_SAERR_EN (OMAP_PRCM_IRQ_BASE
[PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #8)
There are 4 duplicated DPI panel drivers in DSS2 display driver. They are similar and a generic DPI panel driver can support all them with specific panel configuration. And new DPI panel driver can be easily supported by adding panel configurations into generic panel DPI driver. This patchset introduces a generic panel DPI driver, remove 3 panel drivers and enable generic panel DPI driver in board files. And it is based on 2.6.37-rc2. Building with omap2plus_defconfig is successful. Keep sharp_ls_panel, since it contains blacklight control code which will be moved out later. Bryan Wu (3): OMAP: DSS2: Add generic DPI panel display driver OMAP: use generic DPI panel driver in board files OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers arch/arm/mach-omap2/board-3430sdp.c| 12 +- arch/arm/mach-omap2/board-am3517evm.c | 23 +- arch/arm/mach-omap2/board-cm-t35.c | 23 +- arch/arm/mach-omap2/board-devkit8000.c | 26 +- arch/arm/mach-omap2/board-igep0020.c | 12 +- arch/arm/mach-omap2/board-omap3beagle.c| 12 +- arch/arm/mach-omap2/board-omap3evm.c | 12 +- arch/arm/mach-omap2/board-omap3stalker.c | 23 +- .../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++ drivers/video/omap2/displays/Kconfig | 22 +- drivers/video/omap2/displays/Makefile |4 +- drivers/video/omap2/displays/panel-generic-dpi.c | 355 drivers/video/omap2/displays/panel-generic.c | 174 -- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 - .../video/omap2/displays/panel-toppoly-tdo35s.c| 164 - 15 files changed, 504 insertions(+), 560 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c delete mode 100644 drivers/video/omap2/displays/panel-generic.c delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- 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/3] OMAP: DSS2: Add generic DPI panel display driver
Generic DPI panel driver includes the driver and 4 similar panel
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 355
4 files changed, 401 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
diff --git a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..7906197
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,37 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.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/.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+#define __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+#include display.h
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+#endif /* __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H */
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..cb3e339 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,6 +1,14 @@
menu OMAP2/3 Display Device Drivers
depends on OMAP2_DSS
+config PANEL_GENERIC_DPI
+tristate Generic DPI Panel
+help
+ Generic DPI panel driver.
+ Supports DVI output for Beagle and OMAP3 SDP.
+ Supports LCD Panel used in TI SDP3430 and EVM boards,
+ OMAP3517 EVM boards and CM-T35.
+
config PANEL_GENERIC
tristate Generic Panel
help
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..022058c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
new file mode 100644
index 000..6702cf6
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -0,0 +1,355 @@
+/*
+ * Generic DPI Panels support
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * 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 linux/slab.h
+
+#include plat/panel-generic-dpi.h
+
+struct panel_config {
+ struct omap_video_timings timings;
+
+ int acbi; /* ac-bias pin transitions per interrupt */
+ /* Unit: line clocks */
+ int acb;/* ac-bias pin frequency */
+
+
[PATCH 2/3] OMAP: use generic DPI panel driver in board files
Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight
control driver code which will be moved out later. Then we can use generic DPI
driver for sharp_ls_panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-omap2/board-3430sdp.c | 12 +---
arch/arm/mach-omap2/board-am3517evm.c| 23 +--
arch/arm/mach-omap2/board-cm-t35.c | 23 +--
arch/arm/mach-omap2/board-devkit8000.c | 26 ++
arch/arm/mach-omap2/board-igep0020.c | 12 +---
arch/arm/mach-omap2/board-omap3beagle.c | 12 +---
arch/arm/mach-omap2/board-omap3evm.c | 12 +---
arch/arm/mach-omap2/board-omap3stalker.c | 23 +--
8 files changed, 105 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..1ca0156 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -38,6 +38,7 @@
#include plat/dma.h
#include plat/gpmc.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include plat/gpmc-smc91x.h
@@ -270,13 +271,18 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable = sdp3430_panel_disable_lcd,
};
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= sdp3430_panel_enable_dvi,
+ .platform_disable = sdp3430_panel_disable_dvi,
+};
+
static struct omap_dss_device sdp3430_dvi_device = {
.name = dvi,
- .driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
.phy.dpi.data_lines = 24,
- .platform_enable= sdp3430_panel_enable_dvi,
- .platform_disable = sdp3430_panel_disable_dvi,
};
static struct omap_dss_device sdp3430_tv_device = {
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..851683f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
#include plat/common.h
#include plat/usb.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include mux.h
#include control.h
@@ -303,13 +304,18 @@ static void am3517_evm_panel_disable_lcd(struct
omap_dss_device *dssdev)
lcd_enabled = 0;
}
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = sharp_lq,
+ .platform_enable= am3517_evm_panel_enable_lcd,
+ .platform_disable = am3517_evm_panel_disable_lcd,
+};
+
static struct omap_dss_device am3517_evm_lcd_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = lcd,
- .driver_name= sharp_lq_panel,
+ .driver_name= generic_dpi_panel,
+ .data = lcd_panel,
.phy.dpi.data_lines = 16,
- .platform_enable= am3517_evm_panel_enable_lcd,
- .platform_disable = am3517_evm_panel_disable_lcd,
};
static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -346,13 +352,18 @@ static void am3517_evm_panel_disable_dvi(struct
omap_dss_device *dssdev)
dvi_enabled = 0;
}
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= am3517_evm_panel_enable_dvi,
+ .platform_disable = am3517_evm_panel_disable_dvi,
+};
+
static struct omap_dss_device am3517_evm_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
- .driver_name= generic_panel,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
.phy.dpi.data_lines = 24,
- .platform_enable= am3517_evm_panel_enable_dvi,
- .platform_disable = am3517_evm_panel_disable_dvi,
};
static struct omap_dss_device *am3517_evm_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..e91c986 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -46,6 +46,7 @@
#include plat/gpmc.h
#include plat/usb.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include plat/mcspi.h
#include mach/hardware.h
@@ -351,22 +352,32 @@ static void cm_t35_panel_disable_tv(struct
omap_dss_device *dssdev)
{
}
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = toppoly_tdo35s,
+ .platform_enable= cm_t35_panel_enable_lcd,
+ .platform_disable = cm_t35_panel_disable_lcd,
+};
+
static struct omap_dss_device cm_t35_lcd_device = {
.name
[PATCH 3/3] OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
Still keep sharp_ls_panel driver, because it contains blacklight control driver.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/omap2/displays/Kconfig | 18 --
drivers/video/omap2/displays/Makefile |3 -
drivers/video/omap2/displays/panel-generic.c | 174
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 ---
.../video/omap2/displays/panel-toppoly-tdo35s.c| 164 --
5 files changed, 0 insertions(+), 524 deletions(-)
delete mode 100644 drivers/video/omap2/displays/panel-generic.c
delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index cb3e339..9c09afd 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -9,12 +9,6 @@ config PANEL_GENERIC_DPI
Supports LCD Panel used in TI SDP3430 and EVM boards,
OMAP3517 EVM boards and CM-T35.
-config PANEL_GENERIC
-tristate Generic Panel
-help
- Generic panel driver.
- Used for DVI output for Beagle and OMAP3 SDP.
-
config PANEL_SHARP_LS037V7DW01
tristate Sharp LS037V7DW01 LCD Panel
depends on OMAP2_DSS
@@ -22,24 +16,12 @@ config PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
-config PANEL_SHARP_LQ043T1DG01
-tristate Sharp LQ043T1DG01 LCD Panel
-depends on OMAP2_DSS
-help
- LCD Panel used in TI's OMAP3517 EVM boards
-
config PANEL_TAAL
tristate Taal DSI Panel
depends on OMAP2_DSS_DSI
help
Taal DSI command mode panel from TPO.
-config PANEL_TOPPOLY_TDO35S
-tristate Toppoly TDO35S LCD Panel support
-depends on OMAP2_DSS
-help
- LCD Panel used in CM-T35
-
config PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on OMAP2_DSS SPI
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 022058c..3bebe4d 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,9 +1,6 @@
obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
-obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
-obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
-obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
deleted file mode 100644
index 395a68d..000
--- a/drivers/video/omap2/displays/panel-generic.c
+++ /dev/null
@@ -1,174 +0,0 @@
-/*
- * 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 plat/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_power_on(struct omap_dss_device *dssdev)
-{
- int r;
-
- if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
- return 0;
-
- r = omapdss_dpi_display_enable(dssdev);
- if (r)
- goto err0;
-
- if (dssdev-platform_enable) {
- r = dssdev-platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
- return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
-err0:
- return r;
-}
-
-static void generic_panel_power_off(struct omap_dss_device *dssdev)
-{
- if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
- return;
-
- if (dssdev-platform_disable)
- dssdev-platform_disable(dssdev);
-
-
Re: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
On Wed, Nov 17, 2010 at 8:44 PM, Tomi Valkeinen
tomi.valkei...@nokia.com wrote:
On Wed, 2010-11-17 at 10:23 +0800, ext Bryan Wu wrote:
Generic DPI panel driver includes the driver and 4 similar panel
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig | 8 +
drivers/video/omap2/displays/Makefile | 1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 348
4 files changed, 394 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
[snip]
+
+static void generic_dpi_panel_remove(struct omap_dss_device *dssdev)
+{
+}
You need to free the drv_data here.
Perhaps this will be the last fix =).
My bad, I just sent out the 8th version for review. Moreover, I think
in panel-taal.c it also misses call dev_set_drvdata(dssdev-dev,
NULL); after we kfree(td) in taal_remove().
Thanks,
--
Bryan Wu bryan...@canonical.com
Kernel Developer +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
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 0/3] OMAP: DSS2: introduce generic panel display driver (try #8)
On Wed, 2010-11-17 at 21:34 +0800, ext Bryan Wu wrote: There are 4 duplicated DPI panel drivers in DSS2 display driver. They are similar and a generic DPI panel driver can support all them with specific panel configuration. And new DPI panel driver can be easily supported by adding panel configurations into generic panel DPI driver. This patchset introduces a generic panel DPI driver, remove 3 panel drivers and enable generic panel DPI driver in board files. And it is based on 2.6.37-rc2. Building with omap2plus_defconfig is successful. Keep sharp_ls_panel, since it contains blacklight control code which will be moved out later. Bryan Wu (3): OMAP: DSS2: Add generic DPI panel display driver OMAP: use generic DPI panel driver in board files OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers Thanks, looks good. This is now applied to my tree. Are you also interested in solving the backlight issue? =) 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
[PATCH] OMAP3: add comments for erratas i540 and i478 workarounds
From: Jean Pihet jean.pi...@newoldbits.com
Add comments and IDs for the following erratas:
- i540: MPU cannot exit from Standby,
- i478: Unexpected Cold-Reset is generated when device is coming
back from OFF mode
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/irq.c |3 ++-
arch/arm/mach-omap2/powerdomains34xx.h |6 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 32eeabe..e28b417 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -284,7 +284,8 @@ void omap3_intc_suspend(void)
void omap3_intc_prepare_idle(void)
{
- /* Disable autoidle as it can stall interrupt controller */
+ /* Disable autoidle as it can stall interrupt controller,
+* Cf. errata ID i540 for 3430 (all revisions up to 3.1.x) */
intc_bank_write_reg(0, irq_banks[0], INTC_SYSCONFIG);
}
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index fa90486..349f2bf 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -80,6 +80,10 @@ static struct powerdomain mpu_3xxx_pwrdm = {
* 3430s upto ES3.0 and 3630ES1.0. Hence this feature
* needs to be disabled on these chips.
* Refer: 3430 errata ID i459 and 3630 errata ID i579
+ *
+ * Note: setting the SAR flag could help for errata ID i478
+ * which applies to 3430 = ES3.1, but since the SAR feature
+ * is broken, do not use it.
*/
static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
.name = core_pwrdm,
@@ -108,6 +112,8 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
CHIP_GE_OMAP3630ES1_1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
+ /* Setting the SAR flag for errata ID i478 which applies
+* to 3430 = ES3.1 */
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
.banks= 2,
.pwrsts_mem_ret = {
--
1.7.2.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
RE: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Bryan Wu
Sent: Wednesday, November 17, 2010 7:05 PM
To: tomi.valkei...@nokia.com; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Gadiyar, Anand
Subject: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
Generic DPI panel driver includes the driver and 4 similar
panel configurations. It
will match the panel name which is passed from platform data
and setup the
right configurations.
With generic DPI panel driver, we can remove those 4
duplicated panel display
drivers. In the future, it is simple for us just add new
panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 355
4 files changed, 401 insertions(+), 0 deletions(-)
create mode 100644
arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
diff --git
a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..7906197
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,37 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.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/.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+#define __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+#include display.h
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+#endif /* __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H */
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..cb3e339 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,6 +1,14 @@
menu OMAP2/3 Display Device Drivers
depends on OMAP2_DSS
+config PANEL_GENERIC_DPI
+tristate Generic DPI Panel
+help
+ Generic DPI panel driver.
+ Supports DVI output for Beagle and OMAP3 SDP.
+ Supports LCD Panel used in TI SDP3430 and EVM boards,
+ OMAP3517 EVM boards and CM-T35.
+
config PANEL_GENERIC
tristate Generic Panel
help
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..022058c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
new file mode 100644
index 000..6702cf6
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -0,0 +1,355 @@
+/*
+ * Generic DPI Panels support
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
[sp] Shouldn't all authors (from the files being coalesced) be
listed here.
I see this missing from PATCH3/3 in your series:
[quote]
- * LCD panel driver for Sharp LQ043T1DG01
- *
- * Copyright (C) 2009 Texas Instruments Inc
- * Author: Vaibhav Hiremath hvaib...@ti.com
- *
[/quote]
[snip]...[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
Re: [PATCH] omap: prcm: switch to a chained IRQ handler mechanism
Cousson, Benoit b-cous...@ti.com writes: [...] +#define OMAP_MPUIO_IRQ_END (IH_MPUIO_BASE + 16) + +/* 32 IRQs for the PRCM */ +#define OMAP_PRCM_IRQ_BASE (OMAP_MPUIO_IRQ_END) +#define INT_34XX_PRCM_WKUP_EN (OMAP_PRCM_IRQ_BASE + 0) +#define INT_34XX_PRCM_EVGENON_EN (OMAP_PRCM_IRQ_BASE + 2) +#define INT_34XX_PRCM_EVGENOFF_EN (OMAP_PRCM_IRQ_BASE + 3) +#define INT_34XX_PRCM_TRANSITION_EN(OMAP_PRCM_IRQ_BASE + 4) +#define INT_34XX_PRCM_CORE_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 5) +#define INT_34XX_PRCM_PERIPH_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 6) +#define INT_34XX_PRCM_MPU_DPLL_RECAL_EN_EN (OMAP_PRCM_IRQ_BASE + 7) +#define INT_34XX_PRCM_IVA2_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 8) +#define INT_34XX_PRCM_IO_EN(OMAP_PRCM_IRQ_BASE + 9) +#define INT_34XX_PRCM_VP1_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 10) +#define INT_34XX_PRCM_VP1_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 11) +#define INT_34XX_PRCM_VP1_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 12) +#define INT_34XX_PRCM_VP1_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 13) +#define INT_34XX_PRCM_VP1_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 14) +#define INT_34XX_PRCM_VP1_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 15) +#define INT_34XX_PRCM_VP2_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 16) +#define INT_34XX_PRCM_VP2_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 17) +#define INT_34XX_PRCM_VP2_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 18) +#define INT_34XX_PRCM_VP2_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 19) +#define INT_34XX_PRCM_VP2_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 20) +#define INT_34XX_PRCM_VP2_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 21) +#define INT_34XX_PRCM_VC_SAERR_EN (OMAP_PRCM_IRQ_BASE + 22) +#define INT_34XX_PRCM_VC_RAERR_EN (OMAP_PRCM_IRQ_BASE + 23) +#define INT_34XX_PRCM_VC_TIMEOUT_ERR_EN(OMAP_PRCM_IRQ_BASE + 24) +#define INT_34XX_PRCM_SND_PERIPH_RECAL_EN (OMAP_PRCM_IRQ_BASE + 25) +#define INT_36XX_PRCM_ABB_LDO_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 26) +#define INT_36XX_PRCM_VC_VP1_ACK_EN(OMAP_PRCM_IRQ_BASE + 27) +#define INT_36XX_PRCM_VC_BYPASS_ACK_EN (OMAP_PRCM_IRQ_BASE + 28) +#define OMAP_PRCM_NR_IRQS 32 +#define OMAP_PRCM_IRQ_END (OMAP_PRCM_IRQ_BASE + \ +OMAP_PRCM_NR_IRQS) We are in the process of getting rid of all the IRQ defines thanks to hwmod. Maybe we should consider moving that to hwmod data? I'm not sure exactly how we will handle that case but it might worth considering it. What hwmod would these be attached to? I guess that would mean creating a hwmod for the PRM, and attatching the IRQs there? Taht being said, is hwmod the right place for these virtual IRQs? These IRQs are internal to that IP, and not really integration IRQs. If we do want to make that code OMAP generic, we will probably have to. That being said, that patch is already a good improvement compared to the previous solution. So maybe we should do that in several phases. Kevin, Any thoughts on that? I think this needs some more discussion, and probably a separate phase since we don't currently have hwmods for PRM or CM, at least on OMAP3. 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
Re: [PATCH] OMAP: Serial: Define register access modes in LCR
On Wed, Nov 17, 2010 at 10:31:52AM +0200, Emeltchenko Andrei wrote: From: Andrei Emeltchenko andrei.emeltche...@nokia.com Access to some registers depends on register access mode Three different modes are available for OMAP (at least) • Operational mode LCR_REG[7] = 0x0 • Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF • Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF Define access modes and remove redefinitions and magic numbers in serial drivers (and later in bluetooth driver). Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com --- arch/arm/mach-omap2/serial.c | 12 arch/arm/plat-omap/include/plat/omap-serial.h |9 -- drivers/serial/8250.c | 26 +- drivers/serial/omap-serial.c | 34 include/linux/serial_reg.h|7 + What tree should this go through? THe omap or serial one? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: prcm: switch to a chained IRQ handler mechanism
On 11/17/2010 5:16 PM, Kevin Hilman wrote: Cousson, Benoitb-cous...@ti.com writes: [...] +#define OMAP_MPUIO_IRQ_END (IH_MPUIO_BASE + 16) + +/* 32 IRQs for the PRCM */ +#define OMAP_PRCM_IRQ_BASE (OMAP_MPUIO_IRQ_END) +#define INT_34XX_PRCM_WKUP_EN (OMAP_PRCM_IRQ_BASE + 0) +#define INT_34XX_PRCM_EVGENON_EN (OMAP_PRCM_IRQ_BASE + 2) +#define INT_34XX_PRCM_EVGENOFF_EN (OMAP_PRCM_IRQ_BASE + 3) +#define INT_34XX_PRCM_TRANSITION_EN(OMAP_PRCM_IRQ_BASE + 4) +#define INT_34XX_PRCM_CORE_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 5) +#define INT_34XX_PRCM_PERIPH_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 6) +#define INT_34XX_PRCM_MPU_DPLL_RECAL_EN_EN (OMAP_PRCM_IRQ_BASE + 7) +#define INT_34XX_PRCM_IVA2_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 8) +#define INT_34XX_PRCM_IO_EN(OMAP_PRCM_IRQ_BASE + 9) +#define INT_34XX_PRCM_VP1_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 10) +#define INT_34XX_PRCM_VP1_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 11) +#define INT_34XX_PRCM_VP1_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 12) +#define INT_34XX_PRCM_VP1_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 13) +#define INT_34XX_PRCM_VP1_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 14) +#define INT_34XX_PRCM_VP1_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 15) +#define INT_34XX_PRCM_VP2_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 16) +#define INT_34XX_PRCM_VP2_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 17) +#define INT_34XX_PRCM_VP2_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 18) +#define INT_34XX_PRCM_VP2_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 19) +#define INT_34XX_PRCM_VP2_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 20) +#define INT_34XX_PRCM_VP2_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 21) +#define INT_34XX_PRCM_VC_SAERR_EN (OMAP_PRCM_IRQ_BASE + 22) +#define INT_34XX_PRCM_VC_RAERR_EN (OMAP_PRCM_IRQ_BASE + 23) +#define INT_34XX_PRCM_VC_TIMEOUT_ERR_EN(OMAP_PRCM_IRQ_BASE + 24) +#define INT_34XX_PRCM_SND_PERIPH_RECAL_EN (OMAP_PRCM_IRQ_BASE + 25) +#define INT_36XX_PRCM_ABB_LDO_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 26) +#define INT_36XX_PRCM_VC_VP1_ACK_EN(OMAP_PRCM_IRQ_BASE + 27) +#define INT_36XX_PRCM_VC_BYPASS_ACK_EN (OMAP_PRCM_IRQ_BASE + 28) +#define OMAP_PRCM_NR_IRQS 32 +#define OMAP_PRCM_IRQ_END (OMAP_PRCM_IRQ_BASE + \ + OMAP_PRCM_NR_IRQS) We are in the process of getting rid of all the IRQ defines thanks to hwmod. Maybe we should consider moving that to hwmod data? I'm not sure exactly how we will handle that case but it might worth considering it. What hwmod would these be attached to? I guess that would mean creating a hwmod for the PRM, and attatching the IRQs there? Yep. I already have that in some of my secret branches, because, I'd like at some point to leverage hwmod data even for infrastructure code (prcm, control module). Taht being said, is hwmod the right place for these virtual IRQs? These IRQs are internal to that IP, and not really integration IRQs. Well, yes, that's why I was wondering as well if hwmod data is the right place. Anyway, we should probably consider a table with the same kind of information hwmod is using in order to have a flexible management for every OMAPs. If we do want to make that code OMAP generic, we will probably have to. That being said, that patch is already a good improvement compared to the previous solution. So maybe we should do that in several phases. Kevin, Any thoughts on that? I think this needs some more discussion, and probably a separate phase since we don't currently have hwmods for PRM or CM, at least on OMAP3. That part is easy to fix... We just have to create them :-) Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Serial: Define register access modes in LCR
Greg KH g...@kroah.com writes: On Wed, Nov 17, 2010 at 10:31:52AM +0200, Emeltchenko Andrei wrote: From: Andrei Emeltchenko andrei.emeltche...@nokia.com Access to some registers depends on register access mode Three different modes are available for OMAP (at least) • Operational mode LCR_REG[7] = 0x0 • Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF • Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF Define access modes and remove redefinitions and magic numbers in serial drivers (and later in bluetooth driver). Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com --- arch/arm/mach-omap2/serial.c | 12 arch/arm/plat-omap/include/plat/omap-serial.h |9 -- drivers/serial/8250.c | 26 +- drivers/serial/omap-serial.c | 34 include/linux/serial_reg.h|7 + What tree should this go through? THe omap or serial one? Since this only affects OMAP drivers, we can take this through OMAP. That will also help us avoid conflicts, as we'll hopefully be converting the omap-serial driver to runtime PM for this next merge window as well. 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
Re: [PATCH] OMAP: Serial: Define register access modes in LCR
On Wed, Nov 17, 2010 at 09:28:52AM -0800, Kevin Hilman wrote: Greg KH g...@kroah.com writes: On Wed, Nov 17, 2010 at 10:31:52AM +0200, Emeltchenko Andrei wrote: From: Andrei Emeltchenko andrei.emeltche...@nokia.com Access to some registers depends on register access mode Three different modes are available for OMAP (at least) • Operational mode LCR_REG[7] = 0x0 • Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF • Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF Define access modes and remove redefinitions and magic numbers in serial drivers (and later in bluetooth driver). Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com --- arch/arm/mach-omap2/serial.c | 12 arch/arm/plat-omap/include/plat/omap-serial.h |9 -- drivers/serial/8250.c | 26 +- drivers/serial/omap-serial.c | 34 include/linux/serial_reg.h|7 + What tree should this go through? THe omap or serial one? Since this only affects OMAP drivers, we can take this through OMAP. That will also help us avoid conflicts, as we'll hopefully be converting the omap-serial driver to runtime PM for this next merge window as well. Fine with me, feel free to add: Acked-by: Greg Kroah-Hartman gre...@suse.de to it. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: add comments for erratas i540 and i478 workarounds
Jean Pihet jean.pi...@newoldbits.com writes:
From: Jean Pihet jean.pi...@newoldbits.com
Add comments and IDs for the following erratas:
- i540: MPU cannot exit from Standby,
- i478: Unexpected Cold-Reset is generated when device is coming
back from OFF mode
Signed-off-by: Jean Pihet j-pi...@ti.com
Nice, it's great to have the errata numbers in the code.
Minor comment, please fix up the multi-line comment style to follow
CodingStyle. Search for 'multi-line' in Documentation/CodingStyle.
Kevin
---
arch/arm/mach-omap2/irq.c |3 ++-
arch/arm/mach-omap2/powerdomains34xx.h |6 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 32eeabe..e28b417 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -284,7 +284,8 @@ void omap3_intc_suspend(void)
void omap3_intc_prepare_idle(void)
{
- /* Disable autoidle as it can stall interrupt controller */
+ /* Disable autoidle as it can stall interrupt controller,
+ * Cf. errata ID i540 for 3430 (all revisions up to 3.1.x) */
intc_bank_write_reg(0, irq_banks[0], INTC_SYSCONFIG);
}
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index fa90486..349f2bf 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -80,6 +80,10 @@ static struct powerdomain mpu_3xxx_pwrdm = {
* 3430s upto ES3.0 and 3630ES1.0. Hence this feature
* needs to be disabled on these chips.
* Refer: 3430 errata ID i459 and 3630 errata ID i579
+ *
+ * Note: setting the SAR flag could help for errata ID i478
+ * which applies to 3430 = ES3.1, but since the SAR feature
+ * is broken, do not use it.
*/
static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
.name = core_pwrdm,
@@ -108,6 +112,8 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
CHIP_GE_OMAP3630ES1_1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
+ /* Setting the SAR flag for errata ID i478 which applies
+ * to 3430 = ES3.1 */
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
.banks= 2,
.pwrsts_mem_ret = {
--
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] OMAP3: add comments for erratas i540 and i478 workarounds
From: Jean Pihet jean.pi...@newoldbits.com
Add comments and IDs for the following erratas:
- i540: MPU cannot exit from Standby,
- i478: Unexpected Cold-Reset is generated when device is coming
back from OFF mode
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/irq.c |5 -
arch/arm/mach-omap2/powerdomains34xx.h |8
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 32eeabe..85bf8ca 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -284,7 +284,10 @@ void omap3_intc_suspend(void)
void omap3_intc_prepare_idle(void)
{
- /* Disable autoidle as it can stall interrupt controller */
+ /*
+* Disable autoidle as it can stall interrupt controller,
+* cf. errata ID i540 for 3430 (all revisions up to 3.1.x)
+*/
intc_bank_write_reg(0, irq_banks[0], INTC_SYSCONFIG);
}
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index fa90486..ce5c15b 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -80,6 +80,10 @@ static struct powerdomain mpu_3xxx_pwrdm = {
* 3430s upto ES3.0 and 3630ES1.0. Hence this feature
* needs to be disabled on these chips.
* Refer: 3430 errata ID i459 and 3630 errata ID i579
+ *
+ * Note: setting the SAR flag could help for errata ID i478
+ * which applies to 3430 = ES3.1, but since the SAR feature
+ * is broken, do not use it.
*/
static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
.name = core_pwrdm,
@@ -108,6 +112,10 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
CHIP_GE_OMAP3630ES1_1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
+ /*
+* Setting the SAR flag for errata ID i478 which applies
+* to 3430 = ES3.1
+*/
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
.banks= 2,
.pwrsts_mem_ret = {
--
1.7.2.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] OMAP MUX framework changes
Added APIs to get and set the mux setting via the MUX
name. In doing this the omap_mux_read and omap_mux_write can
be made static as these interfaces should be called indirectly.
Added a check in the omap_write_array to test the partition pointer
is valid prior to dereferencing.
Tested the new interfaces with a test file.
Signed-off-by: Dan Murphy dmur...@ti.com
---
arch/arm/mach-omap2/mux.c | 73 +
arch/arm/mach-omap2/mux.h | 23 ++
2 files changed, 77 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 3d71d93..e53d6a3 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -61,7 +61,7 @@ struct omap_mux_partition *omap_mux_get(const char *name)
return NULL;
}
-u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
+static u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
{
if (partition-flags OMAP_MUX_REG_8BIT)
return __raw_readb(partition-base + reg);
@@ -69,7 +69,7 @@ u16 omap_mux_read(struct omap_mux_partition *partition, u16
reg)
return __raw_readw(partition-base + reg);
}
-void omap_mux_write(struct omap_mux_partition *partition, u16 val,
+static void omap_mux_write(struct omap_mux_partition *partition, u16 val,
u16 reg)
{
if (partition-flags OMAP_MUX_REG_8BIT)
@@ -81,10 +81,14 @@ void omap_mux_write(struct omap_mux_partition *partition,
u16 val,
void omap_mux_write_array(struct omap_mux_partition *partition,
struct omap_board_mux *board_mux)
{
- while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
- omap_mux_write(partition, board_mux-value,
- board_mux-reg_offset);
- board_mux++;
+ if (partition) {
+ while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
+ omap_mux_write(partition, board_mux-value,
+ board_mux-reg_offset);
+ board_mux++;
+ }
+ } else {
+ pr_err(%s: Partition was NULL\n, __func__);
}
}
@@ -745,6 +749,63 @@ void omap_mux_set_gpio(u16 val, int gpio)
pr_err(%s: Could not set gpio%i\n, __func__, gpio);
}
+static struct omap_mux *omap_mux_get_by_mux(struct omap_mux_partition
*partition,
+ char *name)
+{
+ struct omap_mux_entry *e;
+ int i = 0;
+
+ list_for_each_entry(e, partition-muxmodes, node) {
+ struct omap_mux *m = e-mux;
+ for (i = 0; i OMAP_MUX_NR_MODES; i++) {
+ if (m-muxnames[i] == NULL)
+ break;
+ else if (!strcmp(name, m-muxnames[i]))
+ return m;
+ }
+ }
+
+ return NULL;
+}
+
+/* Needed for dynamic muxing of pins for off-idle */
+u16 omap_mux_get_mux(char *mux_name)
+{
+ struct omap_mux_partition *partition;
+ struct omap_mux *m;
+
+ list_for_each_entry(partition, mux_partitions, node) {
+ m = omap_mux_get_by_mux(partition, mux_name);
+ if (m)
+ return omap_mux_read(partition, m-reg_offset);
+ }
+
+ if (!m || m-reg_offset == OMAP_MUX_TERMINATOR)
+ pr_err(%s: Could not get mux %s\n,
+ __func__, mux_name);
+
+ return OMAP_MUX_TERMINATOR;
+}
+
+/* Needed for dynamic muxing pins for off-idle */
+void omap_mux_set_mux(u16 val, char *mux_name)
+{
+ struct omap_mux_partition *partition;
+ struct omap_mux *m = NULL;
+
+ list_for_each_entry(partition, mux_partitions, node) {
+ m = omap_mux_get_by_mux(partition, mux_name);
+ if (m) {
+ omap_mux_write(partition, val, m-reg_offset);
+ return;
+ }
+ }
+
+ if (!m || m-reg_offset == OMAP_MUX_TERMINATOR)
+ pr_err(%s: Could not set mux %s\n,
+ __func__, mux_name);
+}
+
static struct omap_mux * __init omap_mux_list_add(
struct omap_mux_partition *partition,
struct omap_mux *src)
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 79076d6..27ce55a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -190,29 +190,26 @@ u16 omap_mux_get_gpio(int gpio);
void omap_mux_set_gpio(u16 val, int gpio);
/**
- * omap_mux_get() - get a mux partition by name
- * @name: Name of the mux partition
+ * omap_mux_get_mux() - set mux register value based on mux name
+ * @mux_name: Mux name
*
*/
-struct omap_mux_partition *omap_mux_get(const char *name);
+u16 omap_mux_get_mux(char *mux_name);
/**
- * omap_mux_read() -
Re: [PATCH 2/3] OMAP: VRAM: Fix boot-time memory allocation
On Wed, Nov 10, 2010 at 11:45 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Use memblock_free() and memblock_remove() to remove the allocated or reserved VRAM area from normal kernel memory. This is a slightly modified version of patches from Felipe Contreras and Namhyung Kim. Reported-by: Felipe Contreras felipe.contre...@gmail.com Reported-by: Namhyung Kim namhy...@gmail.com Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com I would have kept these as two separate patches as they do two different things: 1) Fix a build error 2) Prepare for future ioremap() changes[1] The current patch mentions 1) in the summary, and 2) in the commit message, but it doesn't explain why 2) is needed. Maybe for the next time. Cheers. [1] http://article.gmane.org/gmane.linux.ports.arm.omap/44978 -- Felipe Contreras -- 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] OMAP: Serial: Define register access modes in LCR
* Greg KH g...@kroah.com [101117 09:21]: On Wed, Nov 17, 2010 at 09:28:52AM -0800, Kevin Hilman wrote: Greg KH g...@kroah.com writes: On Wed, Nov 17, 2010 at 10:31:52AM +0200, Emeltchenko Andrei wrote: From: Andrei Emeltchenko andrei.emeltche...@nokia.com Access to some registers depends on register access mode Three different modes are available for OMAP (at least) • Operational mode LCR_REG[7] = 0x0 • Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF • Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF Define access modes and remove redefinitions and magic numbers in serial drivers (and later in bluetooth driver). Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com --- arch/arm/mach-omap2/serial.c | 12 arch/arm/plat-omap/include/plat/omap-serial.h |9 -- drivers/serial/8250.c | 26 +- drivers/serial/omap-serial.c | 34 include/linux/serial_reg.h|7 + What tree should this go through? THe omap or serial one? Since this only affects OMAP drivers, we can take this through OMAP. That will also help us avoid conflicts, as we'll hopefully be converting the omap-serial driver to runtime PM for this next merge window as well. Fine with me, feel free to add: Acked-by: Greg Kroah-Hartman gre...@suse.de to it. Thanks, will queue for 2.6.38 merge window. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Fix IGEPv2 second MMC channel power supply
Commit 72f381ba056 (omap3: Remove VMMC2 regulator on IGEP v2)
removed an unused regulator entry, but left the second MMC channel
(used by the Libertas WLAN module) without link to power regulator.
This causes the SDIO module to fail being detected.
This patch adds the two regulators that actually feed the WLAN module
(1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the
second channel is properly detected. Details of the power supply
implementation were kindly provided by Enric Balletbo i Serra.
Also change vmmc1 to use symbolic names instead of direct device
reference.
Tested on an IGEPv2 Rev-B.
Signed-off-by: Marc Zyngier m...@misterjones.org
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-igep0020.c | 61 -
1 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..9a85e60 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
@@ -257,9 +258,8 @@ static inline void __init igep2_init_smsc911x(void) { }
static struct omap_board_config_kernel igep2_config[] __initdata = {
};
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
- .supply = vmmc,
-};
+static struct regulator_consumer_supply igep2_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data igep2_vmmc1 = {
@@ -276,6 +276,52 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies = igep2_vmmc1_supply,
};
+static struct regulator_consumer_supply igep2_vio_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = 1,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vio_supply,
+};
+
+static struct regulator_consumer_supply igep2_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vmmc2 = {
+ .constraints= {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .always_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vmmc2_supply,
+};
+
+static struct fixed_voltage_config igep2_vwlan = {
+ .supply_name= vwlan,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .enabled_at_boot= 1,
+ .init_data = igep2_vmmc2,
+};
+
+static struct platform_device igep2_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 0,
+ .dev = {
+ .platform_data = igep2_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -373,12 +419,6 @@ static int igep2_twl_gpio_setup(struct device *dev,
omap2_hsmmc_init(mmc);
/*
-* link regulators to MMC adapters ... we know the
-* regulators will be set up only *after* we return.
-*/
- igep2_vmmc1_supply.dev = mmc[0].dev;
-
- /*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
@@ -489,6 +529,7 @@ static void __init igep2_display_init(void)
static struct platform_device *igep2_devices[] __initdata = {
igep2_dss_device,
+ igep2_vwlan_device,
};
static void __init igep2_init_irq(void)
@@ -519,7 +560,7 @@ static struct twl4030_platform_data igep2_twldata = {
.gpio = igep2_twl4030_gpio_pdata,
.vmmc1 = igep2_vmmc1,
.vpll2 = igep2_vpll2,
-
+ .vio= igep2_vio,
};
static struct i2c_board_info __initdata igep2_i2c1_boardinfo[] = {
--
1.7.3.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
RFC: hwmod, iclks, auto-idle and autodeps
Hello, There have been a few discussions over the few months about how to properly use omap_hwmod to manage certain IPs that have the interface clock as the functional clock (e.g. OMAP3 GPIOs.) The goal of this RFC is to come to a conclusion about what should be done, and how to go about implementing it. In the initial conversion of the GPIO core to omap_hwmod, main_clk was left NULL so that hwmod was not managing the clock on every hwmod enable/disable. This behavior matched current mainline GPIO code, which does not dynamically disable/enable GPIO iclks after init time. Instead, it relies on the module-level auto idle feature in HW. However, without dynamically managing the clock in hwmod, this meant that there were no autodeps tracked for GPIO and thus the PER powerdomain could transition independently of MPU/CORE. The initial solution to this was to set the iclk to be the main_clk of the hwmod, such that autodeps were managed dynamically as well. This led to a change in functionality in current code, since the iclk was now being manually enabled/disabled at runtime instead of being left for HW to manage by module autoidle. It also led to problems in correctly handling asynchronous GPIO wakeups. In some off-list discussions, one proposal to address this was to change the omap_hwmod core to check the module autoidle before disabling the clock. If the module autoidle is enabled, then hwmod would not directly manage the clock during hwmod_enable/disable. The question is: is this an acceptable solution? the clock framework currently has no knowledge of module auto-idle, where the hwmod core does, so it seems hwmod is (currently) the best place to handle this. Alternatively, would it make sense to do something different with autodeps, such that modules like this that don't have a separate functional clock still have autodeps handled, possibly by using an optional clock? Does extending autodeps make sense since, IIUC, we won't really need them after all devices are using hwmod? Anyways... this is to get the discussion going so we can come to a conclusion on this matter and finialize the hwmod conversions for some of these special IPs. Thanks, 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
Re: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
On Thu, Nov 18, 2010 at 12:13 AM, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Bryan Wu
Sent: Wednesday, November 17, 2010 7:05 PM
To: tomi.valkei...@nokia.com; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Gadiyar, Anand
Subject: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
Generic DPI panel driver includes the driver and 4 similar
panel configurations. It
will match the panel name which is passed from platform data
and setup the
right configurations.
With generic DPI panel driver, we can remove those 4
duplicated panel display
drivers. In the future, it is simple for us just add new
panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig | 8 +
drivers/video/omap2/displays/Makefile | 1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 355
4 files changed, 401 insertions(+), 0 deletions(-)
create mode 100644
arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
diff --git
a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..7906197
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,37 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.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/.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+#define __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+#include display.h
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+#endif /* __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H */
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..cb3e339 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,6 +1,14 @@
menu OMAP2/3 Display Device Drivers
depends on OMAP2_DSS
+config PANEL_GENERIC_DPI
+ tristate Generic DPI Panel
+ help
+ Generic DPI panel driver.
+ Supports DVI output for Beagle and OMAP3 SDP.
+ Supports LCD Panel used in TI SDP3430 and EVM boards,
+ OMAP3517 EVM boards and CM-T35.
+
config PANEL_GENERIC
tristate Generic Panel
help
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..022058c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
new file mode 100644
index 000..6702cf6
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -0,0 +1,355 @@
+/*
+ * Generic DPI Panels support
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
[sp] Shouldn't all authors (from the files being coalesced) be
listed here.
No problem, I will provide an incremental patch for Tomi.
-Bryan
I see this missing from PATCH3/3 in your series:
[quote]
- * LCD panel driver for Sharp LQ043T1DG01
- *
- * Copyright (C) 2009 Texas Instruments Inc
- * Author: Vaibhav Hiremath hvaib...@ti.com
- *
[/quote]
[snip]...[snip]
--
To unsubscribe
No more software ECC in omap2.c NAND driver. Why?
Between 2.6.35 and 2.6.36 there have need quite a few changes in the NAND driver, including a change from software to hardware ECC. The new code has hardware ECC forced on by: #define CONFIG_MTD_NAND_OMAP_HWECC I am surprised that this was done. Surely this should have been a Kconfig option to select either sw ECC or hw ECC? Does moving to hardware ECC to the exclusion of software ECC reduce functionality? Does the new hwecc scheme still support sub-page writes or does it only provide full page writes? If sub-page writes are lost then this has a ripple effect in breaking the way some UBI stuff works. -- Charles -- 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: DSS2: Add back authors of panel-generic.c based drivers
Signed-off-by: Bryan Wu bryan...@canonical.com --- drivers/video/omap2/displays/panel-generic-dpi.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c index 6702cf6..07eb30e 100644 --- a/drivers/video/omap2/displays/panel-generic-dpi.c +++ b/drivers/video/omap2/displays/panel-generic-dpi.c @@ -4,6 +4,16 @@ * Copyright (C) 2010 Canonical Ltd. * Author: Bryan Wu bryan...@canonical.com * + * LCD panel driver for Sharp LQ043T1DG01 + * + * Copyright (C) 2009 Texas Instruments Inc + * Author: Vaibhav Hiremath hvaib...@ti.com + * + * LCD panel driver for Toppoly TDO35S + * + * Copyright (C) 2009 CompuLab, Ltd. + * Author: Mike Rapoport m...@compulab.co.il + * * Copyright (C) 2008 Nokia Corporation * Author: Tomi Valkeinen tomi.valkei...@nokia.com * -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #8)
On Wed, Nov 17, 2010 at 10:18 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: On Wed, 2010-11-17 at 21:34 +0800, ext Bryan Wu wrote: There are 4 duplicated DPI panel drivers in DSS2 display driver. They are similar and a generic DPI panel driver can support all them with specific panel configuration. And new DPI panel driver can be easily supported by adding panel configurations into generic panel DPI driver. This patchset introduces a generic panel DPI driver, remove 3 panel drivers and enable generic panel DPI driver in board files. And it is based on 2.6.37-rc2. Building with omap2plus_defconfig is successful. Keep sharp_ls_panel, since it contains blacklight control code which will be moved out later. Bryan Wu (3): OMAP: DSS2: Add generic DPI panel display driver OMAP: use generic DPI panel driver in board files OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers Thanks, looks good. This is now applied to my tree. Thanks a lot for making this happen, -:)) Are you also interested in solving the backlight issue? =) Yeah, can I start with drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c. I plan to move the blacklight code to drivers/video/blacklight/ and let sharp_ls to use panel-generic-dpi.c driver. -Bryan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
On Wed, Nov 17, 2010 at 02:28:11PM +0200, Tomi Valkeinen wrote: On Tue, 2010-11-16 at 21:10 +0100, ext Tony Lindgren wrote: Sure a module would be even better. My point is that the selection of all the features should be enabled by default and the board options come from platform_data. Ok, let's build DSS all panel drivers as modules by default. Somehow I've gotten the impression from linux ml that enabling features by default is bad. But perhaps it's more about intervening features than normal drivers. The general rule is to avoid default enabling unless you really need it, but it still remains optional (which is why it's not being selected, instead). Some, like gpiolib, have come up with WANT/NEED options for the platform code to select in order to work out the desired behaviour, and you may benefit from a similar approach for your subsystem if it's really that integral for some parts. The flip side of course is that if you expect your users to primarily be using the defconfigs provided, you can simply leave it default disabled in the Kconfig and set the options you want in the defconfigs. Unless you can say with certainty that all OMAP3 boards are going to want DSS enabled or modular by default, it's almost always better to just leave it up to the defconfigs. -- 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
