Re: DSS2: Compilation Error on Git tree http://www.bat.org/~tomba/git/linux-omap-dss.git
On Wed, 2009-06-03 at 16:07 +0200, ext Venkatesh, Subbu wrote: Hi Tomi, I did git pull to update my tree, later compiling code for LDP, I am getting compilation error as show below. I see that I am missing declaration of struct omap_dss_display_config in display.h file, could you please comment on it... You need to port your LDP changes to newer DSS2 device model. Check how it's done with OMAP SDP or Beagleboard. 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] [MTD] [NAND] Add prefetch and dma support for omap2/3 NAND driver
On Wed, Jun 3, 2009 at 10:03 PM, Tony Lindgren t...@atomide.com wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com [090602
23:46]:
On Wed, Jun 3, 2009 at 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* vimal singh vimalsi...@ti.com [090602 05:40]:
This patch adds prefetch support to access nand flash in both mpu and dma
mode.
This patch also adds 8-bit nand support (omap_read/write_buf8).
Prefetch can be used for both 8- and 16-bit devices.
This should be reviewed on the linux-omap@vger.kernel.org list for sure.
One other comment below.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
I prepared this patch on top of OMAP2 / OMAP3 NAND driver patch:
http://lists.infradead.org/pipermail/linux-mtd/2009-May/025562.html
---
arch/arm/mach-omap2/gpmc.c | 102 ++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 17 +
drivers/mtd/nand/omap2.c | 308
-
4 files changed, 422 insertions(+), 9 deletions(-)
Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
===
--- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
+++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH 7
+#define DMA_MPU_MODE 2
+#endif
+
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -383,6 +389,99 @@ void gpmc_cs_free(int cs)
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/**
+ * gpmc_prefetch_init - configures default configuration for prefetch
engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
Why would you want to have NAND specific init code int gpmc.c?
The purpose if gpmc.c is to provide access to configuring the
General Purpose Memory Controller (GPMC). You should just provide
functions in gpmc.c for the platform init code to use, and then
the drivers can stay platform independent.
In my understanding, this 'prefetch' engine is part of GPMC itself, it is a
kind of feature provided by GPMC which can be utilized by NAND driver.
So, to me, it makes sens to get initialized prefetch by GPMC itself so that
NAND driver can use it.
But it should not have a dependency to NAND.
This engine, in GPMC, is dedicated for NAND devices only.
Another reason was that all read / write to GPMC register are done by
functions 'gpmc_read_reg' / 'gpmc_write_reg', which have been made
'static' in nature.
That's why you need to provide a generic function in gpmc.c to enable
prefetch that the platform code for any driver can use.
Exactly, and whenever a platform code uses gpmc init call, gpmc initializes
this engine too. Since prefetch engine is the part of GPMC, IMHOP, it should
get initialized as part of GPMC initialization.
And then there are prefetch start, stop and status functions calls have been
provided to be used by NAND driver.
-vimal
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB ISSUE on OMAP3530 with USB-2-Ethernet converter
Hi, Anybody had a chance to attend this issue? Any hint to solve the problem? The ASIX AX88772A USB2.0 Fast Ethernet Network Adapter Linux driver available in Asix website supports only upto Linux 2.6.26. I integrated that driver into the git kernel and tested it on the OMAP35xx dev board (EHCI port). The driver detects the presence of USB-2-Ethernet converter and it is possible to assign ip address to the new Ethernet interface. But the ping test fails (ping statistics --- 40 packets transmitted, 0 packets received, 100% packet loss) and therefore I cant continue testing it on the latest git kernel. Any help towards solving this issue will be highly appreciated. Regards, Remith On Fri, May 29, 2009 at 7:46 PM, umesh krishnan umeshde...@gmail.com wrote: Hi, Any help on the below-said musb-issue? -- Forwarded message -- From: Felipe Balbi felipe.ba...@nokia.com Date: Fri, May 29, 2009 at 3:10 PM Subject: Re: MUSB ISSUE on OMAP3530 with USB-2-Ethernet converter To: ext umesh krishnan umeshde...@gmail.com Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org, linux-...@vger.kernel.org Hi, musb should be discussed in linux-usb, but keep linux-omap as Cc. unfortunately I don't have time to help community now due to internal tasks I gotta finish, but I'm sure there's more people in linux-usb that could help you with it. On Fri, May 29, 2009 at 11:24:37AM +0200, ext umesh krishnan wrote: Greetings, I am facing issues while using Asix's AX88772A USB-2-Ethernet converter on my OMAP3530 based product. It uses TI's 2.6.22.18 PSP release-1.0.2 as its OS. The driver for AX8877A was taken from Asix's website. This is one problem, community can only support you with the current version of the open source kernel. Meaning you should try with linux-omap-2.6.git or linux-2.6.git. I am facing kernel crashes when I use the converter on USB OTG port. I am able to get the device detected and also able to assign the ip to the device. But when i repeat the process after plugging-out and plugging-in again and then assigning the ip address , after repeating the process about 9 times, the kernel crashes(when i assign the ip). I tried testing by configuring the musb driver into both OTG and Host only mode. Kernel crashed in both cases. Crash log is attached. (keeping the crash below for reference) - eth1: unregister 'asix' usb-musb_hdrc.0-1, ASIX AX88772A USB 2.0 Ethernet musb_stage0_irq 699: CONNECT (a_host) devctl 5d usb 1-1: new high speed USB device using musb_hdrc and address 3 usb 1-1: Product: AX88x72A usb 1-1: Manufacturer: ASIX Elec. Corp. usb 1-1: SerialNumber: 01 usb 1-1: configuration #1 chosen from 1 choice eth1: register 'asix' at usb-musb_hdrc.0-1, ASIX AX88772A USB 2.0 Ethernet, 00:0e:c6:00:0f:97 [r...@omap3 /]# ping 192.168.13.1 [r...@omap3 /]# ifconfig eth1 192.168.13.254 Unable to handle kernel NULL pointer dereference at virtual address 001c pgd = c719 [001c] *pgd=8706b031, *pte=, *ppte= Internal error: Oops: 17 [#1] Modules linked in: CPU: 0 Not tainted (2.6.22.18-omap3 #1) PC is at musb_start_urb+0x74/0x9b0 LR is at __init_begin+0x3fff8000/0x30 pc : [c0219ac4] lr : [] psr: 6093 sp : c706fc18 ip : c059d1ec fp : c706fcb4 r10: 0020 r9 : r8 : c059d000 r7 : c713e120 r6 : c059d1ec r5 : c059d0d8 r4 : c7f9a9e0 r3 : r2 : r1 : c7f9a9e0 r0 : c059d1ec Flags: nZCv IRQs off FIQs on Mode SVC_32 Segment user Control: 00c5387f Table: 87190018 DAC: 0015 Process ifconfig (pid: 407, stack limit = 0xc706e2d8) Stack: (0xc706fc18 to 0xc707) fc00: 0020 0020 fc20: c706fc44 c706fc30 c02180b4 c02174ec c05c0a00 c706fc64 c03e4464 fc40: c7f9a9e0 c059d0d8 c713e128 c8808000 c059d1ec c706fc68 fc60: c0087f24 c00351dc 005c c03e4464 c706fc9c c706fc80 c002b04c c00688a4 fc80: d820 c059d000 c7f9a9e0 c059d0d8 c059d1ec c713e120 c059d000 fca0: 0020 c706fcf4 c706fcb8 c021a874 c0219a5c c059d000 c713e120 fcc0: a013 0020 0020 871cfa20 c05a1034 c059d000 c713e120 c713e128 fce0: 0020 0020 c706fdbc c706fcf8 c01f8e34 c021a520 c706fd1c c706fd08 fd00: c02180b4 c02174ec c05c0a00 c706fd3c c03e4464 005c fd20: c06753a0 0098 0020 c706fd54 c706fd40 c0087f24 c00351dc fd40: 005c c03e4464 c706fd74 c706fd58 c002b04c c00688a4 d820 fd60: c06753a0 c706fdfc c706fd78 c002ba30 c002b00c c713e120 0020 fd80: 8300 c713e120 c713e120 c713e120 0040 c05a1000 fda0: 0002 0001 0020 c706fdfc c706fdc0 c01f9304 c01f8680 fdc0: c706fde4 c706fdd0 c01f93cc c0169ff8 c713e120 c71cfa20
Re: MUSB ISSUE on OMAP3530 with USB-2-Ethernet converter
On Thu, Jun 04, 2009 at 12:12:04PM +0200, ext Remith Ravi wrote: Hi, Anybody had a chance to attend this issue? Any hint to solve the problem? The ASIX AX88772A USB2.0 Fast Ethernet Network Adapter Linux driver available in Asix website supports only upto Linux 2.6.26. I integrated that driver into the git kernel and tested it on the OMAP35xx dev board (EHCI port). The driver detects the presence of USB-2-Ethernet converter and it is possible to assign ip address to the new Ethernet interface. But the ping test fails (ping statistics --- 40 packets transmitted, 0 packets received, 100% packet loss) and therefore I cant continue testing it on the latest git kernel. Any help towards solving this issue will be highly appreciated. sorry, we can't support you with such an old kernel. You have to fallback to the company who provided you the kernel. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: PM: 2 new entries in SDRC table for Qimonda HYB18M512160AF-6
Ok.. thanks. I just saw this missing in the PM branch and hence posted this. -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, June 03, 2009 6:06 AM To: Nayak, Rajendra Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP3: PM: 2 new entries in SDRC table for Qimonda HYB18M512160AF-6 Hello Rajendra, On Mon, 1 Jun 2009, Rajendra Nayak wrote: This patch adds 2 more entries for new SDRC clock rates (16600 and 8300) in the sdrc params table for Qimonda HYB18M512160AF-6 sdram part. Without this CORE dvfs is broken on the 3430SDP as omap2_sdrc_get_params() call in the dvfs sequence always return 'rate not found' Signed-off-by: Rajendra Nayak rna...@ti.com Commit ID c82881eac1c6999abd768c548ad196c1973d3a55 on l-o master has resolved this. - 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
DSP MMU Fault
Hi everyone, I'm implementing a code on DSP but at the time I do a memory allocation at the DSP side as: short *a; a = malloc(192); // (short*)malloc(192) does not work either But at this line I get the following error and DSP fails afterwards. Then I need to reboot until I can run the application again. 6* DSPMMU FAULT * IRQStatus 0x2 * DSPMMU FAULT * IRQStatus 0x2 6* DSPMMU FAULT * faultAddr 0x230674a0 * DSPMMU FAULT * faultAddr 0x230674a0 6WMD_DEH_Notify: ** DEVICE EXCEPTION ** WMD_DEH_Notify: ** DEVICE EXCEPTION ** 6WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 6WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 6WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 6WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 Do you have any ideas why this might be happening and how to fix it? Thanks a lot. Can -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DSPBRIDGE: Use GT_trace for CLk_Disable message
From: Ameya Palande ameya.pala...@nokia.com
To reduce the unnecessary debug messages polluting the console,
pr_err is replaced by GT_trace which provides finer control for
the visibility of debug messages.
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/services/clk.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index b499b14..f0e46a3 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -277,8 +277,8 @@ DSP_STATUS CLK_Disable(IN enum SERVICES_ClkId clk_id)
SERVICES_Clks[clk_id].clk_name,
SERVICES_Clks[clk_id].id);
} else if (clkUseCnt == 0) {
- pr_err(CLK_Disable: CLK %s, CLK dev id= %d is already
- disabled\n,
+ GT_2trace(CLK_debugMask, GT_4CLASS, CLK_Disable: CLK %s,
+ CLK dev id= %d is already disabled\n,
SERVICES_Clks[clk_id].clk_name,
SERVICES_Clks[clk_id].id);
return status;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
From: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/rmgr/drv_interface.c |2 +-
drivers/dsp/bridge/rmgr/drv_interface.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index c3d8a02..f41e153 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -665,7 +665,7 @@ static int bridge_release(struct inode *ip, struct file
*filp)
}
/* This function provides IO interface to the bridge driver. */
-static int bridge_ioctl(struct file *filp, unsigned int code,
+static long bridge_ioctl(struct file *filp, unsigned int code,
unsigned long args)
{
int status;
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.h
b/drivers/dsp/bridge/rmgr/drv_interface.h
index 3e77ed0..dc49210 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.h
+++ b/drivers/dsp/bridge/rmgr/drv_interface.h
@@ -34,7 +34,7 @@ static int __init bridge_init(void); /* Initialize bridge */
static void __exit bridge_exit(void); /* Opposite of initialize */
static int bridge_open(struct inode *, struct file *); /* Open */
static int bridge_release(struct inode *, struct file *); /* Release */
-static int bridge_ioctl(struct file *, unsigned int,
+static long bridge_ioctl(struct file *, unsigned int,
unsigned long);
static int bridge_mmap(struct file *filp, struct vm_area_struct *vma);
#endif /* ifndef _DRV_INTERFACE_H_ */
--
1.6.2.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: DSP MMU Fault
Hi Can, Do you have any ideas why this might be happening and how to fix it? Thanks a lot. Most probably you might not have mapped the address 0x230674a0. Thank you, Best regards, Hari -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Can Bal Sent: Thursday, June 04, 2009 6:54 AM To: linux-omap@vger.kernel.org Subject: DSP MMU Fault Hi everyone, I'm implementing a code on DSP but at the time I do a memory allocation at the DSP side as: short *a; a = malloc(192); // (short*)malloc(192) does not work either But at this line I get the following error and DSP fails afterwards. Then I need to reboot until I can run the application again. 6* DSPMMU FAULT * IRQStatus 0x2 * DSPMMU FAULT * IRQStatus 0x2 6* DSPMMU FAULT * faultAddr 0x230674a0 * DSPMMU FAULT * faultAddr 0x230674a0 6WMD_DEH_Notify: ** DEVICE EXCEPTION ** WMD_DEH_Notify: ** DEVICE EXCEPTION ** 6WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 6WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 6WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 6WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 Do you have any ideas why this might be happening and how to fix it? Thanks a lot. Can -- 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: LDP support
On Thu, Jun 04, 2009 at 01:41:26AM +0200, ext Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [090603 15:34]: On Thu, Jun 04, 2009 at 12:39:55AM +0300, Imre Deak wrote: I updated the omapfb-upstream branch on git://koowaldah.org/people/imre/linux-2.6-fb, if these are ok with you I'll post them on the fb list. Just be aware that Linus released -rc8 on Tuesday, and said that will be the final rc before the merge window opens. So I reckon there's less than a week to the merge window opening. Imre, few comments after browsing through your patches: omapfb: Add support for MIPI-DCS compatible LCDs seems to depend on drivers/cbus which is not yet merged. Please leave out those parts so it compiles. Then we can add the missing functions once drivers/cbus is merged in the future. omapfb: dispc: Add OMAP3 support should no longer be needed, this got already fixed with clkdev patch 005187eecaa400b4b43d9f640fbde9fcc50f37c1 in mainline. omapfb: Fix coding style / remove dead line has a typo in Russell's name. Thanks, I fixed these and updated the tree. From lcd_mipid I removed the cbus thing and added platform hooks instead, so the backlight code should be now in the board file. This needs to be added for n770, I'll follow-up with a patch for that later. There are two additional patches, one enabling the LCD in the N770 Kconfig and a variable type fix for HWA742. Do you want to put these to omap-fixes or I can just submit them? How about the rest of the Kconfig changes? --Imre -- 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: Question OMAP3 and PM
Kevyn-Alexandre Paré kevyn.alexandre.p...@gmail.com writes: I'm interested in the PM branch latest and greatest that is working for the beagleboard and the omap3evm. I clone these git for master branch and compile and try without success. http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary The 'master' branch of my tree just tracks Tony's tree. If you want to try PM support, then use the branch named 'pm'. Kevin http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary Beagleboard image was freezing after displaying uncompressed with success for both branch. Mistral image was displaying more stuff but no success. I will email the output later. First, I'm interested to know which tag should I use? kernel.org is at 2.6.29.4 for stable should I use these? Best Regards kap -- /** * Ask not what your Linux kernel can do for you - ask what you can do for your Linux kernel * http://www.linuxfoundation.org/en/Kernel_Driver_Statement */ -- 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: LDP support
* Imre Deak imre.d...@nokia.com [090604 07:58]: On Thu, Jun 04, 2009 at 01:41:26AM +0200, ext Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [090603 15:34]: On Thu, Jun 04, 2009 at 12:39:55AM +0300, Imre Deak wrote: I updated the omapfb-upstream branch on git://koowaldah.org/people/imre/linux-2.6-fb, if these are ok with you I'll post them on the fb list. Just be aware that Linus released -rc8 on Tuesday, and said that will be the final rc before the merge window opens. So I reckon there's less than a week to the merge window opening. Imre, few comments after browsing through your patches: omapfb: Add support for MIPI-DCS compatible LCDs seems to depend on drivers/cbus which is not yet merged. Please leave out those parts so it compiles. Then we can add the missing functions once drivers/cbus is merged in the future. omapfb: dispc: Add OMAP3 support should no longer be needed, this got already fixed with clkdev patch 005187eecaa400b4b43d9f640fbde9fcc50f37c1 in mainline. omapfb: Fix coding style / remove dead line has a typo in Russell's name. Thanks, I fixed these and updated the tree. From lcd_mipid I removed the cbus thing and added platform hooks instead, so the backlight code should be now in the board file. This needs to be added for n770, I'll follow-up with a patch for that later. OK, thanks! There are two additional patches, one enabling the LCD in the N770 Kconfig and a variable type fix for HWA742. Do you want to put these to omap-fixes or I can just submit them? How about the rest of the Kconfig changes? I think all these are fine to go via the fb list, just Cc also linux-omap. Then for the patches touching defconfigs and the type fix, please also Cc linux-arm-kernel list too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [MTD] [NAND] Add prefetch and dma support for omap2/3 NAND driver
* vimal singh vimalsi...@ti.com [090604 02:34]:
On Wed, Jun 3, 2009 at 10:03 PM, Tony Lindgren t...@atomide.com wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com [090602
23:46]:
On Wed, Jun 3, 2009 at 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* vimal singh vimalsi...@ti.com [090602 05:40]:
This patch adds prefetch support to access nand flash in both mpu and
dma
mode.
This patch also adds 8-bit nand support (omap_read/write_buf8).
Prefetch can be used for both 8- and 16-bit devices.
This should be reviewed on the linux-omap@vger.kernel.org list for sure.
One other comment below.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
I prepared this patch on top of OMAP2 / OMAP3 NAND driver patch:
http://lists.infradead.org/pipermail/linux-mtd/2009-May/025562.html
---
arch/arm/mach-omap2/gpmc.c | 102 ++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 17 +
drivers/mtd/nand/omap2.c | 308
-
4 files changed, 422 insertions(+), 9 deletions(-)
Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
===
--- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
+++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH 7
+#define DMA_MPU_MODE 2
+#endif
+
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -383,6 +389,99 @@ void gpmc_cs_free(int cs)
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/**
+ * gpmc_prefetch_init - configures default configuration for prefetch
engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
Why would you want to have NAND specific init code int gpmc.c?
The purpose if gpmc.c is to provide access to configuring the
General Purpose Memory Controller (GPMC). You should just provide
functions in gpmc.c for the platform init code to use, and then
the drivers can stay platform independent.
In my understanding, this 'prefetch' engine is part of GPMC itself, it is a
kind of feature provided by GPMC which can be utilized by NAND driver.
So, to me, it makes sens to get initialized prefetch by GPMC itself so that
NAND driver can use it.
But it should not have a dependency to NAND.
This engine, in GPMC, is dedicated for NAND devices only.
Another reason was that all read / write to GPMC register are done by
functions 'gpmc_read_reg' / 'gpmc_write_reg', which have been made
'static' in nature.
That's why you need to provide a generic function in gpmc.c to enable
prefetch that the platform code for any driver can use.
Exactly, and whenever a platform code uses gpmc init call, gpmc initializes
this engine too. Since prefetch engine is the part of GPMC, IMHOP, it should
get initialized as part of GPMC initialization.
No, the driver needing it should initialize it. There should not be any
ifdefs needed in the gpmc.c for that.
And then there are prefetch start, stop and status functions calls have been
provided to be used by NAND driver.
These should really be done in the platform init code for the NAND driver.
The NAND driver really should be generic, not omap specific.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
Wang Sawsd-A24013 cqw...@motorola.com writes: Kevin, See below for more comments/explanations: I still think there at least a couple different problems going on and I think you are addressing some symptoms but not the root cause. I understand that combine these two changes in one patch may cause Some confusion, so this time I separate into two patchs and they are attached. I agree that I didn't describe the issue more in detail, but I think the Second patch (also the original one I intended to make) does address The root cause and not workaround the symptoms. See below for the problem in detail. It would help if you described in more detail the problem(s) you are having and which part of this patch fixes which part of your problem(s). I met this problem when I am using a touch controller that has a firmware That does not work in a graceful way, the controller seems to report Touch event very frequently and seems the HW is too sensitive, this does not mean the issue Is caused by the controller, I think this just make the issue exposed more easily. The controller is using a GPIO to assert interrupt to OMAP, the interrupt Line will be dirven low until the OMAP driver reads out the data through I2C. On OMAP side, we configure the GPIO interrupt pin to be low level detect, Dumb question: Why use level? Why not use falling edge for this? The issue is, after the touch driver calls irq_disable, since it is empty unless Set the IRQ_DISABLED flag, so next time only the generic handler function handle_level_irq is called, this handler just ack to OMAP GPIO IRQ that is To clear the IRQ status and mask the GPIO on OMAP side, but since NO Touch driver IRQ action is called, so the touch Controller can not gets acknowledged, then the interrupt line will be always driven low by the external controller, If the GPIO is set to be edge triggered, the fact that it is still low won't matter, the genirq layer will have noticed a pending interrupt. if we check the IRQ status for that GPIO pin, we will find The IRQ is always set. This will prevent PER enterring RET/OFF state since GPIO Will not acknowledge the IDLE request. The main purpose of the second patch Is to clear the level/edge detect registers for OMAP GPIO when their IRQ is Disabled, this can ensure the GPIO IRQ status will not be set and prevent LPM. Thanks for the very clear explanation. I'm pretty sure I understand what is going on now. I need to think some more about what you describe below, but am curious what you think about using edge triggered GPIOs instead of level. Kevin This GPIO interrupt handling code is very sensitive to changes so we need to really understand your problem before making changes here. I totally undersand this and I am glad to have a thorough understanding By everyone and maybe we can find a better solution for this issue. But now seems I need make you guys understand the issue first. :-) Also it's quite possible there are bugs in your driver as well. Is there any chance you can reproduce this on a public platform such as the 3430SDP using the PM branch? If I use the PM branch on SDP, enable the touchscreen and go into suspend, I do not see the GPIO driver keeping the system out of retention. In addition, if I add enable_irq_wake(gpio_to_irq(ts_gpio)); to the board init code, I can also use the touchscreen as a wakeup source and it does not prevent retention so you should be able to reproduce there. You can say that my touch controller is somehow buggy since it reports Events very frequently and will always keep the interrupt line low unless it is Acknowledged by the touch driver, but I think more important is we can not Expect and *assume* all the peripherals to work as well as we expected, The OMAP GPIO framework should be robust enough to handle such cases Since it will act as a risky hole for PM on OMAP. I understand that this will be hard to reproduce if the Touch controller works Very gracefully, even for us, we do not see the problem on some other HWs Since the controller will not report events/interupts so frequently. Enable_irq_wake and disable_irq_wake is working regardless of irq enabled or disabled Since on OMAP3, they are using IOPAD wakeup(If PER is in RET/OFF) or module level wakeup(if PER is ACTIVE), and the code is handled by gpio suspend/resume functions, see more below. 1: irq mask/unmask are typically used by the IRQ handling framework or CHIP IRQ handler to disable and enable IRQ during the IRQ handing procedure; The mask/unmask are also used by the lazy disable feature of the generic IRQ code. More on this below... I tried to figureout but didn't find any comment on what is the issue fixed By this lazy irq disable or what we can benefit from this lazy irq disable, Seems the change is mainly for x86. The lazy disable is also used so that wakeup interrupts will not be lost between
RE: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 2009年6月5日 1:04 Dumb question: Why use level? Why not use falling edge for this? A good question, :-) We did use edge interrupt before, see the reason below. The issue is, after the touch driver calls irq_disable, since it is empty unless Set the IRQ_DISABLED flag, so next time only the generic handler function handle_level_irq is called, this handler just ack to OMAP GPIO IRQ that is To clear the IRQ status and mask the GPIO on OMAP side, but since NO Touch driver IRQ action is called, so the touch Controller can not gets acknowledged, then the interrupt line will be always driven low by the external controller, If the GPIO is set to be edge triggered, the fact that it is still low won't matter, the genirq layer will have noticed a pending interrupt. If we use edge interrupt here, the potential issue is still existing, and also We are liky to lose the interrupt. After irq_disable and before HW suspend, if the interrupt line is driven low, Then OMAP GPIO can catch this edge transition, so the IRQ is set, Then the handle_edge_irq will clear the IRQ staus and mask the IRQ. Since the controller is not ACKed, then the interrupt line is always driven low, Then from then on, no edge can happen, and no more Touch interrupt can happen Even when irq_enable is called, though we have the prepare for idle hooks, But that only work when the edge transition happens after that prepare call, Since it saves the GPIO data IN at that time, if the input level already changes Before that time, then the workaround does not work. We ever made another patch to not only compare the data in, but also check It is rising or falling edge, and check the CURRENT input level to decide whether to Use LEVEL detect to manually trigger the interrupt, it works fine with our HW. But later on, touch cotroller driver is updated to use level detect, then we Met this issue. I think the patch we made to workaround the edge int lost is also needed In current pm branch, currently we may still face the issue I mentioned above. But think more generically, the kernel should be robust enough to handle such cases, We can not let driver to do the workaround since it is specially OMAP platform issue, Even we have the patch to workaround the edge GPIO IRQ lost issue, but the IRQ staus maybe set again if the interrupt line is driven a second edge. The generic handler will only be called once after irq_disable is called, and If the interrupt happens more than once after that, then we still face the issue that The IRQ status is set and pending there and prevent LPM. I tried to summarize the root cause that we need this change, I think it can be simply Two points: 1: on OMAP, GPIO IRQ status may be set as long as LEVEL/EDGE detect register is configured, regardless of IRQEN or WKEN 2: Pending GPIO IRQ status will impact LPM transition Hope this can explain more on this patch. Thanks, Chunqiu if we check the IRQ status for that GPIO pin, we will find The IRQ is always set. This will prevent PER enterring RET/OFF state since GPIO Will not acknowledge the IDLE request. The main purpose of the second patch Is to clear the level/edge detect registers for OMAP GPIO when their IRQ is Disabled, this can ensure the GPIO IRQ status will not be set and prevent LPM. Thanks for the very clear explanation. I'm pretty sure I understand what is going on now. I need to think some more about what you describe below, but am curious what you think about using edge triggered GPIOs instead of level. See the above explanation 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 01/20] omapfb: Add support for the Apollon LCD
From: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/Makefile |2 +
drivers/video/omap/lcd_apollon.c | 138 ++
2 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap/lcd_apollon.c
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index ed13889..d053498 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -24,5 +24,7 @@ objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) +=
lcd_inn1610.o
objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
+objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
+
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/omap/lcd_apollon.c b/drivers/video/omap/lcd_apollon.c
new file mode 100644
index 000..626ae3a
--- /dev/null
+++ b/drivers/video/omap/lcd_apollon.c
@@ -0,0 +1,138 @@
+/*
+ * LCD panel support for the Samsung OMAP2 Apollon board
+ *
+ * Copyright (C) 2005,2006 Samsung Electronics
+ * Author: Kyungmin Park kyungmin.p...@samsung.com
+ *
+ * Derived from drivers/video/omap/lcd-h4.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+
+#include mach/gpio.h
+#include mach/mux.h
+#include mach/omapfb.h
+
+/* #define USE_35INCH_LCD 1 */
+
+static int apollon_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ /* configure LCD PWR_EN */
+ omap_cfg_reg(M21_242X_GPIO11);
+ return 0;
+}
+
+static void apollon_panel_cleanup(struct lcd_panel *panel)
+{
+}
+
+static int apollon_panel_enable(struct lcd_panel *panel)
+{
+ return 0;
+}
+
+static void apollon_panel_disable(struct lcd_panel *panel)
+{
+}
+
+static unsigned long apollon_panel_get_caps(struct lcd_panel *panel)
+{
+ return 0;
+}
+
+struct lcd_panel apollon_panel = {
+ .name = apollon,
+ .config = OMAP_LCDC_PANEL_TFT | OMAP_LCDC_INV_VSYNC |
+ OMAP_LCDC_INV_HSYNC,
+
+ .bpp= 16,
+ .data_lines = 18,
+#ifdef USE_35INCH_LCD
+ .x_res = 240,
+ .y_res = 320,
+ .hsw= 2,
+ .hfp= 3,
+ .hbp= 9,
+ .vsw= 4,
+ .vfp= 3,
+ .vbp= 5,
+#else
+ .x_res = 480,
+ .y_res = 272,
+ .hsw= 41,
+ .hfp= 2,
+ .hbp= 2,
+ .vsw= 10,
+ .vfp= 2,
+ .vbp= 2,
+#endif
+ .pixel_clock= 6250,
+
+ .init = apollon_panel_init,
+ .cleanup= apollon_panel_cleanup,
+ .enable = apollon_panel_enable,
+ .disable= apollon_panel_disable,
+ .get_caps = apollon_panel_get_caps,
+};
+
+static int apollon_panel_probe(struct platform_device *pdev)
+{
+ omapfb_register_panel(apollon_panel);
+ return 0;
+}
+
+static int apollon_panel_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int apollon_panel_suspend(struct platform_device *pdev,
+ pm_message_t mesg)
+{
+ return 0;
+}
+
+static int apollon_panel_resume(struct platform_device *pdev)
+{
+ return 0;
+}
+
+struct platform_driver apollon_panel_driver = {
+ .probe = apollon_panel_probe,
+ .remove = apollon_panel_remove,
+ .suspend= apollon_panel_suspend,
+ .resume = apollon_panel_resume,
+ .driver = {
+ .name = apollon_lcd,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init apollon_panel_drv_init(void)
+{
+ return platform_driver_register(apollon_panel_driver);
+}
+
+static void __exit apollon_panel_drv_exit(void)
+{
+ platform_driver_unregister(apollon_panel_driver);
+}
+
+module_init(apollon_panel_drv_init);
+module_exit(apollon_panel_drv_exit);
--
1.6.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH 03/20] N770: Enable LCD MIPI-DCS in Kconfig
CC: linux-arm-ker...@lists.arm.linux.org.uk Signed-off-by: Imre Deak imre.d...@nokia.com --- arch/arm/configs/n770_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/n770_defconfig b/arch/arm/configs/n770_defconfig index 672f6db..a1657b7 100644 --- a/arch/arm/configs/n770_defconfig +++ b/arch/arm/configs/n770_defconfig @@ -875,7 +875,7 @@ CONFIG_FB_OMAP_LCDC_EXTERNAL=y CONFIG_FB_OMAP_LCDC_HWA742=y # CONFIG_FB_OMAP_LCDC_BLIZZARD is not set CONFIG_FB_OMAP_MANUAL_UPDATE=y -# CONFIG_FB_OMAP_LCD_MIPID is not set +CONFIG_FB_OMAP_LCD_MIPID=y # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2 # CONFIG_FB_OMAP_DMA_TUNE is not set -- 1.6.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/20] omapfb: Add support for the OMAP2EVM LCD
From: arun c arun.edar...@gmail.com
omap2evm LCD supports VGA and QVGA resolution, by default its in VGA mode.
Signed-off-by: Arun C arunedar...@mistralsolutions.com
Signed-off-by: Tony Lindgren t...@atomide.com
Fixed-by: Jarkko Nikula jarkko.nik...@gmail.com
Fixed-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/Makefile |1 +
drivers/video/omap/lcd_omap2evm.c | 189 +
2 files changed, 190 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap/lcd_omap2evm.c
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 7a37b03..c2475e3 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -27,6 +27,7 @@ objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
+objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/omap/lcd_omap2evm.c
b/drivers/video/omap/lcd_omap2evm.c
new file mode 100644
index 000..2fc46c2
--- /dev/null
+++ b/drivers/video/omap/lcd_omap2evm.c
@@ -0,0 +1,189 @@
+/*
+ * LCD panel support for the MISTRAL OMAP2EVM board
+ *
+ * Author: Arun C arunedar...@mistralsolutions.com
+ *
+ * Derived from drivers/video/omap/lcd_omap3evm.c
+ * Derived from drivers/video/omap/lcd-apollon.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/i2c/twl4030.h
+
+#include mach/mux.h
+#include mach/omapfb.h
+#include asm/mach-types.h
+
+#define LCD_PANEL_ENABLE_GPIO 154
+#define LCD_PANEL_LR 128
+#define LCD_PANEL_UD 129
+#define LCD_PANEL_INI 152
+#define LCD_PANEL_QVGA 148
+#define LCD_PANEL_RESB 153
+
+#define LCD_XRES 480
+#define LCD_YRES 640
+#define LCD_PIXCLOCK_MAX 2 /* in kHz */
+
+#define TWL_LED_LEDEN 0x00
+#define TWL_PWMA_PWMAON0x00
+#define TWL_PWMA_PWMAOFF 0x01
+
+static unsigned int bklight_level;
+
+static int omap2evm_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ gpio_request(LCD_PANEL_ENABLE_GPIO, LCD enable);
+ gpio_request(LCD_PANEL_LR, LCD lr);
+ gpio_request(LCD_PANEL_UD, LCD ud);
+ gpio_request(LCD_PANEL_INI, LCD ini);
+ gpio_request(LCD_PANEL_QVGA, LCD qvga);
+ gpio_request(LCD_PANEL_RESB, LCD resb);
+
+ gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+ gpio_direction_output(LCD_PANEL_RESB, 1);
+ gpio_direction_output(LCD_PANEL_INI, 1);
+ gpio_direction_output(LCD_PANEL_QVGA, 0);
+ gpio_direction_output(LCD_PANEL_LR, 1);
+ gpio_direction_output(LCD_PANEL_UD, 1);
+
+ twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, 0x02, TWL_PWMA_PWMAOFF);
+ bklight_level = 100;
+
+ return 0;
+}
+
+static void omap2evm_panel_cleanup(struct lcd_panel *panel)
+{
+}
+
+static int omap2evm_panel_enable(struct lcd_panel *panel)
+{
+ gpio_set_value(LCD_PANEL_ENABLE_GPIO, 0);
+ return 0;
+}
+
+static void omap2evm_panel_disable(struct lcd_panel *panel)
+{
+ gpio_set_value(LCD_PANEL_ENABLE_GPIO, 1);
+}
+
+static unsigned long omap2evm_panel_get_caps(struct lcd_panel *panel)
+{
+ return 0;
+}
+
+static int omap2evm_bklight_setlevel(struct lcd_panel *panel,
+ unsigned int level)
+{
+ u8 c;
+ if ((level = 0) (level = 100)) {
+ c = (125 * (100 - level)) / 100 + 2;
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF);
+ bklight_level = level;
+ }
+ return 0;
+}
+
+static unsigned int omap2evm_bklight_getlevel(struct lcd_panel *panel)
+{
+ return bklight_level;
+}
+
+static unsigned int omap2evm_bklight_getmaxlevel(struct lcd_panel *panel)
+{
+ return 100;
+}
+
+struct lcd_panel omap2evm_panel = {
+ .name = omap2evm,
[PATCH 00/20] omapfb: Add support for new LCDs / misc fixes
Hi, I'd like to ask for the merging of this patchset into Linus' tree. It adds support for new LCDs on OMAP based boards (01-12) and fixes generic parts of the omapfb driver (13-20). The changes have been staged in the Linux OMAP tree for quite a long time, so they should be safe to be merged. Note that this is about the existing DSS1 FB driver which will eventually be replaced by Tomi Valkeinen's DSS2 FB driver. Thanks, Imre [PATCH 01/20] omapfb: Add support for the Apollon LCD [PATCH 02/20] omapfb: Add support for MIPI-DCS compatible LCDs [PATCH 03/20] N770: Enable LCD MIPI-DCS in Kconfig [PATCH 04/20] omapfb: Add support for the Amstrad Delta LCD [PATCH 05/20] omapfb: Add support for the 2430SDP LCD [PATCH 06/20] omapfb: Add support for the OMAP2EVM LCD [PATCH 07/20] omapfb: Add support for the 3430SDP LCD [PATCH 08/20] omapfb: Add support for the OMAP3 EVM LCD [PATCH 09/20] omapfb: Add support for the OMAP3 Beagle DVI output [PATCH 10/20] omapfb: Add support for the Gumstix Overo LCD [PATCH 11/20] omapfb: Add support for the ZOOM MDK LCD [PATCH 12/20] omapfb: Add support for rotation on the Blizzard LCD ctrl [PATCH 13/20] omapfb: dispc: Various typo fixes [PATCH 14/20] omapfb: dispc: Disable iface clocks along with func clocks [PATCH 15/20] omapfb: dispc: Enable wake up capability [PATCH 16/20] omapfb: dispc: Allow multiple external IRQ handlers [PATCH 17/20] omapfb: suspend/resume only if FB device is already initialized [PATCH 18/20] omapfb: Fix coding style / remove dead line [PATCH 19/20] omapfb: Add FB manual update option to Kconfig [PATCH 20/20] omapfb: HWA742: fix pointer to be const -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/20] omapfb: Add support for MIPI-DCS compatible LCDs
Fixed-by: Mike Wege ext-mike.w...@nokia.com
Fixed-by: Arnaud Patard arnaud.pat...@rtp-net.org
Fixed-by: Timo Savola tsav...@movial.fi
Fixed-by: Hiroshi DOYU hiroshi.d...@nokia.com
Fixed-by: Trilok Soni soni.tri...@gmail.com
Signed-off-by: Imre Deak imre.d...@solidboot.com
Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com
---
arch/arm/plat-omap/include/mach/lcd_mipid.h |5 +
drivers/video/omap/Kconfig |8 +
drivers/video/omap/Makefile |1 +
drivers/video/omap/lcd_mipid.c | 631 +++
4 files changed, 645 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap/lcd_mipid.c
diff --git a/arch/arm/plat-omap/include/mach/lcd_mipid.h
b/arch/arm/plat-omap/include/mach/lcd_mipid.h
index f8fbc48..8e52c65 100644
--- a/arch/arm/plat-omap/include/mach/lcd_mipid.h
+++ b/arch/arm/plat-omap/include/mach/lcd_mipid.h
@@ -16,7 +16,12 @@ enum mipid_test_result {
struct mipid_platform_data {
int nreset_gpio;
int data_lines;
+
void(*shutdown)(struct mipid_platform_data *pdata);
+ void(*set_bklight_level)(struct mipid_platform_data *pdata,
+int level);
+ int (*get_bklight_level)(struct mipid_platform_data *pdata);
+ int (*get_bklight_max)(struct mipid_platform_data *pdata);
};
#endif
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 4440885..574453f 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -7,6 +7,14 @@ config FB_OMAP
help
Frame buffer driver for OMAP based boards.
+config FB_OMAP_LCD_MIPID
+ bool MIPI DBI-C/DCS compatible LCD support
+ depends on FB_OMAP SPI_MASTER
+ help
+ Say Y here if you want to have support for LCDs compatible with
+ the Mobile Industry Processor Interface DBI-C/DCS
+ specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3)
+
config FB_OMAP_BOOTLOADER_INIT
bool Check bootloader initialization
depends on FB_OMAP
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index d053498..d86d54a 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -25,6 +25,7 @@ objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) +=
lcd_inn1510.o
objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
+objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/omap/lcd_mipid.c b/drivers/video/omap/lcd_mipid.c
new file mode 100644
index 000..3165d3d
--- /dev/null
+++ b/drivers/video/omap/lcd_mipid.c
@@ -0,0 +1,631 @@
+/*
+ * LCD driver for MIPI DBI-C / DCS compatible LCDs
+ *
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+#include linux/device.h
+#include linux/delay.h
+#include linux/workqueue.h
+#include linux/spi/spi.h
+
+#include mach/omapfb.h
+#include mach/lcd_mipid.h
+
+#define MIPID_MODULE_NAME lcd_mipid
+
+#define MIPID_CMD_READ_DISP_ID 0x04
+#define MIPID_CMD_READ_RED 0x06
+#define MIPID_CMD_READ_GREEN 0x07
+#define MIPID_CMD_READ_BLUE0x08
+#define MIPID_CMD_READ_DISP_STATUS 0x09
+#define MIPID_CMD_RDDSDR 0x0F
+#define MIPID_CMD_SLEEP_IN 0x10
+#define MIPID_CMD_SLEEP_OUT0x11
+#define MIPID_CMD_DISP_OFF 0x28
+#define MIPID_CMD_DISP_ON 0x29
+
+#define MIPID_VER_LPH8923 3
+#define MIPID_VER_LS041Y3 4
+
+#define MIPID_ESD_CHECK_PERIOD msecs_to_jiffies(5000)
+
+#define to_mipid_device(p) container_of(p, struct mipid_device, \
+ panel)
+struct mipid_device {
+ int enabled;
+ int model;
+ int revision;
+ u8 display_id[3];
+ unsigned intsaved_bklight_level;
+ unsigned long hw_guard_end; /* next value of jiffies
+ when we can issue the
+ next sleep in/out command */
+
[PATCH 08/20] omapfb: Add support for the OMAP3 EVM LCD
From: Steve Sakoman st...@sakoman.com
Add LCD support for OMAP3 EVM
Backlight support by Arun C arunedar...@mistralsolutions.com
Signed-off-by: Steve Sakoman st...@sakoman.com
Acked-by: Syed Mohammed Khasim kha...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Fixed-by: Jarkko Nikula jarkko.nik...@gmail.com
Fixed-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/Makefile |1 +
drivers/video/omap/lcd_omap3evm.c | 191 +
2 files changed, 192 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap/lcd_omap3evm.c
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 96d2d43..4345157 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -30,6 +30,7 @@ objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
+objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/omap/lcd_omap3evm.c
b/drivers/video/omap/lcd_omap3evm.c
new file mode 100644
index 000..1c3d814
--- /dev/null
+++ b/drivers/video/omap/lcd_omap3evm.c
@@ -0,0 +1,191 @@
+/*
+ * LCD panel support for the TI OMAP3 EVM board
+ *
+ * Author: Steve Sakoman st...@sakoman.com
+ *
+ * Derived from drivers/video/omap/lcd-apollon.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/i2c/twl4030.h
+
+#include mach/mux.h
+#include mach/omapfb.h
+#include asm/mach-types.h
+
+#define LCD_PANEL_ENABLE_GPIO 153
+#define LCD_PANEL_LR2
+#define LCD_PANEL_UD3
+#define LCD_PANEL_INI 152
+#define LCD_PANEL_QVGA 154
+#define LCD_PANEL_RESB 155
+
+#define LCD_XRES 480
+#define LCD_YRES 640
+#define LCD_PIXCLOCK 26000 /* in kHz */
+
+#define ENABLE_VDAC_DEDICATED 0x03
+#define ENABLE_VDAC_DEV_GRP0x20
+#define ENABLE_VPLL2_DEDICATED 0x05
+#define ENABLE_VPLL2_DEV_GRP 0xE0
+
+#define TWL_LED_LEDEN 0x00
+#define TWL_PWMA_PWMAON0x00
+#define TWL_PWMA_PWMAOFF 0x01
+
+static unsigned int bklight_level;
+
+static int omap3evm_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ gpio_request(LCD_PANEL_LR, LCD lr);
+ gpio_request(LCD_PANEL_UD, LCD ud);
+ gpio_request(LCD_PANEL_INI, LCD ini);
+ gpio_request(LCD_PANEL_RESB, LCD resb);
+ gpio_request(LCD_PANEL_QVGA, LCD qvga);
+
+ gpio_direction_output(LCD_PANEL_RESB, 1);
+ gpio_direction_output(LCD_PANEL_INI, 1);
+ gpio_direction_output(LCD_PANEL_QVGA, 0);
+ gpio_direction_output(LCD_PANEL_LR, 1);
+ gpio_direction_output(LCD_PANEL_UD, 1);
+
+ twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, 0x02, TWL_PWMA_PWMAOFF);
+ bklight_level = 100;
+
+ return 0;
+}
+
+static void omap3evm_panel_cleanup(struct lcd_panel *panel)
+{
+}
+
+static int omap3evm_panel_enable(struct lcd_panel *panel)
+{
+ gpio_set_value(LCD_PANEL_ENABLE_GPIO, 0);
+ return 0;
+}
+
+static void omap3evm_panel_disable(struct lcd_panel *panel)
+{
+ gpio_set_value(LCD_PANEL_ENABLE_GPIO, 1);
+}
+
+static unsigned long omap3evm_panel_get_caps(struct lcd_panel *panel)
+{
+ return 0;
+}
+
+static int omap3evm_bklight_setlevel(struct lcd_panel *panel,
+ unsigned int level)
+{
+ u8 c;
+ if ((level = 0) (level = 100)) {
+ c = (125 * (100 - level)) / 100 + 2;
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF);
+ bklight_level = level;
+ }
+ return 0;
+}
+
+static unsigned int omap3evm_bklight_getlevel(struct lcd_panel *panel)
+{
+ return bklight_level;
+}
+
+static unsigned int omap3evm_bklight_getmaxlevel(struct
[PATCH 05/20] omapfb: Add support for the 2430SDP LCD
From: Hunyue Yau h...@mvista.com
Add glue to control the 2430SDP LCD as a frame buffer device
using the existing dispc.c driver under omapfb.
Signed-off-by: Hunyue Yau h...@mvista.com
Signed-off-by: Kevin Hilman khil...@mvista.com
Signed-off-by: Tony Lindgren t...@atomide.com
Fixed-by: Kevin Hilman khil...@mvista.com
Fixed-by: Sergio Aguirre saagui...@ti.com
Fixed-by: Francisco Alecrim francisco.alec...@indt.org.br
Fixed-by: Tony Lindgren t...@atomide.com
Fixed-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/Makefile |1 +
drivers/video/omap/lcd_2430sdp.c | 196 ++
2 files changed, 197 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap/lcd_2430sdp.c
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 2bf94ad..7a37b03 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -26,6 +26,7 @@ objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) +=
lcd_inn1510.o
objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
+objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/omap/lcd_2430sdp.c b/drivers/video/omap/lcd_2430sdp.c
new file mode 100644
index 000..5bcbb8d
--- /dev/null
+++ b/drivers/video/omap/lcd_2430sdp.c
@@ -0,0 +1,196 @@
+/*
+ * LCD panel support for the TI 2430SDP board
+ *
+ * Copyright (C) 2007 MontaVista
+ * Author: Hunyue Yau h...@mvista.com
+ *
+ * Derived from drivers/video/omap/lcd-apollon.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/i2c/twl4030.h
+
+#include mach/mux.h
+#include mach/omapfb.h
+#include asm/mach-types.h
+
+#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO 91
+#define SDP2430_LCD_PANEL_ENABLE_GPIO 154
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 24
+#define SDP3430_LCD_PANEL_ENABLE_GPIO 28
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+
+#define LCD_PANEL_BACKLIGHT_GPIO 91
+#define LCD_PANEL_ENABLE_GPIO 154
+#define LCD_PIXCLOCK_MAX 5400 /* freq 5.4 MHz */
+#define PM_RECEIVER TWL4030_MODULE_PM_RECEIVER
+#define ENABLE_VAUX2_DEDICATED 0x09
+#define ENABLE_VAUX2_DEV_GRP0x20
+
+
+#define t2_out(c, r, v) twl4030_i2c_write_u8(c, r, v)
+
+
+static int sdp2430_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ if (machine_is_omap_3430sdp()) {
+ enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
+ backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+ } else {
+ enable_gpio= SDP2430_LCD_PANEL_ENABLE_GPIO;
+ backlight_gpio = SDP2430_LCD_PANEL_BACKLIGHT_GPIO;
+ }
+
+ gpio_request(enable_gpio, LCD enable);/* LCD panel */
+ gpio_request(backlight_gpio, LCD bl); /* LCD backlight */
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+
+ return 0;
+}
+
+static void sdp2430_panel_cleanup(struct lcd_panel *panel)
+{
+}
+
+static int sdp2430_panel_enable(struct lcd_panel *panel)
+{
+ u8 ded_val, ded_reg;
+ u8 grp_val, grp_reg;
+
+ if (machine_is_omap_3430sdp()) {
+ ded_reg = TWL4030_VAUX3_DEDICATED;
+ ded_val = ENABLE_VAUX3_DEDICATED;
+ grp_reg = TWL4030_VAUX3_DEV_GRP;
+ grp_val = ENABLE_VAUX3_DEV_GRP;
+
+ if (omap_rev() OMAP3430_REV_ES1_0) {
+ t2_out(PM_RECEIVER, ENABLE_VPLL2_DEDICATED,
+ TWL4030_VPLL2_DEDICATED);
+ t2_out(PM_RECEIVER, ENABLE_VPLL2_DEV_GRP,
+ TWL4030_VPLL2_DEV_GRP);
+ }
+ } else {
+ ded_reg = TWL4030_VAUX2_DEDICATED;
+ ded_val = ENABLE_VAUX2_DEDICATED;
+ grp_reg = TWL4030_VAUX2_DEV_GRP;
+ grp_val = ENABLE_VAUX2_DEV_GRP;
+ }
+
+ gpio_set_value(enable_gpio, 1);
+
[PATCH 04/20] omapfb: Add support for the Amstrad Delta LCD
From: Jonathan McDowell nood...@earth.li
This is an updated version of the LCD driver for the Amstrad Delta to
take into account the recent changes to the omapfb infrastructure. The
Delta features a 480x320 12 bit DSTN panel.
Signed-off-by: Jonathan McDowell nood...@earth.li
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/Makefile|1 +
drivers/video/omap/lcd_ams_delta.c | 137
2 files changed, 138 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap/lcd_ams_delta.c
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index d86d54a..2bf94ad 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -15,6 +15,7 @@ objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) +=
rfbi.o
objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o
objs-y$(CONFIG_FB_OMAP_LCDC_BLIZZARD) += blizzard.o
+objs-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o
objs-y$(CONFIG_MACH_OMAP_H4) += lcd_h4.o
objs-y$(CONFIG_MACH_OMAP_H3) += lcd_h3.o
objs-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o
diff --git a/drivers/video/omap/lcd_ams_delta.c
b/drivers/video/omap/lcd_ams_delta.c
new file mode 100644
index 000..1f74399
--- /dev/null
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -0,0 +1,137 @@
+/*
+ * Based on drivers/video/omap/lcd_inn1510.c
+ *
+ * LCD panel support for the Amstrad E3 (Delta) videophone.
+ *
+ * Copyright (C) 2006 Jonathan McDowell nood...@earth.li
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/delay.h
+
+#include mach/board-ams-delta.h
+#include mach/hardware.h
+#include mach/omapfb.h
+
+#define AMS_DELTA_DEFAULT_CONTRAST 112
+
+static int ams_delta_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ return 0;
+}
+
+static void ams_delta_panel_cleanup(struct lcd_panel *panel)
+{
+}
+
+static int ams_delta_panel_enable(struct lcd_panel *panel)
+{
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP,
+ AMS_DELTA_LATCH2_LCD_NDISP);
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN,
+ AMS_DELTA_LATCH2_LCD_VBLEN);
+
+ omap_writeb(1, OMAP_PWL_CLK_ENABLE);
+ omap_writeb(AMS_DELTA_DEFAULT_CONTRAST, OMAP_PWL_ENABLE);
+
+ return 0;
+}
+
+static void ams_delta_panel_disable(struct lcd_panel *panel)
+{
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN, 0);
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_NDISP, 0);
+}
+
+static unsigned long ams_delta_panel_get_caps(struct lcd_panel *panel)
+{
+ return 0;
+}
+
+static struct lcd_panel ams_delta_panel = {
+ .name = ams-delta,
+ .config = 0,
+
+ .bpp= 12,
+ .data_lines = 16,
+ .x_res = 480,
+ .y_res = 320,
+ .pixel_clock= 4687,
+ .hsw= 3,
+ .hfp= 1,
+ .hbp= 1,
+ .vsw= 1,
+ .vfp= 0,
+ .vbp= 0,
+ .pcd= 0,
+ .acb= 37,
+
+ .init = ams_delta_panel_init,
+ .cleanup= ams_delta_panel_cleanup,
+ .enable = ams_delta_panel_enable,
+ .disable= ams_delta_panel_disable,
+ .get_caps = ams_delta_panel_get_caps,
+};
+
+static int ams_delta_panel_probe(struct platform_device *pdev)
+{
+ omapfb_register_panel(ams_delta_panel);
+ return 0;
+}
+
+static int ams_delta_panel_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int ams_delta_panel_suspend(struct platform_device *pdev,
+ pm_message_t mesg)
+{
+ return 0;
+}
+
+static int ams_delta_panel_resume(struct platform_device *pdev)
+{
+ return 0;
+}
+
+struct platform_driver ams_delta_panel_driver = {
+ .probe = ams_delta_panel_probe,
+ .remove = ams_delta_panel_remove,
+ .suspend= ams_delta_panel_suspend,
+ .resume = ams_delta_panel_resume,
+ .driver = {
+ .name = lcd_ams_delta,
+ .owner = THIS_MODULE,
+
[PATCH 14/20] omapfb: dispc: Disable iface clocks along with func clocks
From: Jouni Hogander jouni.hogan...@nokia.com
Leaving interface clocks enabled causes dss pwrdm to stay in active
state when mpu is in active state. This fix puts dss to sleep state
when it is not needed.
Earlier version broke framebuffer on 24xx. This is fixed by enabling
clocks before trying to access DISPC_IRQSTATUS register.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/dispc.c | 23 ++-
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 2db8fbb..cc3c817 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -858,8 +858,11 @@ EXPORT_SYMBOL(omap_dispc_free_irq);
static irqreturn_t omap_dispc_irq_handler(int irq, void *dev)
{
- u32 stat = dispc_read_reg(DISPC_IRQSTATUS);
+ u32 stat;
+ enable_lcd_clocks(1);
+
+ stat = dispc_read_reg(DISPC_IRQSTATUS);
if (stat DISPC_IRQ_FRAMEMASK)
complete(dispc.frame_done);
@@ -875,6 +878,8 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
dispc_write_reg(DISPC_IRQSTATUS, stat);
+ enable_lcd_clocks(0);
+
return IRQ_HANDLED;
}
@@ -913,18 +918,13 @@ static void put_dss_clocks(void)
static void enable_lcd_clocks(int enable)
{
- if (enable)
+ if (enable) {
+ clk_enable(dispc.dss_ick);
clk_enable(dispc.dss1_fck);
- else
+ } else {
clk_disable(dispc.dss1_fck);
-}
-
-static void enable_interface_clocks(int enable)
-{
- if (enable)
- clk_enable(dispc.dss_ick);
- else
clk_disable(dispc.dss_ick);
+ }
}
static void enable_digit_clocks(int enable)
@@ -1365,7 +1365,6 @@ static int omap_dispc_init(struct omapfb_device *fbdev,
int ext_mode,
if ((r = get_dss_clocks()) 0)
goto fail0;
- enable_interface_clocks(1);
enable_lcd_clocks(1);
#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
@@ -1469,7 +1468,6 @@ fail2:
free_irq(INT_24XX_DSS_IRQ, fbdev);
fail1:
enable_lcd_clocks(0);
- enable_interface_clocks(0);
put_dss_clocks();
fail0:
iounmap(dispc.base);
@@ -1487,7 +1485,6 @@ static void omap_dispc_cleanup(void)
cleanup_fbmem();
free_palette_ram();
free_irq(INT_24XX_DSS_IRQ, dispc.fbdev);
- enable_interface_clocks(0);
put_dss_clocks();
iounmap(dispc.base);
}
--
1.6.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/20] omapfb: Add support for rotation on the Blizzard LCD ctrl
From: Rodrigo Vivi rodrigo.v...@openbossa.org
The LCD controller (EPSON S1D13744) supports rotation (0, 90, 180
and 270 degrees) on hardware just setting the bits 0 and 1 of 0x28
register (LCD Panel Configuration Register). Now it is possible to
use this caps only setting the angle degree on var rotate of
fb_var_screeninfo using the FBIOPUT_VSCREENINFO ioctl.
Signed-off-by: Rodrigo Vivi rodrigo.v...@openbossa.org
Signed-off-by: Tony Lindgren t...@atomide.com
Fixed-by: Siarhei Siamashka siarhei.siamas...@nokia.com
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/blizzard.c| 91 +++--
drivers/video/omap/omapfb_main.c | 52 --
2 files changed, 124 insertions(+), 19 deletions(-)
diff --git a/drivers/video/omap/blizzard.c b/drivers/video/omap/blizzard.c
index 9dfcf39..d5e5955 100644
--- a/drivers/video/omap/blizzard.c
+++ b/drivers/video/omap/blizzard.c
@@ -44,6 +44,7 @@
#define BLIZZARD_CLK_SRC 0x0e
#define BLIZZARD_MEM_BANK0_ACTIVATE0x10
#define BLIZZARD_MEM_BANK0_STATUS 0x14
+#define BLIZZARD_PANEL_CONFIGURATION 0x28
#define BLIZZARD_HDISP 0x2a
#define BLIZZARD_HNDP 0x2c
#define BLIZZARD_VDISP00x2e
@@ -162,6 +163,10 @@ struct blizzard_struct {
int vid_scaled;
int last_color_mode;
int zoom_on;
+ int zoom_area_gx1;
+ int zoom_area_gx2;
+ int zoom_area_gy1;
+ int zoom_area_gy2;
int screen_width;
int screen_height;
unsignedte_connected:1;
@@ -513,6 +518,13 @@ static int do_full_screen_update(struct blizzard_request
*req)
return REQ_PENDING;
}
+static int check_1d_intersect(int a1, int a2, int b1, int b2)
+{
+ if (a2 = b1 || b2 = a1)
+ return 0;
+ return 1;
+}
+
/* Setup all planes with an overlapping area with the update window. */
static int do_partial_update(struct blizzard_request *req, int plane,
int x, int y, int w, int h,
@@ -525,6 +537,7 @@ static int do_partial_update(struct blizzard_request *req,
int plane,
int color_mode;
int flags;
int zoom_off;
+ int have_zoom_for_this_update = 0;
/* Global coordinates, relative to pixel 0,0 of the LCD */
gx1 = x + blizzard.plane[plane].pos_x;
@@ -544,10 +557,6 @@ static int do_partial_update(struct blizzard_request *req,
int plane,
gx2_out = gx1_out + w_out;
gy2_out = gy1_out + h_out;
}
- zoom_off = blizzard.zoom_on gx1 == 0 gy1 == 0
- w == blizzard.screen_width h == blizzard.screen_height;
- blizzard.zoom_on = (!zoom_off blizzard.zoom_on) ||
- (w w_out || h h_out);
for (i = 0; i OMAPFB_PLANE_NUM; i++) {
struct plane_info *p = blizzard.plane[i];
@@ -653,8 +662,49 @@ static int do_partial_update(struct blizzard_request *req,
int plane,
else
disable_tearsync();
+ if ((gx2_out - gx1_out) != (gx2 - gx1) ||
+ (gy2_out - gy1_out) != (gy2 - gy1))
+ have_zoom_for_this_update = 1;
+
+ /* 'background' type of screen update (as opposed to 'destructive')
+ can be used to disable scaling if scaling is active */
+ zoom_off = blizzard.zoom_on !have_zoom_for_this_update
+ (gx1_out == 0) (gx2_out == blizzard.screen_width)
+ (gy1_out == 0) (gy2_out == blizzard.screen_height)
+ (gx1 == 0) (gy1 == 0);
+
+ if (blizzard.zoom_on !have_zoom_for_this_update !zoom_off
+ check_1d_intersect(blizzard.zoom_area_gx1, blizzard.zoom_area_gx2,
+ gx1_out, gx2_out)
+ check_1d_intersect(blizzard.zoom_area_gy1, blizzard.zoom_area_gy2,
+ gy1_out, gy2_out)) {
+ /* Previous screen update was using scaling, current update
+* is not using it. Additionally, current screen update is
+* going to overlap with the scaled area. Scaling needs to be
+* disabled in order to avoid 'magnifying glass' effect.
+* Dummy setup of background window can be used for this.
+*/
+ set_window_regs(0, 0, blizzard.screen_width,
+ blizzard.screen_height,
+ 0, 0, blizzard.screen_width,
+ blizzard.screen_height,
+ BLIZZARD_COLOR_RGB565, 1, flags);
+ blizzard.zoom_on = 0;
+ }
+
+ /* remember scaling settings if we have scaled update */
+ if
[PATCH 10/20] omapfb: Add support for the Gumstix Overo LCD
From: Steve Sakoman st...@sakoman.com
Signed-off-by: Steve Sakoman st...@sakoman.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/Kconfig | 21 +
drivers/video/omap/Makefile|1 +
drivers/video/omap/lcd_overo.c | 179
3 files changed, 201 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap/lcd_overo.c
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 574453f..eb05e09 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -7,6 +7,27 @@ config FB_OMAP
help
Frame buffer driver for OMAP based boards.
+choice
+ depends on FB_OMAP MACH_OVERO
+ prompt Screen resolution
+ default FB_OMAP_079M3R
+ help
+ Selected desired screen resolution
+
+config FB_OMAP_031M3R
+ boolean 640 x 480 @ 60 Hz Reduced blanking
+
+config FB_OMAP_048M3R
+ boolean 800 x 600 @ 60 Hz Reduced blanking
+
+config FB_OMAP_079M3R
+ boolean 1024 x 768 @ 60 Hz Reduced blanking
+
+config FB_OMAP_092M9R
+ boolean 1280 x 720 @ 60 Hz Reduced blanking
+
+endchoice
+
config FB_OMAP_LCD_MIPID
bool MIPI DBI-C/DCS compatible LCD support
depends on FB_OMAP SPI_MASTER
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 9ff1815..0d2996a 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -33,6 +33,7 @@ objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
+objs-y$(CONFIG_MACH_OVERO) += lcd_overo.o
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/omap/lcd_overo.c b/drivers/video/omap/lcd_overo.c
new file mode 100644
index 000..2bc5c92
--- /dev/null
+++ b/drivers/video/omap/lcd_overo.c
@@ -0,0 +1,179 @@
+/*
+ * LCD panel support for the Gumstix Overo
+ *
+ * Author: Steve Sakoman st...@sakoman.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+
+#include mach/gpio.h
+#include mach/mux.h
+#include mach/omapfb.h
+#include asm/mach-types.h
+
+#define LCD_ENABLE 144
+
+static int overo_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ if ((gpio_request(LCD_ENABLE, LCD_ENABLE) == 0)
+ (gpio_direction_output(LCD_ENABLE, 1) == 0))
+ gpio_export(LCD_ENABLE, 0);
+ else
+ printk(KERN_ERR could not obtain gpio for LCD_ENABLE\n);
+
+ return 0;
+}
+
+static void overo_panel_cleanup(struct lcd_panel *panel)
+{
+ gpio_free(LCD_ENABLE);
+}
+
+static int overo_panel_enable(struct lcd_panel *panel)
+{
+ gpio_set_value(LCD_ENABLE, 1);
+ return 0;
+}
+
+static void overo_panel_disable(struct lcd_panel *panel)
+{
+ gpio_set_value(LCD_ENABLE, 0);
+}
+
+static unsigned long overo_panel_get_caps(struct lcd_panel *panel)
+{
+ return 0;
+}
+
+struct lcd_panel overo_panel = {
+ .name = overo,
+ .config = OMAP_LCDC_PANEL_TFT,
+ .bpp= 16,
+ .data_lines = 24,
+
+#if defined CONFIG_FB_OMAP_031M3R
+
+ /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = 640,
+ .y_res = 480,
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 7,
+ .pixel_clock= 23500,
+
+#elif defined CONFIG_FB_OMAP_048M3R
+
+ /* 800 x 600 @ 60 Hz Reduced blanking VESA CVT 0.48M3-R */
+ .x_res = 800,
+ .y_res = 600,
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 11,
+ .pixel_clock= 35500,
+
+#elif defined CONFIG_FB_OMAP_079M3R
+
+ /* 1024 x 768 @ 60 Hz Reduced blanking VESA CVT 0.79M3-R */
+ .x_res = 1024,
+ .y_res = 768,
+ .hfp= 48,
+ .hsw
[PATCH 13/20] omapfb: dispc: Various typo fixes
- value and register offset was swapped in a dispc write
- DISPC_CONTROL register was used instead of DISPC_SYSCONFIG
- FIFO size bit field had incorrect length for OMAP3
Signed-off-by: Tony Lindgren t...@atomide.com
Fixed-by: arun arunedar...@mistralsolutions.com
Fixed-by: Kalle Jokiniemi ext-kalle.jokini...@nokia.com
Fixed-by: Andrzej Zaborowski bal...@zabor.org
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/dispc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 148cbcc..2db8fbb 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -286,7 +286,7 @@ static void setup_plane_fifo(int plane, int ext_mode)
BUG_ON(plane 2);
l = dispc_read_reg(fsz_reg[plane]);
- l = FLD_MASK(0, 9);
+ l = FLD_MASK(0, 11);
if (ext_mode) {
low = l * 3 / 4;
high = l;
@@ -294,7 +294,7 @@ static void setup_plane_fifo(int plane, int ext_mode)
low = l / 4;
high = l * 3 / 4;
}
- MOD_REG_FLD(ftrs_reg[plane], FLD_MASK(16, 9) | FLD_MASK(0, 9),
+ MOD_REG_FLD(ftrs_reg[plane], FLD_MASK(16, 12) | FLD_MASK(0, 12),
(high 16) | low);
}
@@ -1397,7 +1397,7 @@ static int omap_dispc_init(struct omapfb_device *fbdev,
int ext_mode,
}
/* Enable smart idle and autoidle */
- l = dispc_read_reg(DISPC_CONTROL);
+ l = dispc_read_reg(DISPC_SYSCONFIG);
l = ~((3 12) | (3 3));
l |= (2 12) | (2 3) | (1 0);
dispc_write_reg(DISPC_SYSCONFIG, l);
@@ -1409,7 +1409,7 @@ static int omap_dispc_init(struct omapfb_device *fbdev,
int ext_mode,
dispc_write_reg(DISPC_CONFIG, l);
l = dispc_read_reg(DISPC_IRQSTATUS);
- dispc_write_reg(l, DISPC_IRQSTATUS);
+ dispc_write_reg(DISPC_IRQSTATUS, l);
/* Enable those that we handle always */
omap_dispc_enable_irqs(DISPC_IRQ_FRAMEMASK);
--
1.6.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/20] omapfb: Add support for the 3430SDP LCD
From: Kevin Hilman khil...@mvista.com
The 3430SDP uses the same panel as the 2430SDP. The main difference
are in the GPIO lines used for panel enable and backlight, and the
VAUX register/commands sent to the TWL4030 power subsystem.
Also, some misc. whitespace cleanups.
Signed-off-by: Kevin Hilman khil...@mvsita.com
Signed-off-by: Tony Lindgren t...@atomide.com
Fixed-by: Tony Lindgren t...@atomide.com
CC: linux-arm-ker...@lists.arm.linux.org.uk
Signed-off-by: Imre Deak imre.d...@nokia.com
---
arch/arm/configs/omap_3430sdp_defconfig | 39 +-
drivers/video/omap/Makefile |2 +
drivers/video/omap/lcd_2430sdp.c| 12 ++---
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/arch/arm/configs/omap_3430sdp_defconfig
b/arch/arm/configs/omap_3430sdp_defconfig
index 8fb918d..73e0128 100644
--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -1313,8 +1313,33 @@ CONFIG_DVB_ISL6421=m
# Graphics support
#
# CONFIG_VGASTATE is not set
-# CONFIG_VIDEO_OUTPUT_CONTROL is not set
-# CONFIG_FB is not set
+CONFIG_FB=y
+# CONFIG_FIRMWARE_EDID is not set
+# CONFIG_FB_DDC is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+# CONFIG_FB_MODE_HELPERS is not set
+# CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+CONFIG_FB_OMAP=y
+# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
@@ -1331,6 +1356,16 @@ CONFIG_DISPLAY_SUPPORT=y
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FONTS is not set
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
+CONFIG_LOGO=y
+CONFIG_LOGO_LINUX_MONO=y
+CONFIG_LOGO_LINUX_VGA16=y
+CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SND=y
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index c2475e3..96d2d43 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -8,6 +8,7 @@ objs-yy := omapfb_main.o
objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o
objs-y$(CONFIG_ARCH_OMAP2) += dispc.o
+objs-y$(CONFIG_ARCH_OMAP3) += dispc.o
objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += rfbi.o
@@ -27,6 +28,7 @@ objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
+objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
diff --git a/drivers/video/omap/lcd_2430sdp.c b/drivers/video/omap/lcd_2430sdp.c
index 5bcbb8d..13c822e 100644
--- a/drivers/video/omap/lcd_2430sdp.c
+++ b/drivers/video/omap/lcd_2430sdp.c
@@ -39,13 +39,17 @@
static unsigned backlight_gpio;
static unsigned enable_gpio;
-#define LCD_PANEL_BACKLIGHT_GPIO 91
-#define LCD_PANEL_ENABLE_GPIO 154
#define LCD_PIXCLOCK_MAX 5400 /* freq 5.4 MHz */
#define PM_RECEIVER TWL4030_MODULE_PM_RECEIVER
#define ENABLE_VAUX2_DEDICATED 0x09
#define ENABLE_VAUX2_DEV_GRP0x20
+#define ENABLE_VAUX3_DEDICATED 0x03
+#define ENABLE_VAUX3_DEV_GRP 0x20
+#define ENABLE_VPLL2_DEDICATED 0x05
+#define ENABLE_VPLL2_DEV_GRP0xE0
+#define TWL4030_VPLL2_DEV_GRP 0x33
+#define TWL4030_VPLL2_DEDICATED 0x36
#define t2_out(c, r, v) twl4030_i2c_write_u8(c, r, v)
@@ -144,7 +148,7 @@ struct lcd_panel sdp2430_panel = {
.init = sdp2430_panel_init,
.cleanup= sdp2430_panel_cleanup,
- .enable = sdp2430_panel_enable,
+ .enable = sdp2430_panel_enable,
.disable= sdp2430_panel_disable,
.get_caps = sdp2430_panel_get_caps,
};
@@ -174,7 +178,7 @@ static int sdp2430_panel_resume(struct platform_device
*pdev)
struct platform_driver sdp2430_panel_driver = {
.probe = sdp2430_panel_probe,
.remove = sdp2430_panel_remove,
- .suspend= sdp2430_panel_suspend,
+ .suspend= sdp2430_panel_suspend,
.resume = sdp2430_panel_resume,
.driver = {
.name = sdp2430_lcd,
--
1.6.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of
[PATCH 17/20] omapfb: suspend/resume only if FB device is already initialized
From: Jouni Högander jouni.hogan...@nokia.com
Check wether fbdev is NULL in suspend / resume functions. Fbdev is
NULL, if there is no lcd or it is not enabled in configuration.
Signed-off-by: Jouni Högander jouni.hogan...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/omapfb_main.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 5b04b9c..098177b 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -1842,8 +1842,8 @@ static int omapfb_suspend(struct platform_device *pdev,
pm_message_t mesg)
{
struct omapfb_device *fbdev = platform_get_drvdata(pdev);
- omapfb_blank(FB_BLANK_POWERDOWN, fbdev-fb_info[0]);
-
+ if (fbdev != NULL)
+ omapfb_blank(FB_BLANK_POWERDOWN, fbdev-fb_info[0]);
return 0;
}
@@ -1852,7 +1852,8 @@ static int omapfb_resume(struct platform_device *pdev)
{
struct omapfb_device *fbdev = platform_get_drvdata(pdev);
- omapfb_blank(FB_BLANK_UNBLANK, fbdev-fb_info[0]);
+ if (fbdev != NULL)
+ omapfb_blank(FB_BLANK_UNBLANK, fbdev-fb_info[0]);
return 0;
}
--
1.6.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/20] omapfb: Add support for the ZOOM MDK LCD
From: Stanley.Miao stanley.m...@windriver.com Add glue to control the OMAP_LDP LCD as a frame buffer device using the existing dispc.c driver under omapfb. Patch updated for mainline kernel. Note that the drivers/video/omap should be updated to pass omap_lcd_config in platform_data. The patch should also be updated to compile if twl4030 is not selected, and eventually to use the regulator framework. Signed-off-by: Stanley.Miao stanley.m...@windriver.com Signed-off-by: Tony Lindgren t...@atomide.com Fixed-by: Jarkko Nikula jarkko.nik...@gmail.com Fixed-by: Tony Lindgren t...@atomide.com CC: linux-arm-ker...@lists.arm.linux.org.uk Signed-off-by: Imre Deak imre.d...@nokia.com --- arch/arm/configs/omap_ldp_defconfig | 54 +- drivers/video/omap/Kconfig |4 + drivers/video/omap/Makefile |1 + drivers/video/omap/lcd_ldp.c| 200 +++ 4 files changed, 257 insertions(+), 2 deletions(-) create mode 100644 drivers/video/omap/lcd_ldp.c diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig index 679a4a3..b9c4891 100644 --- a/arch/arm/configs/omap_ldp_defconfig +++ b/arch/arm/configs/omap_ldp_defconfig @@ -690,6 +690,7 @@ CONFIG_GPIOLIB=y # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set +CONFIG_GPIO_TWL4030=y # # PCI GPIO expanders: @@ -742,6 +743,7 @@ CONFIG_SSB_POSSIBLE=y # CONFIG_MFD_SM501 is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set +CONFIG_TWL4030_CORE=y # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC6387XB is not set @@ -767,8 +769,46 @@ CONFIG_DAB=y # # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=m -# CONFIG_FB is not set -# CONFIG_BACKLIGHT_LCD_SUPPORT is not set +CONFIG_FB=y +CONFIG_FIRMWARE_EDID=y +# CONFIG_FB_DDC is not set +# CONFIG_FB_BOOT_VESA_SUPPORT is not set +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set +# CONFIG_FB_SYS_FILLRECT is not set +# CONFIG_FB_SYS_COPYAREA is not set +# CONFIG_FB_SYS_IMAGEBLIT is not set +# CONFIG_FB_FOREIGN_ENDIAN is not set +# CONFIG_FB_SYS_FOPS is not set +# CONFIG_FB_SVGALIB is not set +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +CONFIG_FB_MODE_HELPERS=y +CONFIG_FB_TILEBLITTING=y + +# +# Frame buffer hardware drivers +# +# CONFIG_FB_S1D13XXX is not set +# CONFIG_FB_VIRTUAL is not set +# CONFIG_FB_METRONOME is not set +CONFIG_FB_OMAP=y +CONFIG_FB_OMAP_LCD_VGA=y +# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set +# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set +CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=4 +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +# CONFIG_LCD_LTV350QV is not set +# CONFIG_LCD_ILI9320 is not set +# CONFIG_LCD_TDO24M is not set +# CONFIG_LCD_VGG2432A4 is not set +CONFIG_LCD_PLATFORM=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y +# CONFIG_BACKLIGHT_CORGI is not set +# CONFIG_BACKLIGHT_GENERIC is not set # # Display device support @@ -780,6 +820,16 @@ CONFIG_VIDEO_OUTPUT_CONTROL=m # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=y +# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set +# CONFIG_FONTS is not set +CONFIG_FONT_8x8=y +CONFIG_FONT_8x16=y +CONFIG_LOGO=y +CONFIG_LOGO_LINUX_MONO=y +CONFIG_LOGO_LINUX_VGA16=y +CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=y CONFIG_SND=y # CONFIG_SND_SEQUENCER is not set diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig index eb05e09..2bffc07 100644 --- a/drivers/video/omap/Kconfig +++ b/drivers/video/omap/Kconfig @@ -7,6 +7,10 @@ config FB_OMAP help Frame buffer driver for OMAP based boards. +config FB_OMAP_LCD_VGA +bool Use LCD in VGA mode + depends on MACH_OMAP_3430SDP || MACH_OMAP_LDP + choice depends on FB_OMAP MACH_OVERO prompt Screen resolution diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile index 0d2996a..b63b198 100644 --- a/drivers/video/omap/Makefile +++ b/drivers/video/omap/Makefile @@ -29,6 +29,7 @@ objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o +objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o diff --git a/drivers/video/omap/lcd_ldp.c b/drivers/video/omap/lcd_ldp.c new file mode 100644 index 000..8925230 --- /dev/null +++ b/drivers/video/omap/lcd_ldp.c @@ -0,0 +1,200 @@ +/* + * LCD panel support for the TI LDP board + * + * Copyright (C) 2007 WindRiver + * Author: Stanley Miao stanley.m...@windriver.com + * + * Derived from drivers/video/omap/lcd-2430sdp.c + * + * This program is free
[PATCH 09/20] omapfb: Add support for the OMAP3 Beagle DVI output
From: Koen Kooi k...@openembedded.org
The default resolution is 1024x...@24bit
This version addresses the comments from Felipe Balbi adn Arun Edarath
Signed-off-by: Koen Kooi k...@openembedded.org
Signed-off-by: Tony Lindgren t...@atomide.com
Fixed-by: Felipe Contreras felipe.contre...@gmail.com
Fixed-by: Steve Sakoman st...@sakoman.com
Fixed-by: Jarkko Nikula jarkko.nik...@gmail.com
Fixed-by: David Brownell dbrown...@users.sourceforge.net
CC: linux-arm-ker...@lists.arm.linux.org.uk
Signed-off-by: Imre Deak imre.d...@nokia.com
---
arch/arm/configs/omap3_beagle_defconfig | 47 +++-
drivers/video/omap/Makefile |1 +
drivers/video/omap/lcd_omap3beagle.c| 133 +++
3 files changed, 180 insertions(+), 1 deletions(-)
create mode 100644 drivers/video/omap/lcd_omap3beagle.c
diff --git a/arch/arm/configs/omap3_beagle_defconfig
b/arch/arm/configs/omap3_beagle_defconfig
index 4c6fb7e..c4726f0 100644
--- a/arch/arm/configs/omap3_beagle_defconfig
+++ b/arch/arm/configs/omap3_beagle_defconfig
@@ -769,7 +769,33 @@ CONFIG_DAB=y
#
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
-# CONFIG_FB is not set
+CONFIG_FB=y
+# CONFIG_FIRMWARE_EDID is not set
+# CONFIG_FB_DDC is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+# CONFIG_FB_MODE_HELPERS is not set
+# CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+CONFIG_FB_OMAP=y
+# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
@@ -782,6 +808,25 @@ CONFIG_DAB=y
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
+CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
+# CONFIG_FONT_6x11 is not set
+# CONFIG_FONT_7x14 is not set
+# CONFIG_FONT_PEARL_8x8 is not set
+# CONFIG_FONT_ACORN_8x8 is not set
+# CONFIG_FONT_MINI_4x6 is not set
+# CONFIG_FONT_SUN8x16 is not set
+# CONFIG_FONT_SUN12x22 is not set
+# CONFIG_FONT_10x18 is not set
+# CONFIG_LOGO is not set
+
+#
+# Sound
+#
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
CONFIG_USB_SUPPORT=y
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 4345157..9ff1815 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -31,6 +31,7 @@ objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
+objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/omap/lcd_omap3beagle.c
b/drivers/video/omap/lcd_omap3beagle.c
new file mode 100644
index 000..40454dc
--- /dev/null
+++ b/drivers/video/omap/lcd_omap3beagle.c
@@ -0,0 +1,133 @@
+/*
+ * LCD panel support for the TI OMAP3 Beagle board
+ *
+ * Author: Koen Kooi k...@openembedded.org
+ *
+ * Derived from drivers/video/omap/lcd-omap3evm.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/i2c/twl4030.h
+
+#include mach/mux.h
+#include mach/omapfb.h
+#include asm/mach-types.h
+
+#define LCD_PANEL_ENABLE_GPIO 170
+
+#define LCD_XRES 1024
+#define LCD_YRES 768
+#define LCD_PIXCLOCK 64000 /* in kHz */
+
+static int omap3beagle_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ gpio_request(LCD_PANEL_ENABLE_GPIO, LCD enable);
+ return 0;
+}
+
+static void omap3beagle_panel_cleanup(struct lcd_panel *panel)
+{
+}
+
+static int
[PATCH 18/20] omapfb: Fix coding style / remove dead line
From: arun c arunedar...@mistralsolutions.com
- use __iomem type attribute where appropriate
- expand (a ? : b) to (a ? a : b)
As suggested by Russell King li...@arm.linux.org.uk
- remove a dead line from omapfb_main.c
Signed-off-by: Arun C arunedar...@mistralsolutions.com
Signed-off-by: Tony Lindgren t...@atomide.com
CC: linux-arm-ker...@lists.arm.linux.org.uk
Signed-off-by: Imre Deak imre.d...@nokia.com
---
arch/arm/plat-omap/include/mach/omapfb.h |4 ++--
drivers/video/omap/omapfb_main.c |5 ++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/omapfb.h
b/arch/arm/plat-omap/include/mach/omapfb.h
index 7b74d12..b226bdf 100644
--- a/arch/arm/plat-omap/include/mach/omapfb.h
+++ b/arch/arm/plat-omap/include/mach/omapfb.h
@@ -276,8 +276,8 @@ typedef int (*omapfb_notifier_callback_t)(struct
notifier_block *,
void *fbi);
struct omapfb_mem_region {
- dma_addr_t paddr;
- void*vaddr;
+ u32 paddr;
+ void __iomem*vaddr;
unsigned long size;
u8 type; /* OMAPFB_PLANE_MEM_* */
unsignedalloc:1;/* allocated by the driver */
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 098177b..0df4523 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -562,7 +562,6 @@ static int set_fb_var(struct fb_info *fbi,
var-xoffset = var-xres_virtual - var-xres;
if (var-yres + var-yoffset var-yres_virtual)
var-yoffset = var-yres_virtual - var-yres;
- line_size = var-xres * bpp / 8;
if (plane-color_mode == OMAPFB_COLOR_RGB444) {
var-red.offset = 8; var-red.length = 4;
@@ -1719,8 +1718,8 @@ static int omapfb_do_probe(struct platform_device *pdev,
pr_info(omapfb: configured for panel %s\n, fbdev-panel-name);
- def_vxres = def_vxres ? : fbdev-panel-x_res;
- def_vyres = def_vyres ? : fbdev-panel-y_res;
+ def_vxres = def_vxres ? def_vxres : fbdev-panel-x_res;
+ def_vyres = def_vyres ? def_vyres : fbdev-panel-y_res;
init_state++;
--
1.6.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/20] omapfb: HWA742: fix pointer to be const
Fixes the following:
warning: assignment discards qualifiers from pointer target type
CC: linux-arm-ker...@lists.arm.linux.org.uk
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/hwa742.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c
index 8aa6e47..7bbd4c7 100644
--- a/drivers/video/omap/hwa742.c
+++ b/drivers/video/omap/hwa742.c
@@ -131,7 +131,7 @@ struct {
struct omapfb_device*fbdev;
struct lcd_ctrl_extif *extif;
- struct lcd_ctrl *int_ctrl;
+ const struct lcd_ctrl *int_ctrl;
void(*power_up)(struct device *dev);
void(*power_down)(struct device *dev);
--
1.6.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/20] omapfb: dispc: Enable wake up capability
From: Jouni Hogander jouni.hogan...@nokia.com Without wakeup enable omap doesn't wake up on dispc interrupts. This causes problems in a case where mpu is in sleep state and dispc interrupt fires. Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Imre Deak imre.d...@nokia.com --- drivers/video/omap/dispc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c index cc3c817..9adf54e 100644 --- a/drivers/video/omap/dispc.c +++ b/drivers/video/omap/dispc.c @@ -1395,10 +1395,10 @@ static int omap_dispc_init(struct omapfb_device *fbdev, int ext_mode, enable_digit_clocks(0); } - /* Enable smart idle and autoidle */ + /* Enable smart standby/idle, autoidle and wakeup */ l = dispc_read_reg(DISPC_SYSCONFIG); l = ~((3 12) | (3 3)); - l |= (2 12) | (2 3) | (1 0); + l |= (2 12) | (2 3) | (1 2) | (1 0); dispc_write_reg(DISPC_SYSCONFIG, l); omap_writel(1 0, DSS_BASE + DSS_SYSCONFIG); -- 1.6.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/20] omapfb: Add FB manual update option to Kconfig
Also move the controller specific options up in the menu, to a more logical spot. Signed-off-by: Imre Deak imre.d...@nokia.com --- drivers/video/omap/Kconfig | 49 ++- 1 files changed, 30 insertions(+), 19 deletions(-) diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig index 2bffc07..551e3e9 100644 --- a/drivers/video/omap/Kconfig +++ b/drivers/video/omap/Kconfig @@ -32,6 +32,36 @@ config FB_OMAP_092M9R endchoice +config FB_OMAP_LCDC_EXTERNAL + bool External LCD controller support + depends on FB_OMAP + help + Say Y here, if you want to have support for boards with an + external LCD controller connected to the SoSSI/RFBI interface. + +config FB_OMAP_LCDC_HWA742 + bool Epson HWA742 LCD controller support + depends on FB_OMAP FB_OMAP_LCDC_EXTERNAL + help + Say Y here if you want to have support for the external + Epson HWA742 LCD controller. + +config FB_OMAP_LCDC_BLIZZARD + bool Epson Blizzard LCD controller support + depends on FB_OMAP FB_OMAP_LCDC_EXTERNAL + help + Say Y here if you want to have support for the external + Epson Blizzard LCD controller. + +config FB_OMAP_MANUAL_UPDATE + bool Default to manual update mode + depends on FB_OMAP FB_OMAP_LCDC_EXTERNAL + help + Say Y here, if your user-space applications are capable of + notifying the frame buffer driver when a change has occured in + the frame buffer content and thus a reload of the image data to + the external frame buffer is required. If unsure, say N. + config FB_OMAP_LCD_MIPID bool MIPI DBI-C/DCS compatible LCD support depends on FB_OMAP SPI_MASTER @@ -69,23 +99,4 @@ config FB_OMAP_DMA_TUNE answer yes. Answer no if you have a dedicated video memory, or don't use any of the accelerated features. -config FB_OMAP_LCDC_EXTERNAL - bool External LCD controller support - depends on FB_OMAP - help - Say Y here, if you want to have support for boards with an - external LCD controller connected to the SoSSI/RFBI interface. -config FB_OMAP_LCDC_HWA742 - bool Epson HWA742 LCD controller support - depends on FB_OMAP FB_OMAP_LCDC_EXTERNAL - help - Say Y here if you want to have support for the external - Epson HWA742 LCD controller. - -config FB_OMAP_LCDC_BLIZZARD - bool Epson Blizzard LCD controller support - depends on FB_OMAP FB_OMAP_LCDC_EXTERNAL - help - Say Y here if you want to have support for the external - Epson Blizzard LCD controller. -- 1.6.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/20] omapfb: dispc: Allow multiple external IRQ handlers
From: Daniel Stone daniel.st...@nokia.com
Previously, the only external (to dispc.c) IRQ handler was RFBI's
frame done handler. dispc's IRQ framework was very dumb: you could only
have one handler, and the semantics of {request,free}_irq were odd, to
say the least.
The new framework allows multiple consumers to register arbitrary IRQ
masks.
Signed-off-by: Daniel Stone daniel.st...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Imre Deak imre.d...@nokia.com
---
drivers/video/omap/dispc.c | 95 +++-
drivers/video/omap/dispc.h |7 ++-
drivers/video/omap/rfbi.c |7 ++-
3 files changed, 67 insertions(+), 42 deletions(-)
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 9adf54e..350b444 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -155,6 +155,8 @@ struct resmap {
unsigned long *map;
};
+#define MAX_IRQ_HANDLERS4
+
static struct {
void __iomem*base;
@@ -167,9 +169,11 @@ static struct {
int ext_mode;
- unsigned long enabled_irqs;
- void(*irq_callback)(void *);
- void*irq_callback_data;
+ struct {
+ u32 irq_mask;
+ void(*callback)(void *);
+ void*data;
+ } irq_handlers[MAX_IRQ_HANDLERS];
struct completion frame_done;
int fir_hinc[OMAPFB_PLANE_NUM];
@@ -809,56 +813,70 @@ static void set_lcd_timings(void)
panel-pixel_clock = fck / lck_div / pck_div / 1000;
}
-int omap_dispc_request_irq(void (*callback)(void *data), void *data)
+static void recalc_irq_mask(void)
{
- int r = 0;
+ int i;
+ unsigned long irq_mask = DISPC_IRQ_MASK_ERROR;
- BUG_ON(callback == NULL);
+ for (i = 0; i MAX_IRQ_HANDLERS; i++) {
+ if (!dispc.irq_handlers[i].callback)
+ continue;
- if (dispc.irq_callback)
- r = -EBUSY;
- else {
- dispc.irq_callback = callback;
- dispc.irq_callback_data = data;
+ irq_mask |= dispc.irq_handlers[i].irq_mask;
}
- return r;
-}
-EXPORT_SYMBOL(omap_dispc_request_irq);
-
-void omap_dispc_enable_irqs(int irq_mask)
-{
enable_lcd_clocks(1);
- dispc.enabled_irqs = irq_mask;
- irq_mask |= DISPC_IRQ_MASK_ERROR;
MOD_REG_FLD(DISPC_IRQENABLE, 0x7fff, irq_mask);
enable_lcd_clocks(0);
}
-EXPORT_SYMBOL(omap_dispc_enable_irqs);
-void omap_dispc_disable_irqs(int irq_mask)
+int omap_dispc_request_irq(unsigned long irq_mask, void (*callback)(void
*data),
+ void *data)
{
- enable_lcd_clocks(1);
- dispc.enabled_irqs = ~irq_mask;
- irq_mask = ~DISPC_IRQ_MASK_ERROR;
- MOD_REG_FLD(DISPC_IRQENABLE, 0x7fff, irq_mask);
- enable_lcd_clocks(0);
+ int i;
+
+ BUG_ON(callback == NULL);
+
+ for (i = 0; i MAX_IRQ_HANDLERS; i++) {
+ if (dispc.irq_handlers[i].callback)
+ continue;
+
+ dispc.irq_handlers[i].irq_mask = irq_mask;
+ dispc.irq_handlers[i].callback = callback;
+ dispc.irq_handlers[i].data = data;
+ recalc_irq_mask();
+
+ return 0;
+ }
+
+ return -EBUSY;
}
-EXPORT_SYMBOL(omap_dispc_disable_irqs);
+EXPORT_SYMBOL(omap_dispc_request_irq);
-void omap_dispc_free_irq(void)
+void omap_dispc_free_irq(unsigned long irq_mask, void (*callback)(void *data),
+void *data)
{
- enable_lcd_clocks(1);
- omap_dispc_disable_irqs(DISPC_IRQ_MASK_ALL);
- dispc.irq_callback = NULL;
- dispc.irq_callback_data = NULL;
- enable_lcd_clocks(0);
+ int i;
+
+ for (i = 0; i MAX_IRQ_HANDLERS; i++) {
+ if (dispc.irq_handlers[i].callback == callback
+ dispc.irq_handlers[i].data == data) {
+ dispc.irq_handlers[i].irq_mask = 0;
+ dispc.irq_handlers[i].callback = NULL;
+ dispc.irq_handlers[i].data = NULL;
+ recalc_irq_mask();
+ return;
+ }
+ }
+
+ BUG();
}
EXPORT_SYMBOL(omap_dispc_free_irq);
static irqreturn_t omap_dispc_irq_handler(int irq, void *dev)
{
u32 stat;
+ int i = 0;
enable_lcd_clocks(1);
@@ -873,8 +891,12 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
}
}
- if ((stat dispc.enabled_irqs) dispc.irq_callback)
- dispc.irq_callback(dispc.irq_callback_data);
+ for (i = 0; i MAX_IRQ_HANDLERS; i++) {
+ if (unlikely(dispc.irq_handlers[i].callback
+(stat dispc.irq_handlers[i].irq_mask)))
+ dispc.irq_handlers[i].callback(
+
Please help on testing new sound driver for OMAP1510 based machine
Hi, As some of you may have already noticed, I am trying to create a sound driver for ams-delta board, based on ASoC OMAP framework. AFAIK, this would be the first ASoC implementation for OMAP1510/5910 based board. Unfortunatelly, I am not able to get DMA interrupts working. It would be much easier to find the reason of the problem if there were already working ASoC OMAP implementations for other OMAP1510/5910 based boards. As there is none yet, I would be willing to spend my time on creating one for a board with a former, omap-alsa based working sound driver, if I could only find someone who has such device on hand, knows how to boot a custom kernel and would like spend some time on testing my patches. AFAICS, there were following OMAP1510/5910 based machines supoorted by omap-alsa: - OMAP-1510 Innovator (AIC23 codec), - Palm Tungsten E, - Palm Tungsten T (AIC23 codec), - Palm Zire71 (AIC23 codec), - Siemens SX1. It would be better to start with a machine that has AIC23 codec on board, as this codec is already supported by current ASoC framework. If you know of someone who has access to one of those devices and would like to help, please ask him to drop me a message. Cheers, Janusz -- 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: [RFC][PATCH] Add support for hook switch on ams-delta
On Wed, Jun 03, 2009 at 11:03:20AM +0200, Janusz Krzysztofik wrote: Wednesday 03 June 2009 00:04:33 Jonathan McDowell napisał(a): I'm obviously too late as I've seen the Applied mail, No problem, I'm glad to hear from you. but some comments: * I don't think SW_HEADPHONE_INSERT is appropriate. input guys, is it not reasonable to have SW_PHONE_HOOK or similar? I do share you point of view. However, I didn't want to start a discussion if there is a need for another symbol or not before the patch got any acceptance. * We assume the bootloader does the appropriate GPIO pin setup for us, so I don't think your omap_cfg_reg is required but it doesn't hurt in the unlikely event we ever replace the Amstrad PBL. OK, let it stay there. Do you see a need for replaceing it with a new ams_delta_hook_switch_init() function call that just calls omap_cfg_reg()? I don't see a need for this; it's always present and not a lot of code to have in the init function as it stands. * The commented out code to include the GPIO status in sysfs shouldn't be included. Yes, I put it there to get a feedback. Does the input layer not provide a way to obtain the state of the switch? Yes, it does, with EVIOCGSW ioctl()[1]. I personally don't like this way of getting the switch status and would rather see it available over sysfs. However, input guys may have their own preferences and gpio-keys driver belongs to them. I think that's a discussion to have with the input guys rather than putting a hack in the platform file then. So really the only issue with the patch that remains is if it justifies adding a new SW_PHONE_HOOK switch type? J. -- ] http://www.earth.li/~noodles/ [] Purranoia: The fear that your cat [ ] PGP/GPG Key @ the.earth.li [] is up to something. [ ] via keyserver, web or email. [] [ ] RSA: 4096/2DA8B985[] [ -- 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/2] omap: twl4030_wdt: twl4030 watchdog driver
Hi Russell, Samuel, David,
I reviewed the twl watchdog driver written by Timo and Atal (reviewed version -
see below).
could you review them also (arm driver and touches drivers/mfd/twl4030-core).
Thanks in advance,
Wim.
---
commit ca1a9726d1e0655c39d07f8b77659c5d017748cb
Author: Timo Kokkonen timo.t.kokko...@nokia.com
Date: Fri Mar 27 16:42:17 2009 +0200
[WATCHDOG] twl4030 watchdog driver
Implementation of twl4030 watchdog driver.
Signed-off-by: Timo Kokkonen timo.t.kokko...@nokia.com
Signed-off-by: Atal Shargorodsky ext-atal.shargorod...@nokia.com
Signed-off-by: Wim Van Sebroeck w...@iguana.be
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index ec90e95..b8df518 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -101,6 +101,12 @@
#define twl_has_usb() false
#endif
+#if defined(CONFIG_TWL4030_WATCHDOG) || \
+ defined(CONFIG_TWL4030_WATCHDOG_MODULE)
+#define twl_has_watchdog()true
+#else
+#define twl_has_watchdog()false
+#endif
/* Triton Core internal information (BEGIN) */
@@ -526,6 +532,12 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
usb_transceiver = child;
}
+ if (twl_has_watchdog()) {
+ child = add_child(0, twl4030_wdt, NULL, 0, false, 0, 0);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
if (twl_has_regulator()) {
/*
child = add_regulator(TWL4030_REG_VPLL1, pdata-vpll1);
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9f6766b..d92bf63 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -250,6 +250,13 @@ config COH901327_WATCHDOG
This watchdog is used to reset the system and thus cannot be
compiled as a module.
+config TWL4030_WATCHDOG
+ tristate TWL4030 Watchdog
+ depends on TWL4030_CORE
+ help
+ Support for TI TWL4030 watchdog. Say 'Y' here to enable the
+ watchdog timer support for TWL4030 chips.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 8d75e62..9eb74b7 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
+obj-$(CONFIG_TWL4030_WATCHDOG) += twl4030_wdt.o
obj-$(CONFIG_21285_WATCHDOG) += wdt285.o
obj-$(CONFIG_977_WATCHDOG) += wdt977.o
obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o
diff --git a/drivers/watchdog/twl4030_wdt.c b/drivers/watchdog/twl4030_wdt.c
new file mode 100644
index 000..cb46556
--- /dev/null
+++ b/drivers/watchdog/twl4030_wdt.c
@@ -0,0 +1,272 @@
+/*
+ * Copyright (C) Nokia Corporation
+ *
+ * Written by Timo Kokkonen timo.t.kokkonen at nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+#include linux/miscdevice.h
+#include linux/uaccess.h
+#include linux/i2c/twl4030.h
+
+#define TWL4030_WATCHDOG_CFG_REG_OFFS 0x3
+
+#define TWL4030_WDT_STATE_OPEN 0x1
+#define TWL4030_WDT_STATE_ACTIVE 0x8
+
+static struct platform_device *twl4030_wdt_dev;
+
+struct twl4030_wdt {
+ struct miscdevice miscdev;
+ int timer_margin;
+ unsigned long state;
+};
+
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, Watchdog cannot be stopped once started
+ (default= __MODULE_STRING(WATCHDOG_NOWAYOUT) ));
+
+static int twl4030_wdt_write(unsigned char val)
+{
+ return twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, val,
+ TWL4030_WATCHDOG_CFG_REG_OFFS);
+}
+
+static int twl4030_wdt_enable(struct twl4030_wdt *wdt)
+{
+ return twl4030_wdt_write(wdt-timer_margin + 1);
+}
+
+static int twl4030_wdt_disable(struct twl4030_wdt *wdt)
+{
+ return twl4030_wdt_write(0);
+}
+
+static int twl4030_wdt_set_timeout(struct
[RFC] [PATCH] input: add definition for handset pick up switch event
This patch adds new symbol definition for events generated by handset pick up
switch on machines equipped with such facility. It will be used by gpio-keys
driver supported platform device definition for ams-delta omap board I'm going
to submit.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
diff -up linux-2.6.30-rc5/include/linux/input.h.orig
linux-2.6.30-rc5/include/linux/input.h
--- linux-2.6.30-rc5/include/linux/input.h.orig 2009-06-04 18:25:08.0
+0200
+++ linux-2.6.30-rc5/include/linux/input.h 2009-06-04 20:17:56.0
+0200
@@ -675,6 +675,7 @@ struct input_absinfo {
#define SW_LINEOUT_INSERT 0x06 /* set = inserted */
#define SW_JACK_PHYSICAL_INSERT 0x07 /* set = mechanical switch set */
#define SW_VIDEOOUT_INSERT 0x08 /* set = inserted */
+#define SW_HANDSET_PICK_UP 0x09 /* set = picked up */
#define SW_MAX 0x0f
#define SW_CNT (SW_MAX+1)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Wang Sawsd-A24013 Sent: 2009年6月5日 1:43 To: Kevin Hilman Cc: linux-omap@vger.kernel.org; n...@ti.com; Mike Chan Subject: RE: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 2009年6月5日 1:04 Dumb question: Why use level? Why not use falling edge for this? A good question, :-) We did use edge interrupt before, see the reason below. The issue is, after the touch driver calls irq_disable, since it is empty unless Set the IRQ_DISABLED flag, so next time only the generic handler function handle_level_irq is called, this handler just ack to OMAP GPIO IRQ that is To clear the IRQ status and mask the GPIO on OMAP side, but since NO Touch driver IRQ action is called, so the touch Controller can not gets acknowledged, then the interrupt line will be always driven low by the external controller, If the GPIO is set to be edge triggered, the fact that it is still low won't matter, the genirq layer will have noticed a pending interrupt. If we use edge interrupt here, the potential issue is still existing, and also We are liky to lose the interrupt. After irq_disable and before HW suspend, if the interrupt line is driven low, Then OMAP GPIO can catch this edge transition, so the IRQ is set, Then the handle_edge_irq will clear the IRQ staus and mask the IRQ. Since the controller is not ACKed, then the interrupt line is always driven low, Then from then on, no edge can happen, and no more Touch interrupt can happen Even when irq_enable is called, though we have the prepare for idle hooks, But that only work when the edge transition happens after that prepare call, Since it saves the GPIO data IN at that time, if the input level already changes Before that time, then the workaround does not work. We ever made another patch to not only compare the data in, but also check It is rising or falling edge, and check the CURRENT input level to decide whether to Use LEVEL detect to manually trigger the interrupt, it works fine with our HW. But later on, touch cotroller driver is updated to use level detect, then we Met this issue. I think the patch we made to workaround the edge int lost is also needed In current pm branch, currently we may still face the issue I mentioned above. I rechecked the code, seems the issue will not be there since The handle_edge_irq can resend irq during resume time, then I checked our issue log and found, the reason that we lose The edge interrupt is because we were using omapzoom kernel And put PER to fully HW supervised mode and we didn't use The prepare idle hooks in our idle function call, then the issues Happens when PER is in RET/OFF state but the touch interrupt happens. With linux-omap kernel, seems using edge interrupt can just workaround The touch issue, but I think the issue is still there, we can not expect All the GPIO interrupts to be edge type, and we can not expect all the edge Interrupts to fire only once, with open platforms, every kind of peripherals We may use, the change to root fix this problem should be still clearing The level/edge detection when irq_disable is called. This will not cause Extra interrupt loss since we still have the prepare/resume hooks to check Gpio input and retrigger the interrupts. -- 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
Early gpio_request on LDP for LCD fails
Hi, I am getting failed messages when I try gpio_request for LCD in the early board_init (GPIO number is (9+OMAP_GPIO_LINES_MAX)). Could any one suggest me how to resolve it, or any inputs are appreicated. Regards, Subbu-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] input: add definition for handset pick up switch event
Everyone willing to answer my original message, please correct my spelling
error in linux-input address before sending or reply to this one instead.
Sorry for this.
Janusz
Thursday 04 June 2009 20:46:37 Janusz Krzysztofik napisał(a):
This patch adds new symbol definition for events generated by handset pick
up switch on machines equipped with such facility. It will be used by
gpio-keys driver supported platform device definition for ams-delta omap
board I'm going to submit.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
diff -up linux-2.6.30-rc5/include/linux/input.h.orig
linux-2.6.30-rc5/include/linux/input.h ---
linux-2.6.30-rc5/include/linux/input.h.orig 2009-06-04 18:25:08.0
+0200 +++ linux-2.6.30-rc5/include/linux/input.h 2009-06-04
20:17:56.0 +0200 @@ -675,6 +675,7 @@ struct input_absinfo {
#define SW_LINEOUT_INSERT0x06 /* set = inserted */
#define SW_JACK_PHYSICAL_INSERT 0x07 /* set = mechanical switch set */
#define SW_VIDEOOUT_INSERT 0x08 /* set = inserted */
+#define SW_HANDSET_PICK_UP 0x09 /* set = picked up */
#define SW_MAX 0x0f
#define SW_CNT (SW_MAX+1)
--
To unsubscribe from this list: send the line unsubscribe linux-input 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: [Linux-fbdev-devel] [PATCH 00/20] omapfb: Add support for new LCDs / misc fixes
On Thu, 4 Jun 2009 20:52:25 +0300 Imre Deak imre.d...@nokia.com wrote: Hi, I'd like to ask for the merging of this patchset into Linus' tree. It adds support for new LCDs on OMAP based boards (01-12) and fixes generic parts of the omapfb driver (13-20). The changes have been staged in the Linux OMAP tree for quite a long time, so they should be safe to be merged. I will review your patches over next weekend. Best regards, Krzysztof -- Dodaj ogloszenie motoryzacyjne za 0 zl! Tylko na mobile.interia.pl Sprawdz http://link.interia.pl/f21b7 -- 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
DSS porting problems
I'm porting my platform (3530, very similar to LDP) to your tree. http://www.bat.org/~tomba/git/linux-omap-dss.git Since you have complete support for the 3430SDP, I started with that board file. I've added my own display (larger Hitachi screen that is 800x600). I've run into a few problems: * All output to the main frame buffer (/dev/fb0) seems to go to the very last line of the display. * The documentation (Documentation/arm/OMAP/DSS) does not seem to match what's in sysfs. In particular, there are no horizontal or vertical fields in the displayN tree. This makes the examples of how to clone, etc, not work. Any ideas what I should look at? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
Wang Sawsd-A24013 cqw...@motorola.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Wang Sawsd-A24013 Sent: 2009年6月5日 1:43 To: Kevin Hilman Cc: linux-omap@vger.kernel.org; n...@ti.com; Mike Chan Subject: RE: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 2009年6月5日 1:04 Dumb question: Why use level? Why not use falling edge for this? A good question, :-) We did use edge interrupt before, see the reason below. The issue is, after the touch driver calls irq_disable, since it is empty unless Set the IRQ_DISABLED flag, so next time only the generic handler function handle_level_irq is called, this handler just ack to OMAP GPIO IRQ that is To clear the IRQ status and mask the GPIO on OMAP side, but since NO Touch driver IRQ action is called, so the touch Controller can not gets acknowledged, then the interrupt line will be always driven low by the external controller, If the GPIO is set to be edge triggered, the fact that it is still low won't matter, the genirq layer will have noticed a pending interrupt. If we use edge interrupt here, the potential issue is still existing, and also We are liky to lose the interrupt. After irq_disable and before HW suspend, if the interrupt line is driven low, Then OMAP GPIO can catch this edge transition, so the IRQ is set, Then the handle_edge_irq will clear the IRQ staus and mask the IRQ. Since the controller is not ACKed, then the interrupt line is always driven low, Then from then on, no edge can happen, and no more Touch interrupt can happen Even when irq_enable is called, though we have the prepare for idle hooks, But that only work when the edge transition happens after that prepare call, Since it saves the GPIO data IN at that time, if the input level already changes Before that time, then the workaround does not work. We ever made another patch to not only compare the data in, but also check It is rising or falling edge, and check the CURRENT input level to decide whether to Use LEVEL detect to manually trigger the interrupt, it works fine with our HW. But later on, touch cotroller driver is updated to use level detect, then we Met this issue. I think the patch we made to workaround the edge int lost is also needed In current pm branch, currently we may still face the issue I mentioned above. I rechecked the code, seems the issue will not be there since The handle_edge_irq can resend irq during resume time, then Yes, I was actually replying to ask you to check why the retrigger wasn't happening in your kernel. I checked our issue log and found, the reason that we lose The edge interrupt is because we were using omapzoom kernel I was starting to think you were not actually using the linux-omap kernel (looks like I was right.) And put PER to fully HW supervised mode and we didn't use The prepare idle hooks in our idle function call, then the issues Happens when PER is in RET/OFF state but the touch interrupt happens. With linux-omap kernel, seems using edge interrupt can just workaround The touch issue, Good. but I think the issue is still there, we can not expect All the GPIO interrupts to be edge type, and we can not expect all the edge Interrupts to fire only once, with open platforms, every kind of peripherals We may use, I completely agree. You have definitely found a robustness problem in the GPIO core that will be relatively easy to run into in the future. the change to root fix this problem should be still clearing The level/edge detection when irq_disable is called. This will not cause Extra interrupt loss since we still have the prepare/resume hooks to check Gpio input and retrigger the interrupts. What do you think about disabling the level/edge detection when disable_irq_wake() is called instead? This seems more logical and expected. Kevin P.S., are you wanting to use your touchscreen as a wakeup source? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] OMAP4: I2C Support for OMAP_4430SDP
why is this 2600? omap3 could do 3.3Mhz. There is a silicon issue reported on TWL5030 which says that it can not operate at the stipulated highest frequency of 3.3MHz. The information I got is this: I2C data hold time in HS mode is higher than specification when reading I2C registers. This leads to a data setup issue which introduces a frequency limitation in HS mode (can not reach 3.4MHz as specified in I2C standard). The limitation is for the Control I2C, and for SmartReflex I2C when using other products than OMAP34xx with SR. HS mode is working OK for SR I2C when using OMAP34xx. -- With regards, Jagadeesh Bhaskar P Bugs are by far the largest and most successful class of entity, with nearly a million known species. In this respect they outnumber all the other known creatures about four to one. —Professor Snopes' Encyclopedia of Animal Life --- -- 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] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
What do you think about disabling the level/edge detection when disable_irq_wake() is called instead? This seems more logical and expected. Kevin, if we look at the current code, enable_irq_wake and disable_irq_wake Does not even touch any GPIO WAKEEN register, it seems it is intended To just log the gpio bit and enable its WAKEUP and IOPAD wakeup when suspend happens. And also, enable_irq_wake/disable_irq_wake Are designed to be able used when both IRQ is enabled AND disabled, In another words, enable_irq_wake may be called after irq_disable, Disable_irq_wake may be called after irq_enable, if we change Level/edge detect then it may cause either IRQ never happen After irq_enable, or IRQ staus bit also set after irq_disable. Since The root reason is the level/edge detect can cause IRQ status, it Is related with IRQ, not wakeup. What do you think? Kevin P.S., are you wanting to use your touchscreen as a wakeup source? -- 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: [RFC][PATCH] Add support for hook switch on ams-delta
Hi, Thursday 04 June 2009 20:18:33 Jonathan McDowell napisał(a): On Wed, Jun 03, 2009 at 11:03:20AM +0200, Janusz Krzysztofik wrote: Wednesday 03 June 2009 00:04:33 Jonathan McDowell napisał(a): * We assume the bootloader does the appropriate GPIO pin setup for us, so I don't think your omap_cfg_reg is required but it doesn't hurt in the unlikely event we ever replace the Amstrad PBL. OK, let it stay there. Do you see a need for replaceing it with a new ams_delta_hook_switch_init() function call that just calls omap_cfg_reg()? I don't see a need for this; it's always present and not a lot of code to have in the init function as it stands. Fine, I'll only add a comment explainig the purpose of the call then. Does the input layer not provide a way to obtain the state of the switch? Yes, it does, with EVIOCGSW ioctl()[1]. I personally don't like this way of getting the switch status and would rather see it available over sysfs. However, input guys may have their own preferences and gpio-keys driver belongs to them. I think that's a discussion to have with the input guys rather than putting a hack in the platform file then. Sure. I have a patch for gpio-keys.c ready to submit, let's see how far we can get with the idea of exporting a gpio-keys driven switch state over gpiolib sysfs. So really the only issue with the patch that remains is if it justifies adding a new SW_PHONE_HOOK switch type? I've just submitted a patch that adds new symbol definition to include/linux/input.h. Do I have to wait for acknowledgement before I resubmit my modified patch that depends on that, or can I submit it now? Thanks, Janusz -- 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: DSP MMU Fault
Hi Hari, How can I map the address? At what part do I specify these mappings; bridge installation, at DSP side program (with the tci file etc.)? By the way just before that in the program I do a malloc(32) to another short pointer but |it doesn't return any errors? Please forgive me if this is a trivial question but I'm just learning the DSP programming. Thanks a lot. Best regards, Can Hi Can, Do you have any ideas why this might be happening and how to fix it? Thanks a lot. Most probably you might not have mapped the address 0x230674a0. Thank you, Best regards, Hari -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Can Bal Sent: Thursday, June 04, 2009 6:54 AM To: linux-omap@vger.kernel.org Subject: DSP MMU Fault Hi everyone, I'm implementing a code on DSP but at the time I do a memory allocation at the DSP side as: short *a; a = malloc(192); // (short*)malloc(192) does not work either But at this line I get the following error and DSP fails afterwards. Then I need to reboot until I can run the application again. 6* DSPMMU FAULT * IRQStatus 0x2 * DSPMMU FAULT * IRQStatus 0x2 6* DSPMMU FAULT * faultAddr 0x230674a0 * DSPMMU FAULT * faultAddr 0x230674a0 6WMD_DEH_Notify: ** DEVICE EXCEPTION ** WMD_DEH_Notify: ** DEVICE EXCEPTION ** 6WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 6WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 6WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 6WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 Do you have any ideas why this might be happening and how to fix it? Thanks a lot. Can -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DSP MMU Fault
Hi Can, The address that DSP accesses should be mapped to physical address by ARM. I am not sure what you are trying to do, but you can look at the below examples on how the Mapping works. Reference: 1 = MPU side sample: http://gitorious.org/ti-dspbridge/userspace/blobs/master/source/samples/mpu/src/dmmcopy/dmmcopy.c DSP sample: http://gitorious.org/ti-dspbridge/userspace/trees/master/source/samples/dsp Reference: 2 = Felipe has good example on his tree. May be this is bit simpler. http://github.com/felipec/dsp-dummy/tree/master Thank you, Best regards, Hari -Original Message- From: Can Bal [mailto:can...@ee.bilkent.edu.tr] Sent: Thursday, June 04, 2009 5:15 PM To: Kanigeri, Hari Cc: Can Bal; linux-omap@vger.kernel.org Subject: RE: DSP MMU Fault Hi Hari, How can I map the address? At what part do I specify these mappings; bridge installation, at DSP side program (with the tci file etc.)? By the way just before that in the program I do a malloc(32) to another short pointer but |it doesn't return any errors? Please forgive me if this is a trivial question but I'm just learning the DSP programming. Thanks a lot. Best regards, Can Hi Can, Do you have any ideas why this might be happening and how to fix it? Thanks a lot. Most probably you might not have mapped the address 0x230674a0. Thank you, Best regards, Hari -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Can Bal Sent: Thursday, June 04, 2009 6:54 AM To: linux-omap@vger.kernel.org Subject: DSP MMU Fault Hi everyone, I'm implementing a code on DSP but at the time I do a memory allocation at the DSP side as: short *a; a = malloc(192); // (short*)malloc(192) does not work either But at this line I get the following error and DSP fails afterwards. Then I need to reboot until I can run the application again. 6* DSPMMU FAULT * IRQStatus 0x2 * DSPMMU FAULT * IRQStatus 0x2 6* DSPMMU FAULT * faultAddr 0x230674a0 * DSPMMU FAULT * faultAddr 0x230674a0 6WMD_DEH_Notify: ** DEVICE EXCEPTION ** WMD_DEH_Notify: ** DEVICE EXCEPTION ** 6WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 6WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 6WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 6WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 Do you have any ideas why this might be happening and how to fix it? Thanks a lot. Can -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH] input: export gpio-keys driven switch status over gpiolib sysfs
This patch adds support for exporting status of GPIO switches, configured as
gpio-keys buttons that generate events of type EV_SW, over standard gpiolib
sysfs interface. That way, switch state can be easily accessed from userspace
via a modern sysfs API in addition to traditional ioclt API, without the need
for adding a new, usualy controversial entry to sysfs interface.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
diff -up linux-2.6.30-rc5/drivers/input/keyboard/gpio_keys.c.orig
linux-2.6.30-rc5/drivers/input/keyboard/gpio_keys.c
--- linux-2.6.30-rc5/drivers/input/keyboard/gpio_keys.c.orig2009-03-24
00:12:14.0 +0100
+++ linux-2.6.30-rc5/drivers/input/keyboard/gpio_keys.c 2009-06-04
21:31:19.0 +0200
@@ -157,6 +157,19 @@ static int __devinit gpio_keys_probe(str
wakeup = 1;
input_set_capability(input, type, button-code);
+
+ /* For GPIO buttons generating events of type EV_SW
+* (ie switches), export their status
+* over gpiolib sysfs interface if configured */
+#ifdef CONFIG_GPIO_SYSFS
+ if (type == EV_SW) {
+ error = gpio_export(button-gpio, false);
+ if (error)
+ pr_warning(gpio-keys:
+ failed to export GPIO %d, error %d\n,
+ button-gpio, error);
+ }
+#endif
}
error = input_register_device(input);
--
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] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
Wang Sawsd-A24013 cqw...@motorola.com writes: What do you think about disabling the level/edge detection when disable_irq_wake() is called instead? This seems more logical and expected. Kevin, if we look at the current code, enable_irq_wake and disable_irq_wake Does not even touch any GPIO WAKEEN register, it seems it is intended To just log the gpio bit and enable its WAKEUP and IOPAD wakeup when suspend happens. Correct. And also, enable_irq_wake/disable_irq_wake Are designed to be able used when both IRQ is enabled AND disabled, In another words, enable_irq_wake may be called after irq_disable, Disable_irq_wake may be called after irq_enable, if we change Level/edge detect then it may cause either IRQ never happen Good point. After irq_enable, or IRQ staus bit also set after irq_disable. Since The root reason is the level/edge detect can cause IRQ status, it Is related with IRQ, not wakeup. Correct again. What do you think? I'm thinking I'm not thinking very clearly on the subject today. It's too hot in Seattle today. ;) I'm also thinking that this isn't just going to be a problem with suspend/resume but also for hitting retention in idle. Any level-triggered GPIO IRQ that is masked, yet still has level/edge detect configured can prevent retention during idle since it will cause IRQ status as you've pointed out. Can you think of any reason not to disable the level/edge detect in the -mask() hook and to re-enable it in the -unmask hook? Something like the patch below? Could you try this patch with your TS GPIO configured as level-triggered? Kevin commit f8eb69a2edd684c9e0b72bc3c84c6af9718bd4a4 Author: Kevin Hilman khil...@deeprootsystems.com Date: Thu Jun 4 15:57:10 2009 -0700 OMAP: GPIO: clear/restore level/edge detect settings on mask/unmask needs detailed description Signed-off-by: Kevin Hilman khil...@ti.deeprootsystems.com diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index 3b2054b..83ac494 100644 --- a/arch/arm/plat-omap/gpio.c +++ b/arch/arm/plat-omap/gpio.c @@ -1135,6 +1135,7 @@ static void gpio_mask_irq(unsigned int irq) struct gpio_bank *bank = get_irq_chip_data(irq); _set_gpio_irqenable(bank, gpio, 0); + _set_gpio_triggering(bank, get_gpio_index(gpio), IRQ_TYPE_NONE); } static void gpio_unmask_irq(unsigned int irq) @@ -1142,6 +1143,11 @@ static void gpio_unmask_irq(unsigned int irq) unsigned int gpio = irq - IH_GPIO_BASE; struct gpio_bank *bank = get_irq_chip_data(irq); unsigned int irq_mask = 1 get_gpio_index(gpio); + struct irq_desc *desc = irq_to_desc(irq); + u32 trigger = desc-status IRQ_TYPE_SENSE_MASK; + + if (trigger) + _set_gpio_triggering(bank, get_gpio_index(gpio), trigger); /* For level-triggered GPIOs, the clearing must be done after * the HW source is cleared, thus after the handler has run */ -- 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: DSS2: Compilation Error on Git tree http://www.bat.org/~tomba/git/linux-omap-dss.git
Hi Tomi, I ported LDP changes to new Device model, basic features are tested, let me know if I need to resend it. While testing mirroring, I added new IOCTL for mirroring, so that user application can perform operations, do you want me send that patch too? Regards, Subbu From: Tomi Valkeinen [tomi.valkei...@nokia.com] Sent: Thursday, June 04, 2009 1:59 AM To: Venkatesh, Subbu Cc: Shah, Hardik; linux-omap@vger.kernel.org; Mande, Nikhil; Castaneda Gonzalez, Axel; Miesen, Sharon Subject: Re: DSS2: Compilation Error on Git tree http://www.bat.org/~tomba/git/linux-omap-dss.git On Wed, 2009-06-03 at 16:07 +0200, ext Venkatesh, Subbu wrote: Hi Tomi, I did git pull to update my tree, later compiling code for LDP, I am getting compilation error as show below. I see that I am missing declaration of struct omap_dss_display_config in display.h file, could you please comment on it... You need to port your LDP changes to newer DSS2 device model. Check how it's done with OMAP SDP or Beagleboard. 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
Early gpio_request on LDP for LCD fails
Hi, I am getting failed messages when I try gpio_request for LCD in the early board_init (GPIO number is (9+OMAP_GPIO_LINES_MAX)). Could any one suggest me how to resolve it, or any inputs are appreicated. Regards, Subbu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] OMAP4: I2C Support for OMAP_4430SDP
On Thu, Jun 4, 2009 at 4:41 PM, Jagadeesh Bhaskar Pakaravoor jagadees...@gmail.com wrote: why is this 2600? omap3 could do 3.3Mhz. There is a silicon issue reported on TWL5030 which says that it can not operate at the stipulated highest frequency of 3.3MHz. The information I got is this: I2C data hold time in HS mode is higher than specification when reading I2C registers. This leads to a data setup issue which introduces a frequency limitation in HS mode (can not reach 3.4MHz as specified in I2C standard). The limitation is for the Control I2C, and for SmartReflex I2C when using other products than OMAP34xx with SR. HS mode is working OK for SR I2C when using OMAP34xx. Is this bug valid for OMAP4 already :) ? Is'nt it a bit early to post erratas :D... btw, the topic was on OMAP4 I2C.. the point i was driving at is this: we need options to do: A) provide speed parameter per bus at a board level (which is implemented now). or B) also provide flexibility, when so desired to provide scll and sch values per bus for the board. Rationale: a) using i2c speed is not a scalable technique to handle varied i2c bus conditions - what if you have 1 foot wiring to the i2c device? b) bus capacitance and other factors have to be considered. c) we need some mechanism to allow a board specific configuration of i2c scll sclh (fast and hs mode) to be configurable for platform bus - note, in a bus with multiple devices, you need to measure the least common factor - the default equations may not scale well. d) At the same time, ability which is in the driver today - essentially to be able to provide speed as a i2c module parameter should be scaled accross when we provide flexibility for i2c scll and sclh value configuration.. e) for boards which are fine with default equations, the current mechanism of providing speeds as parameter should be retained. Unless we ensure we do it as part of initial driver, we will fall into OMAP3 trap of inflexibility.. just my 2 cents Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSP MMU Fault
Hi Can, On 6/4/09, Can Bal can...@ee.bilkent.edu.tr wrote: Hi everyone, I'm implementing a code on DSP but at the time I do a memory allocation at the DSP side as: short *a; a = malloc(192); // (short*)malloc(192) does not work either But at this line I get the following error and DSP fails afterwards. Then I need to reboot until I can run the application again. 6* DSPMMU FAULT * IRQStatus 0x2 * DSPMMU FAULT * IRQStatus 0x2 6* DSPMMU FAULT * faultAddr 0x230674a0 * DSPMMU FAULT * faultAddr 0x230674a0 6WMD_DEH_Notify: ** DEVICE EXCEPTION ** WMD_DEH_Notify: ** DEVICE EXCEPTION ** 6WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 WMD_DEH_Notify: DSP_MMUFAULT,errInfo = 0x0 6WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 WMD_DEH_Notify: DSP_MMUFAULT, High Address = 0x2306 6WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 WMD_DEH_Notify: DSP_MMUFAULT, Low Address = 0x74a0 6WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 WMD_DEH_Notify: DSP_MMUFAULT, fault address = 0x230674a0 Do you have any ideas why this might be happening and how to fix it? Thanks a lot. This means that the DSP is trying to access a virtual memory for which no physical memory present, Can you please check why the memory allocation failing on the DSP? regards Ramesh -- 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
