Re: n810 video
Hi, On Mon, 2010-11-01 at 17:07 +0100, ext Grazvydas Ignotas wrote: hi, On Sat, Oct 30, 2010 at 11:40 AM, Maksim A. Boyko maksim.a.bo...@gmail.com wrote: Hi, I try to switch on OMAP2/3 Display Subsystem Support and Omap frame buffer support on n810 (commit 8b4b01). In OMAP2/3 Display Subsystem Support I used: CONFIG_OMAP2_VRAM_SIZE=4 CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y CONFIG_OMAP2_DSS_DPI=y CONFIG_OMAP2_DSS_VENC=y CONFIG_PANEL_GENERIC=y In Omap frame buffer support I used: CONFIG_FB=y CONFIG_FB_OMAP_LCDC_EXTERNAL=y CONFIG_FB_OMAP_LCDC_BLIZZARD=y CONFIG_FB_OMAP_LCD_MIPID=y CONFIG_FB_OMAP_BOOTLOADER_INIT=y CONFIG_FB_OMAP=y CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2 I create fb device: #mknod /dev/fb0 c 29 0 #chgrp video /dev/fb0 #chmod 660 /dev/fb0 But XServer 1.7.7-8 from debian squeeze armel don't work in both cases. Tail of Xorg.0.log (II) LoadModule: omapfb (II) Loading /usr/lib/xorg/modules/drivers/omapfb_drv.so (II) Module omapfb: vendor=X.Org Foundation compiled for 1.7.4, module version = 0.1.1 ABI class: X.Org Video Driver, version 6.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (WW) Could not open '/dev/fb0': No such device or address(EE) No devices detected The kernel driver probably failed to start, check your dmesg. I guess you'll need to update arch/arm/mach-omap2/board-n8x0.c and add dss2 platform_data (see other board-* files for some examples). Unfortunately there's no support in DSS2 for N800's Blizzard chip, so you'll have to use the older omapfb driver. Or alternatively port the Blizzard driver to DSS2, and probably make some fixes for DSS2's RFBI support. 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/2] OMAP: DSS2: Add new display panel
On Mon, 2010-11-01 at 17:45 +0100, ext Bryan Wu wrote: On Mon, Nov 1, 2010 at 10:15 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: What we need is a common driver for all these dummy panels, and the driver would contain configurations for all the supported panels. The board file would pass the name of the panel used in that board to the driver, and the driver would use the configurations for that panel. It looks like that we just need one file name displays.c to do those generic things and pass the configuration from board files to this driver, such as timing or other things. Not quite. If you pass timing information from the board files then every board file has to define all the timings, even if they are using the same panel. That's why the configs should be in the panel driver, and the board file only has to define which panel is actually connected. This has been discussed a few times in l-o list, but I haven't found time to implement it and nobody else has done it either. I'm quite happy to do this, thanks, Thanks, I appreciate that. 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] OMAP: Fix build failure on MEMBLOCK_REAL_LIMIT
On Mon, 2010-11-01 at 17:30 +0100, ext Namhyung Kim wrote: The MEMBLOCK_REAL_LIMIT symbol was removed by the commit e63075a3c937 (memblock: Introduce default allocation limit and use it to replace explicit ones) so it breaks beagle board build as follows: CC drivers/video/omap2/vram.o drivers/video/omap2/vram.c: In function 'omap_vram_reserve_sdram_memblock': drivers/video/omap2/vram.c:573: error: 'MEMBLOCK_REAL_LIMIT' undeclared (first use in this function) drivers/video/omap2/vram.c:573: error: (Each undeclared identifier is reported only once drivers/video/omap2/vram.c:573: error: for each function it appears in.) make[5]: *** [drivers/video/omap2/vram.o] Error 1 make[4]: *** [drivers/video/omap2] Error 2 make[3]: *** [drivers/video] Error 2 make[2]: *** [drivers] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 Thanks, applied to my tree. 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 v2] McBSP: Fix the free variable update at remove.
From: Shubhrajyoti D shubhrajy...@ti.com
At remove the free variable is wrongly updated.Attempting to solve the same.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
-[v2] Instead of using 0/1 use a macro
arch/arm/plat-omap/include/plat/mcbsp.h |3 +++
arch/arm/plat-omap/mcbsp.c | 10 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index b87d83c..8988733 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -37,6 +37,9 @@ static struct platform_device omap_mcbsp##port_nr = { \
.id = OMAP_MCBSP##port_nr, \
}
+#define TRUE 1
+#define FALSE 0
+
#define OMAP7XX_MCBSP1_BASE0xfffb1000
#define OMAP7XX_MCBSP2_BASE0xfffb1800
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index eac4b97..438b3c7 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -755,7 +755,7 @@ int omap_mcbsp_request(unsigned int id)
goto err_kfree;
}
- mcbsp-free = 0;
+ mcbsp-free = FALSE;
mcbsp-reg_cache = reg_cache;
spin_unlock(mcbsp-lock);
@@ -815,7 +815,7 @@ err_clk_disable:
clk_disable(mcbsp-iclk);
spin_lock(mcbsp-lock);
- mcbsp-free = 1;
+ mcbsp-free = TRUE;
mcbsp-reg_cache = NULL;
err_kfree:
spin_unlock(mcbsp-lock);
@@ -858,7 +858,7 @@ void omap_mcbsp_free(unsigned int id)
if (mcbsp-free)
dev_err(mcbsp-dev, McBSP%d was not reserved\n, mcbsp-id);
else
- mcbsp-free = 1;
+ mcbsp-free = TRUE;
mcbsp-reg_cache = NULL;
spin_unlock(mcbsp-lock);
@@ -1771,7 +1771,7 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
spin_lock_init(mcbsp-lock);
mcbsp-id = id + 1;
- mcbsp-free = 1;
+ mcbsp-free = TRUE;
mcbsp-dma_tx_lch = -1;
mcbsp-dma_rx_lch = -1;
@@ -1845,7 +1845,7 @@ static int __devexit omap_mcbsp_remove(struct
platform_device *pdev)
mcbsp-fclk = NULL;
mcbsp-iclk = NULL;
- mcbsp-free = 0;
+ mcbsp-free = TRUE;
mcbsp-dev = NULL;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] McBSP: Fix the free variable update at remove.
Hi Vishwa, Thanks for your review -Original Message- From: Sripathy, Vishwanath Sent: Saturday, October 30, 2010 12:35 AM To: Datta, Shubhrajyoti; linux-omap@vger.kernel.org Cc: Pandita, Vikram; ABRAHAM, KISHON VIJAY Subject: RE: [PATCH] McBSP: Fix the free variable update at remove. Shubro, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Datta, Shubhrajyoti Sent: Friday, October 29, 2010 4:19 AM To: linux-omap@vger.kernel.org Cc: Pandita, Vikram; Datta, Shubhrajyoti; ABRAHAM, KISHON VIJAY Subject: [PATCH] McBSP: Fix the free variable update at remove. From: Shubhrajyoti D shubhrajy...@ti.com At remove the free variable is wrongly updated.Attempting to solve the same. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Reported-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index eac4b97..6802ed1 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -1845,7 +1845,7 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev) mcbsp-fclk = NULL; mcbsp-iclk = NULL; - mcbsp-free = 0; + mcbsp-free = 1; Isn't it better to use TRUE/FALSE instead of 1/0 if it's a Boolean variable? Addressed it in the v2. Thanks. Vishwa mcbsp-dev = NULL; } -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] McBSP: Fix the free variable update at remove.
On Tue, 2 Nov 2010 15:54:48 +0530
shubhrajy...@ti.com wrote:
From: Shubhrajyoti D shubhrajy...@ti.com
At remove the free variable is wrongly updated.Attempting to solve the same.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
-[v2] Instead of using 0/1 use a macro
arch/arm/plat-omap/include/plat/mcbsp.h |3 +++
arch/arm/plat-omap/mcbsp.c | 10 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index b87d83c..8988733 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -37,6 +37,9 @@ static struct platform_device omap_mcbsp##port_nr = {
\
.id = OMAP_MCBSP##port_nr, \
}
+#define TRUE 1
+#define FALSE0
+
Use 'true' 'false' in the code instead and then there is no need to
redefine these. They are defined in include/linux/stddef.h which is
probably included already by some another file.
--
Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] McBSP: Fix the free variable update at remove.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Datta, Shubhrajyoti
Sent: Tuesday, November 02, 2010 3:55 PM
To: linux-omap@vger.kernel.org
Cc: Datta, Shubhrajyoti
Subject: [PATCH v2] McBSP: Fix the free variable update at remove.
From: Shubhrajyoti D shubhrajy...@ti.com
At remove the free variable is wrongly updated.Attempting to solve the
same.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
-[v2] Instead of using 0/1 use a macro
arch/arm/plat-omap/include/plat/mcbsp.h |3 +++
arch/arm/plat-omap/mcbsp.c | 10 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h b/arch/arm/plat-
omap/include/plat/mcbsp.h
index b87d83c..8988733 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -37,6 +37,9 @@ static struct platform_device omap_mcbsp##port_nr = {
\
.id = OMAP_MCBSP##port_nr, \
}
+#define TRUE 1
+#define FALSE0
+
Why do you redefine them? They are already available.
#define OMAP7XX_MCBSP1_BASE 0xfffb1000
#define OMAP7XX_MCBSP2_BASE 0xfffb1800
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index eac4b97..438b3c7 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -755,7 +755,7 @@ int omap_mcbsp_request(unsigned int id)
goto err_kfree;
}
- mcbsp-free = 0;
+ mcbsp-free = FALSE;
mcbsp-reg_cache = reg_cache;
spin_unlock(mcbsp-lock);
@@ -815,7 +815,7 @@ err_clk_disable:
clk_disable(mcbsp-iclk);
spin_lock(mcbsp-lock);
- mcbsp-free = 1;
+ mcbsp-free = TRUE;
mcbsp-reg_cache = NULL;
err_kfree:
spin_unlock(mcbsp-lock);
@@ -858,7 +858,7 @@ void omap_mcbsp_free(unsigned int id)
if (mcbsp-free)
dev_err(mcbsp-dev, McBSP%d was not reserved\n, mcbsp-id);
else
- mcbsp-free = 1;
+ mcbsp-free = TRUE;
mcbsp-reg_cache = NULL;
spin_unlock(mcbsp-lock);
@@ -1771,7 +1771,7 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
spin_lock_init(mcbsp-lock);
mcbsp-id = id + 1;
- mcbsp-free = 1;
+ mcbsp-free = TRUE;
During probe this should not be TRUE as it becomes TRUE during
a omap_mcbsp_request().
The changes should actually make this flag a boolean one and then
do these changes. You might also need to consider changing the code
in places where this flag is being used.
example:
if (mcbsp-free == TRUE)
mcbsp-dma_tx_lch = -1;
mcbsp-dma_rx_lch = -1;
@@ -1845,7 +1845,7 @@ static int __devexit omap_mcbsp_remove(struct
platform_device *pdev)
mcbsp-fclk = NULL;
mcbsp-iclk = NULL;
- mcbsp-free = 0;
+ mcbsp-free = TRUE;
mcbsp-dev = NULL;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 ] McBSP: Fix the free variable update at remove
From: Shubhrajyoti D shubhrajy...@ti.com At remove the free variable is wrongly updated.Attempting to solve the same. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Reported-by: Vikram Pandita vikram.pand...@ti.com --- -[v2] Instead of using 0/1 use true/false arch/arm/plat-omap/mcbsp.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index eac4b97..07c0525 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -755,7 +755,7 @@ int omap_mcbsp_request(unsigned int id) goto err_kfree; } - mcbsp-free = 0; + mcbsp-free = false; mcbsp-reg_cache = reg_cache; spin_unlock(mcbsp-lock); @@ -815,7 +815,7 @@ err_clk_disable: clk_disable(mcbsp-iclk); spin_lock(mcbsp-lock); - mcbsp-free = 1; + mcbsp-free = true; mcbsp-reg_cache = NULL; err_kfree: spin_unlock(mcbsp-lock); @@ -858,7 +858,7 @@ void omap_mcbsp_free(unsigned int id) if (mcbsp-free) dev_err(mcbsp-dev, McBSP%d was not reserved\n, mcbsp-id); else - mcbsp-free = 1; + mcbsp-free = true; mcbsp-reg_cache = NULL; spin_unlock(mcbsp-lock); @@ -1771,7 +1771,7 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev) spin_lock_init(mcbsp-lock); mcbsp-id = id + 1; - mcbsp-free = 1; + mcbsp-free = true; mcbsp-dma_tx_lch = -1; mcbsp-dma_rx_lch = -1; @@ -1845,7 +1845,7 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev) mcbsp-fclk = NULL; mcbsp-iclk = NULL; - mcbsp-free = 0; + mcbsp-free = true; mcbsp-dev = NULL; } -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] McBSP: Fix the free variable update at remove.
-Original Message-
From: Jarkko Nikula [mailto:jhnik...@gmail.com]
Sent: Tuesday, November 02, 2010 4:03 PM
To: Datta, Shubhrajyoti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v2] McBSP: Fix the free variable update at remove.
On Tue, 2 Nov 2010 15:54:48 +0530
shubhrajy...@ti.com wrote:
From: Shubhrajyoti D shubhrajy...@ti.com
At remove the free variable is wrongly updated.Attempting to solve the
same.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
-[v2] Instead of using 0/1 use a macro
arch/arm/plat-omap/include/plat/mcbsp.h |3 +++
arch/arm/plat-omap/mcbsp.c | 10 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h b/arch/arm/plat-
omap/include/plat/mcbsp.h
index b87d83c..8988733 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -37,6 +37,9 @@ static struct platform_device omap_mcbsp##port_nr = {
\
.id = OMAP_MCBSP##port_nr, \
}
+#define TRUE 1
+#define FALSE 0
+
Use 'true' 'false' in the code instead and then there is no need to
redefine these. They are defined in include/linux/stddef.h which is
probably included already by some another file.
Yes missed it. Will fix that.
--
Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
On 10/28/2010 5:27 PM, Gopinath, Thara wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Thursday, October 28, 2010 11:09 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
Thara,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara Gopinath
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD MPU and the
other associated with VDD CORE.
This patch adds support for smartreflex driver. The driver
is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
SmartReflex support under System type-TI OMAP
implementations menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1 /debug/voltage/vdd_X/smartreflex/autocomp
To disable smartreflex autocompensation feature
echo 0 /debug/voltage/vdd_X/smartreflex/autocomp
where X can be mpu, core , iva etc.
This patch contains code originally in linux omap pm branch.
Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex.c | 975
+
arch/arm/plat-omap/Kconfig| 36 +
arch/arm/plat-omap/include/plat/smartreflex.h | 271 +++
4 files changed, 1283 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex.c
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
snip
+static int __init omap_sr_probe(struct platform_device *pdev)
+{
+ struct omap_sr *sr_info = kzalloc(sizeof(struct
omap_sr), GFP_KERNEL);
+ struct omap_device *odev = to_omap_device(pdev);
Patch3 should be ordered before patch2 in your series. Otherwise,
this would fail during a git-bisect.
Again why ?? All patches individually compile and boot.
+ struct omap_sr_data *pdata = pdev-dev.platform_data;
+ struct resource *mem, *irq;
+ struct dentry *vdd_dbg_dir, *dbg_dir;
+ int ret = 0;
+
+ if (!sr_info) {
+ dev_err(pdev-dev, %s: unable to allocate sr_info\n,
+ __func__);
+ return -ENOMEM;
+ }
+
+ if (!pdata) {
+ dev_err(pdev-dev, %s: platform data
missing\n, __func__);
+ return -EINVAL;
+ }
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(pdev-dev, %s: no mem resource\n, __func__);
+ ret = -ENODEV;
+ goto err_free_devinfo;
+ }
+
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+
+ pm_runtime_enable(pdev-dev);
+
+ sr_info-pdev = pdev;
+ sr_info-srid = pdev-id;
+ sr_info-voltdm = pdata-voltdm;
+ sr_info-autocomp_active = false;
+ sr_info-ip_type = odev-hwmods[0]-class-rev;
I am not sure if it is okay to get hwmods-info in the driver.
To avoid too many indirections, it can be obtained before
omap_device_build() of the device and passed to the driver.
mmm. yep we could do it also. Maybe Kevin/Benoit needs to confirm the
correct way of doing this.
Yep, I fully agree with Charu. You'd better copy that information at
omap_device build time. Getting hwmod internal stuff directly is bad.
Benoit
Regards
Thara
+ sr_info-base = ioremap(mem-start, resource_size(mem));
+ if (!sr_info-base) {
+ dev_err(pdev-dev, %s: ioremap fail\n, __func__);
+ ret = -ENOMEM;
+ goto err_release_region;
+ }
snip
-V Charulatha
--
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 v2 08/11] OMAP4: Adding dev atrributes to OMAP4 smartreflex hwmod data
Cousson, Benoit b-cous...@ti.com writes:
On 9/25/2010 2:51 PM, Gopinath, Thara wrote:
This patch adds dev attributes for smartreflex modules
in the OMAP4 hwmod database. This patch also updates the
smartreflex rev in the smartreflex class data structure
in the OMAP4 hwmod database.
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 56
arch/arm/plat-omap/include/plat/control.h | 12 ++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba3c215..82657b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,8 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/smartreflex.h
+#includeplat/control.h
#include omap_hwmod_common_data.h
@@ -474,6 +476,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_smartreflex_sysc = {
static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
.name = smartreflex,
.sysc =omap44xx_smartreflex_sysc,
+.rev = 2,
};
/* smartreflex_core */
@@ -505,6 +508,22 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_core_slaves[] = {
omap44xx_l4_cfg__smartreflex_core,
};
+static u32 omap44xx_sr_core_efuse_offs[] = {
+OMAP44XX_CONTROL_FUSE_CORE_OPP50, OMAP44XX_CONTROL_FUSE_CORE_OPP100,
+};
+
+static u32 omap44xx_sr_core_test_nvalues[] = {
+0x0, 0x0
+};
At first, I thought it was a good idea to put such data here, but now
after the discussion about timer hwmod data, I realize I was wrong.
These informations belong to omap_volt_data. For each OPP you should
provide the efuse offset an the SW nvalues.
BTW, you should not call them test Nvalues, these are perfectly valid
and can be potentially used in production. There are just not as
optimized as a efuse Nvalue.
Just to clarify...
Benoit, what's your opinion of my comment that these values don't belong
in the volt_data.
As they are only used in the SR layer, they should remain there, IMO.
The only thing needed in volt_data is an efuse id/offset.
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 v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions
Omar Ramirez Luna omar.rami...@ti.com writes: From: Paul Walmsley p...@pwsan.com Update the DSP reset code in pm34xx.c to use one of the new SCM DSP boot control functions, omap2430_ctrl_set_dsp_bootmode(). This reset code should be moved out to a separate function to be called by the hwmod reset process at some point. Also, 2430 should be initializing the DSP in a similar fashion. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Acked-by: Kevin Hilman khil...@deeprootsystems.com In PATCH 0/x, please report on what platforms this was tested. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: tidspbridge: fix build failure on MEMBLOCK_REAL_LIMIT
MEMBLOCK_REAL_LIMIT symbol was removed by the commit e63075a3c937
(memblock: Introduce default allocation limit and use it to replace
explicit ones). This breaks build as below when CONFIG_TIDSPBRIDGE
is selected. Fix this.
CC arch/arm/plat-omap/devices.o
arch/arm/plat-omap/devices.c: In function 'omap_dsp_reserve_sdram_memblock':
arch/arm/plat-omap/devices.c:287: error: 'MEMBLOCK_REAL_LIMIT' undeclared
(first use in this function)
arch/arm/plat-omap/devices.c:287: error: (Each undeclared identifier is
reported only once
arch/arm/plat-omap/devices.c:287: error: for each function it appears in.)
make[1]: *** [arch/arm/plat-omap/devices.o] Error 1
make: *** [arch/arm/plat-omap] Error 2
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Felipe Contreras felipe.contre...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Tony Lindgren t...@atomide.com
---
Based on another similar patch [1] for vram.c. I've scrubbed the rest
of the tree for MEMBLOCK_REAL_LIMIT. Only other occurrence is in
a comment in arch/powerpc/kernel/setup_32.c [2]. Not sure what this
should be changed to.
[1] http://marc.info/?l=linux-omapm=128862903431257w=2
[2] http://lxr.free-electrons.com/source/arch/powerpc/kernel/setup_32.c#L249
arch/arm/plat-omap/devices.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/arch/arm/plat-omap/devices.c
===
--- linux-2.6.orig/arch/arm/plat-omap/devices.c
+++ linux-2.6/arch/arm/plat-omap/devices.c
@@ -284,7 +284,7 @@ void __init omap_dsp_reserve_sdram_membl
if (!size)
return;
- paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_REAL_LIMIT);
+ paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_ALLOC_ACCESSIBLE);
if (!paddr) {
pr_err(%s: failed to reserve %x bytes\n,
__func__, size);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 low power mode broken on l-o
Jean Pihet jean.pi...@newoldbits.com writes: The low power mode on the latest l-o master branch is broken, so I investigated a bit. Here are the results. This has been tested on OMAP3EVM and Beagleboard. The problem is that the CORE does not reach the desired mode (RET, OFF). It is caused by the I2C1 fclk that is left enabled at suspend time. Extra printks has been added in the clock enable and disable functions for I2C and a stack dump has been added in the suspend path if the clock is still enabled, cf. log below. In the devices suspend sequence the RTC gets suspended, which triggers a read of the TWL RTC through the I2C bus, which in turn enables the I2C1 fclk. That clock is only disabled on devices resume. I am guessing this is linked to the recent changes in the I2C for HWMOD support. What is the correct fix to have the I2C modules correctly shut off before the suspend? I2C clocks are supposed to be disabled after each transaction. This isn't happening. My guess is that the 'put' that happens after TX doesn't actually actually result in a call to omap_device_idle() since system suspend is active. Static suspend/resume take the runtime PM lock, effectively disabling runtime PM suspend during static suspend. I have a patch/workaround for this problem which is part of my pm-core branch, but I did not submit for 2.6.37 as I'm not entirely convinced of it yet. Basically, in the OMAP bus-methods for static suspend/resume I tinker with the runtime PM usecounting such that the devices can idle. Please take a look at the tip patch in my pm-suspend branch, try it out and see if it fixes your problem. 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 v2 08/11] OMAP4: Adding dev atrributes to OMAP4 smartreflex hwmod data
Hi Kevin,
On 11/2/2010 10:10 AM, Kevin Hilman wrote:
Cousson, Benoitb-cous...@ti.com writes:
On 9/25/2010 2:51 PM, Gopinath, Thara wrote:
This patch adds dev attributes for smartreflex modules
in the OMAP4 hwmod database. This patch also updates the
smartreflex rev in the smartreflex class data structure
in the OMAP4 hwmod database.
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 56
arch/arm/plat-omap/include/plat/control.h | 12 ++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba3c215..82657b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,8 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/smartreflex.h
+#includeplat/control.h
#include omap_hwmod_common_data.h
@@ -474,6 +476,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_smartreflex_sysc = {
static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
.name = smartreflex,
.sysc =omap44xx_smartreflex_sysc,
+ .rev = 2,
};
/* smartreflex_core */
@@ -505,6 +508,22 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_core_slaves[] = {
omap44xx_l4_cfg__smartreflex_core,
};
+static u32 omap44xx_sr_core_efuse_offs[] = {
+ OMAP44XX_CONTROL_FUSE_CORE_OPP50, OMAP44XX_CONTROL_FUSE_CORE_OPP100,
+};
+
+static u32 omap44xx_sr_core_test_nvalues[] = {
+ 0x0, 0x0
+};
At first, I thought it was a good idea to put such data here, but now
after the discussion about timer hwmod data, I realize I was wrong.
These informations belong to omap_volt_data. For each OPP you should
provide the efuse offset an the SW nvalues.
BTW, you should not call them test Nvalues, these are perfectly valid
and can be potentially used in production. There are just not as
optimized as a efuse Nvalue.
Just to clarify...
Benoit, what's your opinion of my comment that these values don't belong
in the volt_data.
Or maybe it is just volt_data that should be renamed, because all the
data in it are SR / VP related:
{.volt_nominal = 975000, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C},
So the efuse info belongs to it as well.
At the end the volt_data at voltage management level is just a list of
supported voltages. Does it make sense to add an id instead of keeping
the voltage as an index?
volt_data should be:
{.volt_nominal = 975000},
and then volt_sr_vp_data will be:
{.volt_nominal = 975000, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C,
efuse_stuff...},
or with an id:
{.id = 0, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C, efuse_stuff...},
I do agree that we have to split that in two structures, but I'm not
sure the id is really needed here?
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. I guess you have seen the complaint from Linus regarding ARM relying too much on defconfigs. This helps in order to simplify defconfigs, and eventually getting rid of them completely. -- 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
[PATCH 2.6.37-rc1] OMAP1: camera.h: readd missing include
#include media/omap1_camera.h directive, required for successfull compilation of dependant boards (board-ams-delta for now), has been lost somehow from arch/arm/mach-omap1/include/mach/camera.h on creation. Readd it. Created and tested against linux-2.6.37-rc1. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- arch/arm/mach-omap1/include/mach/camera.h |2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.37-rc1/arch/arm/mach-omap1/include/mach/camera.h.orig 2010-11-01 22:41:04.0 +0100 +++ linux-2.6.37-rc1/arch/arm/mach-omap1/include/mach/camera.h 2010-11-01 23:18:44.0 +0100 @@ -1,6 +1,8 @@ #ifndef __ASM_ARCH_CAMERA_H_ #define __ASM_ARCH_CAMERA_H_ +#include media/omap1_camera.h + void omap1_camera_init(void *); static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info) -- 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: tidspbridge: fix build failure on MEMBLOCK_REAL_LIMIT
On Tue, Nov 2, 2010 at 3:31 PM, Anand Gadiyar gadi...@ti.com wrote: MEMBLOCK_REAL_LIMIT symbol was removed by the commit e63075a3c937 (memblock: Introduce default allocation limit and use it to replace explicit ones). This breaks build as below when CONFIG_TIDSPBRIDGE is selected. Fix this. I would rather apply this: http://article.gmane.org/gmane.linux.ports.arm.omap/45076 -- 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: tidspbridge: fix build failure on MEMBLOCK_REAL_LIMIT
On Tue, Nov 2, 2010 at 10:05 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Nov 2, 2010 at 3:31 PM, Anand Gadiyar gadi...@ti.com wrote: MEMBLOCK_REAL_LIMIT symbol was removed by the commit e63075a3c937 (memblock: Introduce default allocation limit and use it to replace explicit ones). This breaks build as below when CONFIG_TIDSPBRIDGE is selected. Fix this. I would rather apply this: http://article.gmane.org/gmane.linux.ports.arm.omap/45076 Okay, I hadn't seen that one. Thanks! - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by default, too. (TWL4030_CORE doesn't depend on something omapish.) For me this looks OK. It would be still better if it removed CONFIG_REGULATOR_TWL4030=y from arch/arm/configs/omap2plus_defconfig. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: Add missing dependencies, and remove redundant ones, and select sensible defaults. This is more user-friendly, and logical. - TWL4030_CORE people should be able to compile without ARM - REGULATOR_TWL4030 if TWL4030_CORE and REGULATOR, it's pretty clear we want this - USB_GADGET_SELECTED is already inside USB_GADGET - USB_GADGET_OMAP only works on ARCH_OMAP1, and USB_OTG_UTILS is already selected by NOP_USB_XCEIV - USB_GADGET_R8A66597 is meant for ARCH_SHMOBILE - USB_MUSB_HDRC needs either NOP_USB_XCEIV, or TWL4030_USB - USB_MUSB_AM35X, NOP_USB_XCEIV is already selected because MACH_OMAP3EVM Finally, move: config USB_MUSB_HDRC select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP To: config TWL4030_USB default y if ARCH_OMAP3 config NOP_USB_XCEIV default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN Signed-off-by: Felipe Contreras felipe.contre...@gmail.com All changes look fine to me, but I think you will need to split up this patch for the different subsystem maintainers. Best regards Uwe --- drivers/mfd/Kconfig|2 +- drivers/regulator/Kconfig |1 + drivers/usb/gadget/Kconfig |5 ++--- drivers/usb/musb/Kconfig |7 ++- drivers/usb/otg/Kconfig|2 ++ 5 files changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3a1493b..88e47a0 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -169,7 +169,7 @@ config TWL4030_CORE config TWL4030_POWER bool Support power resources on TWL4030 family chips - depends on TWL4030_CORE ARM + depends on TWL4030_CORE help Say yes here if you want to use the power resources on the TWL4030 family chips. Most of these resources are regulators, diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index dd30e88..1397f7a 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -119,6 +119,7 @@ config REGULATOR_MAX8998 config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 75733cd..0ad0c32 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -111,7 +111,6 @@ configUSB_GADGET_SELECTED # choice prompt USB Peripheral Controller - depends on USB_GADGET help A USB device uses a controller to talk to its host. Systems should have only one such upstream link. @@ -190,9 +189,8 @@ config USB_LH7A40X config USB_GADGET_OMAP boolean OMAP USB Device Controller - depends on ARCH_OMAP + depends on ARCH_OMAP1 select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG - select USB_OTG_UTILS if ARCH_OMAP help Many Texas Instruments OMAP processors have flexible full speed USB device controllers, with support for up to 30 @@ -244,6 +242,7 @@ config USB_PXA25X_SMALL config USB_GADGET_R8A66597 boolean Renesas R8A66597 USB Peripheral Controller + depends on ARCH_SHMOBILE select USB_GADGET_DUALSPEED help R8A66597 is a discrete USB host and peripheral controller chip that diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index f0e0495..5951b9f 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,8 +11,7 @@ config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) - select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) - select TWL4030_USB if MACH_OMAP_3430SDP + depends on (NOP_USB_XCEIV || TWL4030_USB) select USB_OTG_UTILS help Say Y here if your system has a dual role high speed USB @@ -63,7 +62,6 @@ comment Blackfin high speed USB Support config USB_MUSB_AM35X bool depends on USB_MUSB_HDRC !ARCH_OMAP2430 !ARCH_OMAP4 - select NOP_USB_XCEIV default MACH_OMAP3517EVM help Select this option if your platform is based on AM35x. As @@ -73,8 +71,7 @@ config USB_MUSB_AM35X config USB_TUSB6010 boolean TUSB 6010 support - depends on USB_MUSB_HDRC !USB_MUSB_SOC - select NOP_USB_XCEIV + depends on USB_MUSB_HDRC !USB_MUSB_SOC NOP_USB_XCEIV default y help The TUSB 6010 chip, from Texas Instruments, connects a discrete diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 5ce0752..728b476 100644 --- a/drivers/usb/otg/Kconfig +++
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de: On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by default, too. (TWL4030_CORE doesn't depend on something omapish.) Yes, I think TWL4030_CORE should depend on OMAP3, but I think some people might not like that. That's why I wanted to make that a separate patch. For me this looks OK. It would be still better if it removed CONFIG_REGULATOR_TWL4030=y from arch/arm/configs/omap2plus_defconfig. Yes, but I want to run 'make savedefconfig'; there's many changes lingering like that. -- 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 v3 2/2] drivers: cleanup Kconfig stuff
2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de: On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: Add missing dependencies, and remove redundant ones, and select sensible defaults. This is more user-friendly, and logical. - TWL4030_CORE people should be able to compile without ARM - REGULATOR_TWL4030 if TWL4030_CORE and REGULATOR, it's pretty clear we want this - USB_GADGET_SELECTED is already inside USB_GADGET - USB_GADGET_OMAP only works on ARCH_OMAP1, and USB_OTG_UTILS is already selected by NOP_USB_XCEIV - USB_GADGET_R8A66597 is meant for ARCH_SHMOBILE - USB_MUSB_HDRC needs either NOP_USB_XCEIV, or TWL4030_USB - USB_MUSB_AM35X, NOP_USB_XCEIV is already selected because MACH_OMAP3EVM Finally, move: config USB_MUSB_HDRC select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP To: config TWL4030_USB default y if ARCH_OMAP3 config NOP_USB_XCEIV default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN Signed-off-by: Felipe Contreras felipe.contre...@gmail.com All changes look fine to me, but I think you will need to split up this patch for the different subsystem maintainers. Ok, will do. -- 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 v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. TWL4030 can be enabled on other platforms - it's not tied to OMAP (mostly to enable build coverage). I guess you have seen the complaint from Linus regarding ARM relying too much on defconfigs. This helps in order to simplify defconfigs, and eventually getting rid of them completely. This solution doesn't seem like it scales so well either, it just shifts it into the Kconfig files (where everything is all in central files shared by everyone which has its own problems). Certainly the goal of replacing defconfig files with Kconfig seems unattainable. -- 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 v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote: 2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by default, too. (TWL4030_CORE doesn't depend on something omapish.) Yes, I think TWL4030_CORE should depend on OMAP3, but I think some people might not like that. That's why I wanted to make that a separate patch. It did originally but that dependency was removed to allow build coverage for non-OMAP users. For me this looks OK. It would be still better if it removed CONFIG_REGULATOR_TWL4030=y from arch/arm/configs/omap2plus_defconfig. Yes, but I want to run 'make savedefconfig'; there's many changes lingering like that. -- 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
[PATCH 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem
In the new code introduced with commit cf4c87abe238ec17cd0255b4e21abd949d7f811e, OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c, the way omap1 build is supposed to bypass omap2 specific functionality doesn't optimize out all omap2 specific stuff. This breaks linking phase for omap1 machines, giving undefined reference to `omap2_mcbsp1_mux_clkr_src' and undefined reference to `omap2_mcbsp1_mux_fsr_src' errors. Fix it. Created and tested against linux-2.6.37-rc1. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- sound/soc/omap/omap-mcbsp.c |8 1 file changed, 8 insertions(+) --- linux-2.6.37-rc1/sound/soc/omap/omap-mcbsp.c.orig 2010-11-01 22:43:16.0 +0100 +++ linux-2.6.37-rc1/sound/soc/omap/omap-mcbsp.c2010-11-02 15:41:42.0 +0100 @@ -644,15 +644,23 @@ static int omap_mcbsp_dai_set_dai_sysclk case OMAP_MCBSP_CLKR_SRC_CLKR: + if (cpu_class_is_omap1()) + break; omap2_mcbsp1_mux_clkr_src(CLKR_SRC_CLKR); break; case OMAP_MCBSP_CLKR_SRC_CLKX: + if (cpu_class_is_omap1()) + break; omap2_mcbsp1_mux_clkr_src(CLKR_SRC_CLKX); break; case OMAP_MCBSP_FSR_SRC_FSR: + if (cpu_class_is_omap1()) + break; omap2_mcbsp1_mux_fsr_src(FSR_SRC_FSR); break; case OMAP_MCBSP_FSR_SRC_FSX: + if (cpu_class_is_omap1()) + break; omap2_mcbsp1_mux_fsr_src(FSR_SRC_FSX); break; default: -- 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] OMAP3630: DSS2: Enable Pre-Multiplied Alpha Support
Hi,
On Wed, 2010-10-27 at 12:16 +0200, ext Samreen wrote:
From: Rajkumar N rajkumar.nagara...@ti.com
Enable dss to process color formats with pre-mulitplied alpha.
With this we can have alpha values defined for each pixel
and hence can have different blending values for each pixel.
sysfs entry has been created for this and pre-multiplied alpha
support is turned off by default.
Also, the check for '(plane != OMAP_DSS_VIDEO1)'
in _dispc_setup_plane has been replaced by the correct
dss_has_feature check
You're changing too many things in one patch. Please separate the
dss_feature changes and the actual implementation for the pre-multiplied
alpha.
Your naming of this feature is also bit varying: you have pre_mult,
PREMUL, pre_multiplication_alpha. The last one is quite wrong, as
the feature is premultiplied alpha.
Also a few comments inline.
Signed-off-by: Sudeep Basavaraj sudeep.basava...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |1 +
drivers/video/omap2/dss/dispc.c | 25 +---
drivers/video/omap2/dss/dss.h |3 +-
drivers/video/omap2/dss/dss_features.c| 20 ++--
drivers/video/omap2/dss/dss_features.h|1 +
drivers/video/omap2/dss/manager.c |5 +++-
drivers/video/omap2/dss/overlay.c | 35
+
7 files changed, 81 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index c915a66..d433baf 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -268,6 +268,7 @@ struct omap_overlay_info {
u16 out_width; /* if 0, out_width == width */
u16 out_height; /* if 0, out_height == height */
u8 global_alpha;
+ u8 pre_mult_alpha;
};
struct omap_overlay {
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fa40fa5..f1d1797 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -773,6 +773,17 @@ static void _dispc_set_vid_size(enum omap_plane plane,
int width, int height)
dispc_write_reg(vsi_reg[plane-1], val);
}
+static void _dispc_set_pre_mult_alpha(enum omap_plane plane, bool enable)
+{
+ if (!dss_has_feature(FEAT_PREMUL_ALPHA))
+ return;
+
+ BUG_ON(!dss_has_feature(FEAT_GLOBAL_ALPHA_VID1)
+ plane == OMAP_DSS_VIDEO1);
What is the rationale for having the function return, if
FEAT_PREMUL_ALPHA is not supported, but BUG if plane is video1 and
GLOBAL_ALPHA_VID1 is not supported?
+
+ REG_FLD_MOD(dispc_reg_att[plane], enable ? 1 : 0, 28, 28);
+}
+
static void _dispc_setup_global_alpha(enum omap_plane plane, u8 global_alpha)
{
if (!dss_has_feature(FEAT_GLOBAL_ALPHA))
@@ -1507,7 +1518,8 @@ static int _dispc_setup_plane(enum omap_plane plane,
bool ilace,
enum omap_dss_rotation_type rotation_type,
u8 rotation, int mirror,
- u8 global_alpha)
+ u8 global_alpha,
+ u8 pre_mult_alpha)
{
const int maxdownscale = cpu_is_omap34xx() ? 4 : 2;
bool five_taps = 0;
@@ -1693,8 +1705,11 @@ static int _dispc_setup_plane(enum omap_plane plane,
_dispc_set_rotation_attrs(plane, rotation, mirror, color_mode);
- if (plane != OMAP_DSS_VIDEO1)
+ if ((plane != OMAP_DSS_VIDEO1) ||
+ dss_has_feature(FEAT_GLOBAL_ALPHA_VID1)) {
+ _dispc_set_pre_mult_alpha(plane, pre_mult_alpha);
_dispc_setup_global_alpha(plane, global_alpha);
+ }
return 0;
}
@@ -3139,7 +3154,8 @@ int dispc_setup_plane(enum omap_plane plane,
enum omap_color_mode color_mode,
bool ilace,
enum omap_dss_rotation_type rotation_type,
-u8 rotation, bool mirror, u8 global_alpha)
+u8 rotation, bool mirror, u8 global_alpha,
+u8 pre_mult_alpha)
{
int r = 0;
@@ -3161,7 +3177,8 @@ int dispc_setup_plane(enum omap_plane plane,
color_mode, ilace,
rotation_type,
rotation, mirror,
-global_alpha);
+global_alpha,
+pre_mult_alpha);
enable_clocks(0);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 5c7940d..2bb515c 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -359,7 +359,8 @@ int dispc_setup_plane(enum omap_plane plane,
bool ilace,
enum omap_dss_rotation_type rotation_type,
u8 rotation, bool mirror,
- u8 global_alpha);
Re: [PATCH 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem
On Tue, Nov 02, 2010 at 03:50:32PM +0100, Janusz Krzysztofik wrote: In the new code introduced with commit cf4c87abe238ec17cd0255b4e21abd949d7f811e, OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c, the way omap1 build is supposed to bypass omap2 specific functionality doesn't optimize out all omap2 specific stuff. This breaks linking phase for omap1 machines, giving undefined reference to `omap2_mcbsp1_mux_clkr_src' and undefined reference to `omap2_mcbsp1_mux_fsr_src' errors. Fix it. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com case OMAP_MCBSP_CLKR_SRC_CLKR: + if (cpu_class_is_omap1()) + break; omap2_mcbsp1_mux_clkr_src(CLKR_SRC_CLKR); I guess this will still fail with optimisation diabled, but I'm not sure anyone ever builds the kernel like that. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] tidspbridge: SCM layer violation fixes
On 10/26/2010 11:15 AM, Ramirez Luna, Omar wrote: This is the patch series shared by Paul, for a short term fix to a compile break due SCM layer layer violations from tidspbridge driver, where the latter is used to write directly into registers and use SCM layer macros, among other layer bypassing. patch: staging: tidspbridge: use new SCM DSP boot control fns was split from its original version, it is meant to be on hold until the rest of the series gets upstreamed and can be found in the staging tree (unless best advice is given). Paul Walmsley (4): OMAP: control: add functions for DSP boot address/mode control OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions OMAP: dsp: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns staging: tidspbridge: use new SCM DSP boot control fns arch/arm/mach-omap2/control.c | 51 ++ arch/arm/mach-omap2/control.h | 16 --- arch/arm/mach-omap2/dsp.c |4 ++ arch/arm/mach-omap2/pm34xx.c |6 +- arch/arm/plat-omap/include/plat/dsp.h |4 ++ arch/arm/plat-omap/include/plat/iva2_dsp.h| 56 + drivers/staging/tidspbridge/core/tiomap3430.c | 13 +++--- 7 files changed, 133 insertions(+), 17 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h This series was tested on OMAP 3430 (zoom2) and 3630 (zoom3) boards. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAP: DSS2: introduce dummy panel driver
There are 4 duplicated panel driver sin DSS2 display driver. They are similar and dummy panel driver can support all them with specific panel configuration. And new panel driver can be easily supported by adding panel configurations into dummy panel driver. This patchset introduces dummy panel driver, remove 3 panel drivers and enable dummy panel driver in board files. And it is based on 2.6.37-rc1. 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 dummy panel display driver OMAP: DSS2: remove dummy panel driver duplicated panel drivers OMAP: use dummy panel driver in board files arch/arm/mach-omap2/board-3430sdp.c|3 +- arch/arm/mach-omap2/board-am3517evm.c |6 +- arch/arm/mach-omap2/board-cm-t35.c |6 +- arch/arm/mach-omap2/board-devkit8000.c |6 +- arch/arm/mach-omap2/board-igep0020.c |3 +- arch/arm/mach-omap2/board-omap3beagle.c|3 +- arch/arm/mach-omap2/board-omap3evm.c |3 +- arch/arm/mach-omap2/board-omap3stalker.c |6 +- arch/arm/plat-omap/include/plat/display.h | 28 +- drivers/video/omap2/displays/Kconfig | 22 +- drivers/video/omap2/displays/Makefile |4 +- drivers/video/omap2/displays/panel-dummy.c | 195 +++ drivers/video/omap2/displays/panel-dummy.h | 119 + drivers/video/omap2/displays/panel-generic.c | 174 --- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 -- .../video/omap2/displays/panel-tpo-td043mtea1.c| 535 16 files changed, 364 insertions(+), 914 deletions(-) create mode 100644 drivers/video/omap2/displays/panel-dummy.c create mode 100644 drivers/video/omap2/displays/panel-dummy.h 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-tpo-td043mtea1.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 2/3] OMAP: DSS2: remove dummy 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-tpo-td043mtea1.c| 535
5 files changed, 0 insertions(+), 895 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-tpo-td043mtea1.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 4b2ed33..4a29863 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -9,12 +9,6 @@ config PANEL_DUMMY
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 5b50036..587bef8 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,9 +1,6 @@
obj-$(CONFIG_PANEL_DUMMY) += panel-dummy.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);
-
- omapdss_dpi_display_disable(dssdev);
[PATCH 1/3] OMAP: DSS2: Add dummy panel display driver
Dummy 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 dummy 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-dummy.h to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-dummy.c | 195
drivers/video/omap2/displays/panel-dummy.h | 119 +
4 files changed, 323 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-dummy.c
create mode 100644 drivers/video/omap2/displays/panel-dummy.h
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..4b2ed33 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_DUMMY
+tristate Dummy Panel
+help
+ Dummy 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..5b50036 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_DUMMY) += panel-dummy.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-dummy.c
b/drivers/video/omap2/displays/panel-dummy.c
new file mode 100644
index 000..c4c387a
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-dummy.c
@@ -0,0 +1,195 @@
+/*
+ * Dummy Panels support
+ *
+ * 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/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include plat/display.h
+
+#include panel-dummy.h
+
+static int dummy_panel_power_on(struct omap_dss_device *dssdev)
+{
+ int r;
+ struct omap_display_panel *p = dssdev-panel;
+
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
+ r = omapdss_dpi_display_enable(dssdev);
+ if (r)
+ goto err0;
+
+ /* wait couple of vsyncs until enabling the LCD */
+ if (p-power_on_delay)
+ msleep(p-power_on_delay);
+
+ 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 dummy_panel_power_off(struct omap_dss_device *dssdev)
+{
+ struct omap_display_panel *p = dssdev-panel;
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+
+ /* wait couple of vsyncs after disabling the LCD */
+ if (p-power_off_delay)
+ msleep(p-power_off_delay);
+
+ omapdss_dpi_display_disable(dssdev);
+}
+
+static int dummy_panel_probe(struct omap_dss_device *dssdev)
+{
+ struct omap_display_panel *dp = dssdev-panel;
+ struct omap_display_panel *pp = NULL;
+ int i;
+ int matched = 0;
+
+ if (dp-name == NULL)
+ return -ENODEV;
+
+ /* Match for the configuration of the panel */
+ for (i = 0; i ARRAY_SIZE(dummy_panels); i++) {
+ pp = dummy_panels[i];
+ if (strcmp(pp-name, dp-name) == 0) {
+ matched = 1;
+ break;
+ }
+ }
+
+ if (!matched)
+ return -ENODEV;
+
+ memcpy(dp, pp, sizeof(struct omap_display_panel));
+
+ return 0;
+}
+
+static void dummy_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int dummy_panel_enable(struct
[PATCH 3/3] OMAP: use dummy panel driver in board files
Introduce some fields in struct panel, which will be used to match the right
panel configurations in dummy driver.
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 dummy driver
for sharp_ls_panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-omap2/board-3430sdp.c |3 ++-
arch/arm/mach-omap2/board-am3517evm.c |6 --
arch/arm/mach-omap2/board-cm-t35.c|6 --
arch/arm/mach-omap2/board-devkit8000.c|6 --
arch/arm/mach-omap2/board-igep0020.c |3 ++-
arch/arm/mach-omap2/board-omap3beagle.c |3 ++-
arch/arm/mach-omap2/board-omap3evm.c |3 ++-
arch/arm/mach-omap2/board-omap3stalker.c |6 --
arch/arm/plat-omap/include/plat/display.h | 28 +++-
9 files changed, 43 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..0e4598d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -272,7 +272,8 @@ static struct omap_dss_device sdp3430_lcd_device = {
static struct omap_dss_device sdp3430_dvi_device = {
.name = dvi,
- .driver_name= generic_panel,
+ .driver_name= dummy_panel,
+ .panel.name = generic,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.platform_enable= sdp3430_panel_enable_dvi,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..88c9b76 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -306,7 +306,8 @@ static void am3517_evm_panel_disable_lcd(struct
omap_dss_device *dssdev)
static struct omap_dss_device am3517_evm_lcd_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = lcd,
- .driver_name= sharp_lq_panel,
+ .driver_name= dummy_panel,
+ .panel.name = sharp_lq,
.phy.dpi.data_lines = 16,
.platform_enable= am3517_evm_panel_enable_lcd,
.platform_disable = am3517_evm_panel_disable_lcd,
@@ -349,7 +350,8 @@ static void am3517_evm_panel_disable_dvi(struct
omap_dss_device *dssdev)
static struct omap_dss_device am3517_evm_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
- .driver_name= generic_panel,
+ .driver_name= dummy_panel,
+ .panel.name = generic,
.phy.dpi.data_lines = 24,
.platform_enable= am3517_evm_panel_enable_dvi,
.platform_disable = am3517_evm_panel_disable_dvi,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..a0c555d 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -353,7 +353,8 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device
*dssdev)
static struct omap_dss_device cm_t35_lcd_device = {
.name = lcd,
- .driver_name= toppoly_tdo35s_panel,
+ .driver_name= dummy_panel,
+ .panel.name = toppoly_tdo35s,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 18,
.platform_enable= cm_t35_panel_enable_lcd,
@@ -362,7 +363,8 @@ static struct omap_dss_device cm_t35_lcd_device = {
static struct omap_dss_device cm_t35_dvi_device = {
.name = dvi,
- .driver_name= generic_panel,
+ .driver_name= dummy_panel,
+ .panel.name = generic,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.platform_enable= cm_t35_panel_enable_dvi,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 067f437..ce5be9c 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -151,7 +151,8 @@ static struct regulator_consumer_supply
devkit8000_vio_supply =
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
- .driver_name= generic_panel,
+ .driver_name= dummy_panel,
+ .panel.name = generic,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.reset_gpio = -EINVAL, /* will be replaced */
@@ -160,7 +161,8 @@ static struct omap_dss_device devkit8000_lcd_device = {
};
static struct omap_dss_device devkit8000_dvi_device = {
.name = dvi,
- .driver_name= generic_panel,
+ .driver_name
Re: [PATCH 0/3] OMAP: DSS2: introduce dummy panel driver
On 11/2/2010 9:43 PM, Bryan Wu wrote: There are 4 duplicated panel driver sin DSS2 display driver. They are similar and dummy panel driver can support all them with specific panel configuration. And new panel driver can be easily supported by adding panel configurations into dummy panel driver. This patchset introduces dummy panel driver, remove 3 panel drivers and enable dummy panel driver in board files. And it is based on 2.6.37-rc1. 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 dummy panel display driver OMAP: DSS2: remove dummy panel driver duplicated panel drivers OMAP: use dummy panel driver in board files arch/arm/mach-omap2/board-3430sdp.c|3 +- arch/arm/mach-omap2/board-am3517evm.c |6 +- arch/arm/mach-omap2/board-cm-t35.c |6 +- arch/arm/mach-omap2/board-devkit8000.c |6 +- arch/arm/mach-omap2/board-igep0020.c |3 +- arch/arm/mach-omap2/board-omap3beagle.c|3 +- arch/arm/mach-omap2/board-omap3evm.c |3 +- arch/arm/mach-omap2/board-omap3stalker.c |6 +- arch/arm/plat-omap/include/plat/display.h | 28 +- drivers/video/omap2/displays/Kconfig | 22 +- drivers/video/omap2/displays/Makefile |4 +- drivers/video/omap2/displays/panel-dummy.c | 195 +++ drivers/video/omap2/displays/panel-dummy.h | 119 + drivers/video/omap2/displays/panel-generic.c | 174 --- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 -- .../video/omap2/displays/panel-tpo-td043mtea1.c| 535 16 files changed, 364 insertions(+), 914 deletions(-) create mode 100644 drivers/video/omap2/displays/panel-dummy.c create mode 100644 drivers/video/omap2/displays/panel-dummy.h 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-tpo-td043mtea1.c Why can't panel-generic.c be reused instead of a new panel-dummy.c? Sounds like what you're trying to do is to get a generic panel driver; so shouldn't it at least be called generic instead of dummy. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem
On Tue, 2 Nov 2010, Janusz Krzysztofik wrote: In the new code introduced with commit cf4c87abe238ec17cd0255b4e21abd949d7f811e, OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c, the way omap1 build is supposed to bypass omap2 specific functionality doesn't optimize out all omap2 specific stuff. This breaks linking phase for omap1 machines, giving undefined reference to `omap2_mcbsp1_mux_clkr_src' and undefined reference to `omap2_mcbsp1_mux_fsr_src' errors. Fix it. Created and tested against linux-2.6.37-rc1. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Acked-by: Paul Walmsley p...@pwsan.com Thanks Janusz. - Paul -- 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 2/3] OMAP: DSS2: remove dummy panel driver duplicated panel drivers
On Tue, Nov 2, 2010 at 6:13 PM, Bryan Wu bryan...@canonical.com wrote: 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-tpo-td043mtea1.c | 535 5 files changed, 0 insertions(+), 895 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-tpo-td043mtea1.c Hey don't remove panel-tpo-td043mtea1.c, it's not a dupe! You probably confused it with panel-toppoly-tdo35s.c . This shows you did not build test all panel drivers, just select them all in config (enable SPI so they all appear). -- 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 dummy panel display driver
On Tue, Nov 2, 2010 at 6:13 PM, Bryan Wu bryan...@canonical.com wrote:
Dummy 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 dummy 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-dummy.h to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
snip
diff --git a/drivers/video/omap2/displays/panel-dummy.h
b/drivers/video/omap2/displays/panel-dummy.h
new file mode 100644
index 000..ac2b7a2
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-dummy.h
There is no benefit of having this header, just add all data directly
in .c file.
snip
+ /* Sharp LQ043T1DG01 */
+ {
+ { .x_res = 480,
+ .y_res = 272,
missing newline after {
--
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 dummy panel driver
On Tue, Nov 2, 2010 at 12:53 PM, Anand Gadiyar gadi...@ti.com wrote: On 11/2/2010 9:43 PM, Bryan Wu wrote: There are 4 duplicated panel driver sin DSS2 display driver. They are similar and dummy panel driver can support all them with specific panel configuration. And new panel driver can be easily supported by adding panel configurations into dummy panel driver. This patchset introduces dummy panel driver, remove 3 panel drivers and enable dummy panel driver in board files. And it is based on 2.6.37-rc1. 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 dummy panel display driver OMAP: DSS2: remove dummy panel driver duplicated panel drivers OMAP: use dummy panel driver in board files arch/arm/mach-omap2/board-3430sdp.c | 3 +- arch/arm/mach-omap2/board-am3517evm.c | 6 +- arch/arm/mach-omap2/board-cm-t35.c | 6 +- arch/arm/mach-omap2/board-devkit8000.c | 6 +- arch/arm/mach-omap2/board-igep0020.c | 3 +- arch/arm/mach-omap2/board-omap3beagle.c | 3 +- arch/arm/mach-omap2/board-omap3evm.c | 3 +- arch/arm/mach-omap2/board-omap3stalker.c | 6 +- arch/arm/plat-omap/include/plat/display.h | 28 +- drivers/video/omap2/displays/Kconfig | 22 +- drivers/video/omap2/displays/Makefile | 4 +- drivers/video/omap2/displays/panel-dummy.c | 195 +++ drivers/video/omap2/displays/panel-dummy.h | 119 + drivers/video/omap2/displays/panel-generic.c | 174 --- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 -- .../video/omap2/displays/panel-tpo-td043mtea1.c | 535 16 files changed, 364 insertions(+), 914 deletions(-) create mode 100644 drivers/video/omap2/displays/panel-dummy.c create mode 100644 drivers/video/omap2/displays/panel-dummy.h 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-tpo-td043mtea1.c Why can't panel-generic.c be reused instead of a new panel-dummy.c? Sounds like what you're trying to do is to get a generic panel driver; so shouldn't it at least be called generic instead of dummy. I assume panel-generic is for some DVI output connection, so I picked up dummy. But yeah, I do prefer to panel-generic driver and maybe change the name generic-panel to dvi. -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 1/3] OMAP: DSS2: Add dummy panel display driver
On Tue, Nov 2, 2010 at 1:21 PM, Grazvydas Ignotas nota...@gmail.com wrote:
On Tue, Nov 2, 2010 at 6:13 PM, Bryan Wu bryan...@canonical.com wrote:
Dummy 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 dummy 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-dummy.h to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
snip
diff --git a/drivers/video/omap2/displays/panel-dummy.h
b/drivers/video/omap2/displays/panel-dummy.h
new file mode 100644
index 000..ac2b7a2
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-dummy.h
There is no benefit of having this header, just add all data directly
in .c file.
snip
+ /* Sharp LQ043T1DG01 */
+ {
+ { .x_res = 480,
+ .y_res = 272,
missing newline after {
Thanks, I will take these 2 comments.
--
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 v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. TWL4030 can be enabled on other platforms - it's not tied to OMAP (mostly to enable build coverage). Yes, but if you are manually enabling TWL4030_CORE and REGULATOR, REGULATOR_TWL4030 makes sense. If somebody doesn't want it for some reason, it can be manually disabled. I guess you have seen the complaint from Linus regarding ARM relying too much on defconfigs. This helps in order to simplify defconfigs, and eventually getting rid of them completely. This solution doesn't seem like it scales so well either, it just shifts it into the Kconfig files (where everything is all in central files shared by everyone which has its own problems). Certainly the goal of replacing defconfig files with Kconfig seems unattainable. The difference is that Kconfig files are needed, and part of linux itself. The defconfig files should be optional, there are many, and not necessarily in the linux tree (e.g. meego kernel configs). However, even if you forget about Kconfig vs defconfig, it should be possible to create a .config file from nothing, and when you do that, having REGULATOR_TWL4030 enabled when you enable REGULATOR support just makes sense (if you have enabled TWL4030_CORE). -- 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 v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 2, 2010 at 4:39 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote: 2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by default, too. (TWL4030_CORE doesn't depend on something omapish.) Yes, I think TWL4030_CORE should depend on OMAP3, but I think some people might not like that. That's why I wanted to make that a separate patch. It did originally but that dependency was removed to allow build coverage for non-OMAP users. I'm not sure removing that dependency is worth it. There's probably a lot of code in the kernel that can be built without meeting the specified dependencies. Maybe there should be a way to differentiate soft from hard dependencies for this particular use-case. But I guess for now the lack of dependency should be ok. -- 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 v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 09:43:30PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown This solution doesn't seem like it scales so well either, it just shifts it into the Kconfig files (where everything is all in central files shared by everyone which has its own problems). Certainly the goal of replacing defconfig files with Kconfig seems unattainable. The difference is that Kconfig files are needed, and part of linux itself. The defconfig files should be optional, there are many, and not necessarily in the linux tree (e.g. meego kernel configs). Right, but it's not like you're ever going to get a useful machine configuration just using Kconfig except in the most trivial systems. However, even if you forget about Kconfig vs defconfig, it should be possible to create a .config file from nothing, and when you do that, having REGULATOR_TWL4030 enabled when you enable REGULATOR support just makes sense (if you have enabled TWL4030_CORE). Right, but everyone uses the same Kconfig files while the defconfigs only affect the individual platform which uses them. This is annoying for me since it increases the amount of stuff that gets built into my kernel (I routinely build everything I possibly can in my subsystems for coverage but don't actually want to have all that stuff show up in the kernel image I'm running on my system). The stuff ends up built in due to the issue with MFDs not being buildable as modules since they have interrupt controllers, if that were fixed it wouldn't be an issue. If you're going to make this sort of change we need to have a policy change over all MFD subdevices (and possibly some other things) and decide that we'll eat the costs. Doing it randomly for individual chips and drivers within those chips doesn't seem like a good approach. -- 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 v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 09:46:47PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 4:39 PM, Mark Brown It did originally but that dependency was removed to allow build coverage for non-OMAP users. I'm not sure removing that dependency is worth it. There's probably a lot of code in the kernel that can be built without meeting the specified dependencies. Maybe there should be a way to differentiate soft from hard dependencies for this particular use-case. But I guess for now the lack of dependency should be ok. It's really useful for subsystem maintainers - it means you can do changes over the subsystem without having to have a build lots and lots of different configs per chip to make sure everything still at least compiles. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAP: DSS2: introduce generic panel display driver
There are 4 duplicated panel drivers in DSS2 display driver. They are similar and generic panel driver can support all them with specific panel configuration. And new panel driver can be easily supported by adding panel configurations into generic panel driver. This patchset introduces generic panel driver, remove 3 panel drivers and enable generic panel driver in board files. And it is based on 2.6.37-rc1. 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 panel display driver OMAP: DSS2: remove generic panel driver duplicated panel drivers OMAP: use generic panel driver in board files arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-am3517evm.c |4 +- arch/arm/mach-omap2/board-cm-t35.c |4 +- arch/arm/mach-omap2/board-devkit8000.c |2 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |1 + arch/arm/mach-omap2/board-omap3stalker.c |2 + arch/arm/plat-omap/include/plat/display.h | 28 +++- drivers/video/omap2/displays/Kconfig | 16 +-- drivers/video/omap2/displays/Makefile |2 - drivers/video/omap2/displays/panel-generic.c | 153 -- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 .../video/omap2/displays/panel-toppoly-tdo35s.c| 164 --- 14 files changed, 175 insertions(+), 369 deletions(-) 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 panel display driver
Generic 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 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.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/omap2/displays/Kconfig |4 +-
drivers/video/omap2/displays/panel-generic.c | 153 +++---
2 files changed, 142 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..1a455d7 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -5,7 +5,9 @@ config PANEL_GENERIC
tristate Generic Panel
help
Generic panel driver.
- Used for DVI output for Beagle and OMAP3 SDP.
+ 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_SHARP_LS037V7DW01
tristate Sharp LS037V7DW01 LCD Panel
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 395a68d..88e5bdf 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -1,5 +1,8 @@
/*
- * Generic panel support
+ * Generic 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
@@ -22,22 +25,113 @@
#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,
+/* Panel configurations */
+static struct omap_display_panel generic_panels[] = {
+ /* Generic Panel for DVI */
+ {
+ {
+ .x_res = 640,
+ .y_res = 480,
+
+ .pixel_clock= 23500,
+
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 7,
+ },
+ .acbi = 0x0,
+ .acb= 0x0,
+ .config = OMAP_DSS_LCD_TFT,
+ .power_on_delay = 0,
+ .power_off_delay= 0,
+ .name = dvi,
+ },
+
+ /* Sharp LQ043T1DG01 */
+ {
+ {
+ .x_res = 480,
+ .y_res = 272,
+
+ .pixel_clock= 9000,
+
+ .hsw= 42,
+ .hfp= 3,
+ .hbp= 2,
+
+ .vsw= 11,
+ .vfp= 3,
+ .vbp= 2,
+ },
+ .acbi = 0x0,
+ .acb= 0x0,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IEO,
+ .power_on_delay = 50,
+ .power_off_delay= 100,
+ .name = sharp_lq,
+ },
+
+ /* Sharp LS037V7DW01 */
+ {
+ {
+ .x_res = 480,
+ .y_res = 640,
+
+ .pixel_clock= 19200,
+
+ .hsw= 2,
+ .hfp= 1,
+ .hbp= 28,
+
+ .vsw= 1,
+ .vfp= 1,
+ .vbp= 1,
+ },
+ .acbi = 0x0,
+ .acb= 0x28,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS,
+ .power_on_delay = 50,
+ .power_off_delay= 100,
+ .name = sharp_ls,
+ },
+
+ /* Toppoly TDO35S */
+ {
+ {
+ .x_res = 480,
+
[PATCH 3/3] OMAP: use generic panel driver in board files
Introduce some fields in struct panel, which will be used to match the right
panel configurations in generic panel driver.
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
driver
for sharp_ls_panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-am3517evm.c |4 +++-
arch/arm/mach-omap2/board-cm-t35.c|4 +++-
arch/arm/mach-omap2/board-devkit8000.c|2 ++
arch/arm/mach-omap2/board-igep0020.c |1 +
arch/arm/mach-omap2/board-omap3beagle.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap3stalker.c |2 ++
arch/arm/plat-omap/include/plat/display.h | 28 +++-
9 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..529a016 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -273,6 +273,7 @@ static struct omap_dss_device sdp3430_lcd_device = {
static struct omap_dss_device sdp3430_dvi_device = {
.name = dvi,
.driver_name= generic_panel,
+ .panel.name = dvi,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.platform_enable= sdp3430_panel_enable_dvi,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..e435e66 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -306,7 +306,8 @@ static void am3517_evm_panel_disable_lcd(struct
omap_dss_device *dssdev)
static struct omap_dss_device am3517_evm_lcd_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = lcd,
- .driver_name= sharp_lq_panel,
+ .driver_name= generic_panel,
+ .panel.name = sharp_lq,
.phy.dpi.data_lines = 16,
.platform_enable= am3517_evm_panel_enable_lcd,
.platform_disable = am3517_evm_panel_disable_lcd,
@@ -350,6 +351,7 @@ static struct omap_dss_device am3517_evm_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
.driver_name= generic_panel,
+ .panel.name = dvi,
.phy.dpi.data_lines = 24,
.platform_enable= am3517_evm_panel_enable_dvi,
.platform_disable = am3517_evm_panel_disable_dvi,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..afadebb 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -353,7 +353,8 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device
*dssdev)
static struct omap_dss_device cm_t35_lcd_device = {
.name = lcd,
- .driver_name= toppoly_tdo35s_panel,
+ .driver_name= generic_panel,
+ .panel.name = toppoly_tdo35s,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 18,
.platform_enable= cm_t35_panel_enable_lcd,
@@ -363,6 +364,7 @@ static struct omap_dss_device cm_t35_lcd_device = {
static struct omap_dss_device cm_t35_dvi_device = {
.name = dvi,
.driver_name= generic_panel,
+ .panel.name = dvi,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.platform_enable= cm_t35_panel_enable_dvi,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 067f437..3a5937e 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -152,6 +152,7 @@ static struct regulator_consumer_supply
devkit8000_vio_supply =
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
.driver_name= generic_panel,
+ .panel.name = dvi,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.reset_gpio = -EINVAL, /* will be replaced */
@@ -161,6 +162,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
static struct omap_dss_device devkit8000_dvi_device = {
.name = dvi,
.driver_name= generic_panel,
+ .panel.name = dvi,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.reset_gpio = -EINVAL, /* will be replaced */
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..4c83ef0 100644
[PATCH 2/3] OMAP: DSS2: remove generic 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 | 12 --
drivers/video/omap2/displays/Makefile |2 -
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165
.../video/omap2/displays/panel-toppoly-tdo35s.c| 164 ---
4 files changed, 0 insertions(+), 343 deletions(-)
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 1a455d7..ae1aabe 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -16,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 aa38609..004335c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,8 +1,6 @@
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-sharp-lq043t1dg01.c
b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
deleted file mode 100644
index 0c6896c..000
--- a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
+++ /dev/null
@@ -1,165 +0,0 @@
-/*
- * LCD panel driver for Sharp LQ043T1DG01
- *
- * Copyright (C) 2009 Texas Instruments Inc
- * Author: Vaibhav Hiremath hvaib...@ti.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/device.h
-#include linux/err.h
-
-#include plat/display.h
-
-static struct omap_video_timings sharp_lq_timings = {
- .x_res = 480,
- .y_res = 272,
-
- .pixel_clock= 9000,
-
- .hsw= 42,
- .hfp= 3,
- .hbp= 2,
-
- .vsw= 11,
- .vfp= 3,
- .vbp= 2,
-};
-
-static int sharp_lq_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;
-
- /* wait couple of vsyncs until enabling the LCD */
- msleep(50);
-
- 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 sharp_lq_panel_power_off(struct omap_dss_device *dssdev)
-{
- if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
- return;
-
- if (dssdev-platform_disable)
- dssdev-platform_disable(dssdev);
-
- /* wait at least 5 vsyncs after disabling the LCD */
- msleep(100);
-
- omapdss_dpi_display_disable(dssdev);
-}
-
-static int sharp_lq_panel_probe(struct omap_dss_device *dssdev)
-{
-
- dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
- OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IEO;
- dssdev-panel.acb = 0x0;
- dssdev-panel.timings = sharp_lq_timings;
-
- return 0;
-}
-
-static void sharp_lq_panel_remove(struct omap_dss_device *dssdev)
-{
-}
-
-static int
