RE: [PATCH] OMAP: DSS: Add NEC NL8048HL11-01B display panel
Hi Kishore,
Please see my comments below.
/Mikkel
On Tue, Jan 19, 2010 at 07:09:15, Y, Kishore wrote:
Cc: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP: DSS: Add NEC NL8048HL11-01B display panel
From: Erik Gilling konk...@android.com
NEC WVGA LCD NL8048HL11-01B support has been added.
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
---
drivers/video/omap2/displays/Kconfig |5 +
drivers/video/omap2/displays/Makefile |2 +
.../omap2/displays/panel-nec-NL8048HL11-01B.c | 282
3 files changed, 289 insertions(+), 0 deletions(-) create mode
100644 drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index b12a59c..18849e6 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -19,4 +19,9 @@ config PANEL_TAAL
help
Taal DSI command mode panel from TPO.
+config PANEL_NEC_NL8048HL11_01B
+tristate NEC NL8048HL11-01B Panel
+help
+ LCD Panel used in the Zoom boards
Well the LCD panel can be used in many boards, not only Zoom2. Please correct
the help text.
+
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 9556464..9180086 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -2,3 +2,5 @@ obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-NL8048HL11-01B.o
+
diff --git
a/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
new file mode 100644
index 000..91d8bd2
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
@@ -0,0 +1,282 @@
+/*
+ * NEC panel support
+ *
+ * This program is free software; you can redistribute it
and/or modify
+it
+ * under the terms of the GNU General Public License version 2 as
+published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be
useful, but
+WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY
+or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
+License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/spi/spi.h
+#include plat/gpio.h
+#include plat/mux.h
+#include asm/mach-types.h
+#include plat/control.h
+#include plat/display.h
+
+#define LCD_XRES 800
+#define LCD_YRES 480
+#define LCD_PIXCLOCK_MIN 21800 /* NEC MIN PIX
Clock is 21.8MHz */
+#define LCD_PIXCLOCK_TYP 23800 /* Typical PIX
clock is 23.8MHz */
+#define LCD_PIXCLOCK_MAX 25700 /* Maximum is 25.7MHz */
+/* Current Pixel clock */
+#define LCD_PIXEL_CLOCK LCD_PIXCLOCK_MIN
+
+/* NEC NL8048HL11-01B Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below */
+
+static struct omap_video_timings nec_8048_panel_timings = {
+ /* 800 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = LCD_XRES,
+ .y_res = LCD_YRES,
+ .pixel_clock= LCD_PIXEL_CLOCK,
+ .hfp= 6,
+ .hsw= 1,
+ .hbp= 4,
+ .vfp= 3,
+ .vsw= 1,
+ .vbp= 4,
+};
+
+static int nec_8048_panel_probe(struct omap_dss_device *dssdev) {
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
+ OMAP_DSS_LCD_ONOFF;
+ dssdev-panel.timings = nec_8048_panel_timings;
+ dssdev-panel.recommended_bpp = 16;
+
+ return 0;
+}
+
+static void nec_8048_panel_remove(struct omap_dss_device *dssdev) { }
+
+static int nec_8048_panel_enable(struct omap_dss_device *dssdev) {
+ int r = 0;
+
+ /* Delay recommended by panel DATASHEET */
+ mdelay(4);
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void nec_8048_panel_disable(struct omap_dss_device *dssdev) {
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+ /* Delay recommended by panel DATASHEET */
+ mdelay(4);
+}
+
+static int nec_8048_panel_suspend(struct omap_dss_device *dssdev) {
+ nec_8048_panel_disable(dssdev);
+ return 0;
+}
+
+static int nec_8048_panel_resume(struct omap_dss_device *dssdev) {
RE: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Mon, Oct 12, 2009 at 03:25:27, Tomi Valkeinen wrote:
Subject: Re: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Fri, 2009-10-09 at 23:08 +0200, ext Mikkel Christensen wrote:
This patch adds suspend / resume functionality to the RFBI
driver along with missing callback functions needed by OMAP Frame
buffer.
Signed-off-by: Mikkel Christensen m...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 76
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/rfbi.c
b/drivers/video/omap2/dss/rfbi.c index 9dd2349..ddfc472 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1181,6 +1181,7 @@ int rfbi_init(void)
/* Enable autoidle and smart-idle */
l = rfbi_read_reg(RFBI_SYSCONFIG);
+ l = ~((0x03 3)|(0x01 0));
l |= (1 0) | (2 3);
rfbi_write_reg(RFBI_SYSCONFIG, l);
@@ -1208,6 +1209,9 @@ static int rfbi_display_update(struct
omap_dss_device *dssdev, {
int rfbi_module;
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
if (w == 0 || h == 0)
return 0;
@@ -1239,6 +1243,18 @@ static int
rfbi_display_enable_te(struct omap_dss_device *dssdev, bool enable)
return 0;
}
+static enum omap_dss_update_mode rfbi_display_get_update_mode(
+ struct omap_dss_device *dssdev)
+{
+ return OMAP_DSS_UPDATE_MANUAL;
+}
+
+static int rfbi_display_set_update_mode(struct
omap_dss_device *dssdev,
+ enum omap_dss_update_mode mode)
+{
+ return 0;
+}
+
static int rfbi_display_enable(struct omap_dss_device *dssdev) {
int r;
@@ -1269,6 +1285,7 @@ static int rfbi_display_enable(struct
omap_dss_device *dssdev)
rfbi_set_timings(dssdev-phy.rfbi.channel,
dssdev-ctrl.rfbi_timings);
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
if (dssdev-driver-enable) {
r = dssdev-driver-enable(dssdev); @@ -1288,12
+1305,67 @@ err0:
static void rfbi_display_disable(struct omap_dss_device *dssdev) {
+ dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+
dssdev-driver-disable(dssdev);
omap_dispc_unregister_isr(framedone_callback, NULL,
DISPC_IRQ_FRAMEDONE);
omap_dss_stop_device(dssdev);
}
+static int rfbi_display_suspend(struct omap_dss_device *dssdev) {
+ unsigned long l;
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return -EINVAL;
+
+ DSSDBG(rfbi_display_suspend\n);
+
+ if (dssdev-driver-suspend)
+ dssdev-driver-suspend(dssdev);
+
+ dispc_enable_lcd_out(0);
I don't think this is needed. DSS hardware disables lcd_out when the
transfer has finished. Although for correct operation suspend() should
wait until the last transfer has been done before disabling clocks,
which is something it currently doesn't.
This was done with reference to the DPI and SDI files that do the same thing.
It can be removed if not necessary.
+
+ /* Force idle */
+ rfbi_enable_clocks(1);
+ l = rfbi_read_reg(RFBI_SYSCONFIG);
+ l = ~(0x03 3);
+ rfbi_write_reg(RFBI_SYSCONFIG, l);
+ rfbi_enable_clocks(0);
Why force idle?
The RFBI module must be forced to idle on suspend to allow for the DSS module
to idle. The CM_CLKSTST_DSS[CLKACTIVITY_DSS] bit does not change if the RFBI
module was configured to autoidle, preventing DSS from entering retention or
off.
+
+ dssdev-state = OMAP_DSS_DISPLAY_SUSPENDED;
+
+ return 0;
+}
+
+static int rfbi_display_resume(struct omap_dss_device *dssdev) {
+ unsigned long l;
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_SUSPENDED)
+ return -EINVAL;
+
+ DSSDBG(rfbi_display_resume\n);
+
+ /* Re-enable autoidle */
+ rfbi_enable_clocks(1);
+ l = rfbi_read_reg(RFBI_SYSCONFIG);
+ l = ~(0x03 3);
+ l |= (0x02 3);
+ rfbi_write_reg(RFBI_SYSCONFIG, l);
+ rfbi_enable_clocks(0);
+
+ dispc_enable_lcd_out(1);
This is not needed. lcd_out is enabled when the transfer is started.
This was done with reference to the DPI and SDI files that do the same thing.
It can be removed if not necessary.
+
+ if (dssdev-driver-resume)
+ dssdev-driver-resume(dssdev);
+
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ return 0;
+}
+
int rfbi_init_display(struct omap_dss_device *dssdev) {
dssdev-enable = rfbi_display_enable; @@ -1301,6
+1373,10 @@ int
rfbi_init_display(struct omap_dss_device *dssdev)
dssdev-update = rfbi_display_update;
dssdev-sync = rfbi_display_sync;
dssdev-enable_te = rfbi_display_enable_te;
+ dssdev-get_update_mode = rfbi_display_get_update_mode;
+ dssdev-set_update_mode = rfbi_display_set_update_mode;
+ dssdev-suspend = rfbi_display_suspend;
+ dssdev-resume = rfbi_display_resume;
RE: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Mon, Oct 12, 2009 at 09:17:27, Tomi Valkeinen wrote:
Subject: RE: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Mon, 2009-10-12 at 16:03 +0200, ext Christensen, Mikkel wrote:
On Mon, Oct 12, 2009 at 03:25:27, Tomi Valkeinen wrote:
Subject: Re: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Fri, 2009-10-09 at 23:08 +0200, ext Mikkel Christensen wrote:
This patch adds suspend / resume functionality to the RFBI
driver along with missing callback functions needed by OMAP Frame
buffer.
Signed-off-by: Mikkel Christensen m...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 76
1 files changed, 76 insertions(+), 0 deletions(-)
snip
+static int rfbi_display_suspend(struct omap_dss_device
*dssdev) {
+ unsigned long l;
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return -EINVAL;
+
+ DSSDBG(rfbi_display_suspend\n);
+
+ if (dssdev-driver-suspend)
+ dssdev-driver-suspend(dssdev);
+
+ dispc_enable_lcd_out(0);
I don't think this is needed. DSS hardware disables
lcd_out when the
transfer has finished. Although for correct operation suspend()
should wait until the last transfer has been done before
disabling
clocks, which is something it currently doesn't.
This was done with reference to the DPI and SDI files that
do the same thing. It can be removed if not necessary.
DPI and SDI work quite differently than RFBI, you can't just copy
their functionality =).
It is more correct without disable/enable_lcd_out, but it's not
correct as there may be a transfer ongoing when suspend call comes.
That's why there should be some mechanism to wait until the transfer
has been done.
DSI tries to do this (and hopefully correctly does =).
OK. Thanks I will try to incorporate this. Where in the DSI driver is this
mechanism implemented?
+
+ /* Force idle */
+ rfbi_enable_clocks(1);
+ l = rfbi_read_reg(RFBI_SYSCONFIG);
+ l = ~(0x03 3);
+ rfbi_write_reg(RFBI_SYSCONFIG, l);
+ rfbi_enable_clocks(0);
Why force idle?
The RFBI module must be forced to idle on suspend to allow
for the DSS module to idle. The
CM_CLKSTST_DSS[CLKACTIVITY_DSS] bit does not change if the RFBI module
was configured to autoidle, preventing DSS from entering retention or
off.
Why must it? Is there a hardware bug (what errata number?)?
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 v2 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
Hi Kevin On Fri, May 15, 2009 at 13:04:42, Kevin Hilman wrote: --- arch/arm/mach-omap2/board-zoom2-debugboard.c | 165 ++ arch/arm/mach-omap2/board-zoom2.c| 109 + 2 files changed, 274 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom2-debugboard.c create mode 100644 arch/arm/mach-omap2/board-zoom2.c diff --git a/arch/arm/mach-omap2/board-zoom2-debugboard.c b/arch/arm/mach-omap2/board-zoom2-debugboard.c new file mode 100644 index 000..e89b3af --- /dev/null +++ b/arch/arm/mach-omap2/board-zoom2-debugboard.c @@ -0,0 +1,165 @@ +/* + * arch/arm/mach-omap2/board-zoom2-debugboard.c Can you drop the filename here, and in the other files as well. Sure I can do the change. Is this a new convention being used? I can see the file name in many other files as well. /Mikkel -- 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 broken in 2.6.30-rc 2
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Christensen, Mikkel Sent: Monday, April 20, 2009 3:28 PM To: linux-omap@vger.kernel.org Subject: LDP broken in 2.6.30-rc 2 I cloned master a few days ago and when I boot up the OMAP3 LDP, the board seem to hang in the i2c /dev entries driver dialog and after a minute the kernel dumps. Have anybody else seen this problem? I found that the commit 92f00c2fa10629bad7206cd613d3b3357c8d6a81 - Extra omap code in linux-omap tree breaks the LDP bootup. Best regards, Mikkel -- 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 broken in 2.6.30-rc 2
Hi, On 2.6.29 I can use NFS and the board will boot my file system. On the 2.6.30-rc 2 the board is not even coming this far. Best regards, Mikkel -Original Message- From: Koen Kooi [mailto:k.k...@student.utwente.nl] Sent: Tuesday, April 21, 2009 2:31 AM To: Christensen, Mikkel Cc: linux-omap@vger.kernel.org Subject: Re: LDP broken in 2.6.30-rc 2 Op 20 apr 2009, om 22:28 heeft Christensen, Mikkel het volgende geschreven: I cloned master a few days ago and when I boot up the OMAP3 LDP, the board seem to hang in the i2c /dev entries driver dialog and after a minute the kernel dumps. Have anybody else seen this problem? LDP was broken in .29 as well, at least for mmc: http://patchwork.kernel.org/patch/15340/ regards, Koen -- 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
LDP broken in 2.6.30-rc 2
Hi, I cloned master a few days ago and when I boot up the OMAP3 LDP, the board seem to hang in the i2c /dev entries driver dialog and after a minute the kernel dumps. Have anybody else seen this problem? Log is below. Best regards, Mikkel Bytes transferred = 1851164 (1c3f1c hex) ## Booting image at 8000 ... Image Name: Linux-2.6.30-rc2-omap1-05648-g8e Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1851100 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... 5Linux version 2.6.30-rc2-omap1-05648-g8e58316-dirty (a0389...@a0389005-desktop) (gcc version 4.2.3 (Sourcery G++ Lite 20089 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP LDP board Memory policy: ECC disabled, Data cache writeback 7On node 0 totalpages: 28672 7free_area_init_node: node 0, pgdat c0391ac8, node_mem_map c03ad000 7 Normal zone: 224 pages used for memmap 7 Normal zone: 0 pages reserved 7 Normal zone: 28448 pages, LIFO batch:7 6OMAP3430 ES2.1 6SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 28448 5Kernel command line: console=ttyS2,115200n8 noinitrd mem=112M root=/dev/nfs rw nfsroot=128.247.85.60:/home/a0389051/omap34p 6NR_IRQS:402 6Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz 6GPMC revision 5.0 6IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts 6Total of 96 interrupts on 1 active controller 6OMAP34xx GPIO hardware version 2.5 PID hash table entries: 512 (order: 9, 2048 bytes) 6OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 6Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) 6Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) 6Memory: 112MB = 112MB total 5Memory: 109780KB available (3176K code, 292K data, 144K init, 0K highmem) 6Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696) Mount-cache hash table entries: 512 6CPU: Testing write buffer coherency: ok 6net_namespace: 520 bytes 6regulator: core version 0.5 6NET: Registered protocol family 16 3mmci-omap-hs.0: use which platform_data? 6OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 6i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz 6twl4030: PIH (irq 7) chaining IRQs 368..375 6twl4030: power (irq 373) chaining IRQs 376..383 3twl4030_bci: use which platform_data? 3twl4030_gpio: use which platform_data? 6twl4030: gpio (irq 368) chaining IRQs 384..401 3twl4030_keypad: use which platform_data? 3twl4030_madc: use which platform_data? 3twl4030_usb: use which platform_data? 3twl4030_reg.17: use which platform_data? 3set_machine_constraints: invalid 'VUSB1V5' voltage constraints 3twl4030_reg twl4030_reg.17: can't register VUSB1V5, -22 4twl4030_reg: probe of twl4030_reg.17 failed with error -22 3twl4030_reg.18: use which platform_data? 3set_machine_constraints: invalid 'VUSB1V8' voltage constraints 3twl4030_reg twl4030_reg.18: can't register VUSB1V8, -22 4twl4030_reg: probe of twl4030_reg.18 failed with error -22 3twl4030_reg.19: use which platform_data? 3set_machine_constraints: invalid 'VUSB3V1' voltage constraints 3twl4030_reg twl4030_reg.19: can't register VUSB3V1, -22 4twl4030_reg: probe of twl4030_reg.19 failed with error -22 6i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz 6i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz 5SCSI subsystem initialized 3twl4030_usb twl4030_usb: ldo init failed 6usbcore: registered new interface driver usbfs 6usbcore: registered new interface driver hub 6usbcore: registered new device driver usb 6musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 7Switched to high resolution mode on CPU 0 7musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X)) 7musb_hdrc: MHDRC RTL version 1.400 7musb_hdrc: setup fifo_mode 4 7musb_hdrc: 29/31 max ep, 15424/16384 memory 7musb_hdrc: hw_ep 0shared, max 64 7musb_hdrc: hw_ep 1tx, max 512 7musb_hdrc: hw_ep 1rx, max 512 7musb_hdrc: hw_ep 2tx, max 512 7musb_hdrc: hw_ep 2rx, max 512 7musb_hdrc: hw_ep 3tx, max 512 7musb_hdrc: hw_ep 3rx, max 512 7musb_hdrc: hw_ep 4tx, max 512 7musb_hdrc: hw_ep 4rx, max 512 7musb_hdrc: hw_ep 5tx, max 512 7musb_hdrc: hw_ep 5rx, max 512 7musb_hdrc: hw_ep 6tx, max 512 7musb_hdrc: hw_ep 6rx, max 512 7musb_hdrc: hw_ep 7tx, max 512 7musb_hdrc: hw_ep 7rx, max 512 7musb_hdrc: hw_ep 8tx, max 512 7musb_hdrc: hw_ep 8rx, max 512 7musb_hdrc: hw_ep 9tx, max 512 7musb_hdrc: hw_ep 9rx, max 512 7musb_hdrc: hw_ep 10tx, max 512 7musb_hdrc: hw_ep 10rx, max 512 7musb_hdrc: hw_ep 11tx, max 512 7musb_hdrc: hw_ep 11rx, max 512 7musb_hdrc: hw_ep 12tx, max 512 7musb_hdrc: hw_ep
