* [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:21 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
init functions in omap board files request panel specific gpios, and provide
functions which omapdss panel drivers call to enable or disable them.
Instead of the board files requesting these gpios, they should just pass the
platform specific data(like the gpio numbers), the panel should retrieve the
platform data and request the gpios. Doing this prevents the need of the panel
driver calling platform functions in board files.
Panel drivers have their own platform data struct, and the board files populate
these structs and pass the pointer to the 'data' field of omap_dss_device. This
work will make it easier for the panel drivers be more adaptable to the
DT model.
There is also removal of passing panel reset_gpio numbers through
omap_dss_device struct directly, reset gpios are passed through platform data
only.
Reference tree:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git for-3.9/remove_enable_disable_callbacks
Archit Taneja (32):
OMAPDSS: panels: keep platform data of all panels in a single header
arm: omap: board-2430: use generic dpi panel's gpio handling
arm: omap: board-devkit8000: use generic dpi panel's gpio handling
arm: omap: board-cm-t35: use generic dpi panel's gpio handling
arm: omap: board-apollon: use generic dpi panel's gpio handling
arm: omap: board-am3517: use generic dpi panel's gpio handling
arm: omap: board-ldp: use generic dpi panel's gpio handling
OMAPDSS: lb035q02: handle gpios in panel driver
arm: omap: board-overo: use lb035q02 dpi panel's gpio handling
OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks
OMAPDSS: generic dpi panel: remove platform_enable/disable ops from
platform_data
arm: omap: board-omap3evm: use sharp panel's gpio handling
arm: omap: board-sdp3430: use sharp panel's gpio handling
OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks
OMAPDSS: acx565akm panel: handle gpios in panel driver
arm: omap: board-rx-51: use acx565akm panel's gpio handling
OMAPDSS: nec-nl8048 panel: handle gpios ins panel driver
arm: omap: board-zoom: use NEC panel's gpio handling
OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks
OMAPDSS: tpo-td043 panel: handle gpios in panel driver
arm: omap: board-omap3pandora: use tpo panel's gpio handling
OMAPDSS: tpo-td043: remove platform_enable/disable callbacks
OMAPDSS: picodlp panel: handle gpio data in panel driver
arm: omap: dss-common: use picodlp panel's gpio handling
OMAPDSS: picodlp panel: remove platform_enable/disable callbacks
OMAPDSS: n8x0 panel: handle gpio data in panel driver
OMAPDSS: n8x0 panel: remove platform_enable/disable callbacks
arm: omap boards: Remove unnecessary platform_enable/disable
callbacks for VENC devices
OMAPDSS: VENC: remove platform_enable/disable calls
OMAPDSS: remove platform_enable/disable callbacks from
omap_dss_device
arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device
OMAPDSS: remove reset_gpio field from omap_dss_device
Tomi Valkeinen (1):
OMAPDSS: generic dpi panel: handle gpios in panel driver
arch/arm/mach-omap2/board-2430sdp.c | 45 +-----
arch/arm/mach-omap2/board-3430sdp.c | 55 +++-----
arch/arm/mach-omap2/board-am3517evm.c | 77 +----------
arch/arm/mach-omap2/board-apollon.c | 11 +-
arch/arm/mach-omap2/board-cm-t35.c | 60 +-------
arch/arm/mach-omap2/board-devkit8000.c | 30 +---
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c | 63 ++-------
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/board-omap3evm.c | 72 +++-------
arch/arm/mach-omap2/board-omap3pandora.c | 7 +-
arch/arm/mach-omap2/board-omap3stalker.c | 14 +-
arch/arm/mach-omap2/board-overo.c | 61 ++-------
arch/arm/mach-omap2/board-rx51-video.c | 26 +---
arch/arm/mach-omap2/board-zoom-display.c | 38 ++----
arch/arm/mach-omap2/dss-common.c | 58 +++-----
drivers/video/omap2/displays/panel-acx565akm.c | 48 +++++--
drivers/video/omap2/displays/panel-generic-dpi.c | 33 +++--
.../omap2/displays/panel-lgphilips-lb035q02.c | 44 ++++--
drivers/video/omap2/displays/panel-n8x0.c | 29 ++--
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 53 ++++---
drivers/video/omap2/displays/panel-picodlp.c | 35 +++--
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 78 ++++++++---
drivers/video/omap2/displays/panel-taal.c | 2 +-
drivers/video/omap2/displays/panel-tfp410.c | 2 +-
.../video/omap2/displays/panel-tpo-td043mtea1.c | 45 +++---
drivers/video/omap2/dss/venc.c | 9 --
include/video/omap-panel-data.h | 144 ++++++++++++++++++++
include/video/omap-panel-generic-dpi.h | 37 -----
include/video/omap-panel-n8x0.h | 13 --
include/video/omap-panel-nokia-dsi.h | 32 -----
include/video/omap-panel-picodlp.h | 23 ----
include/video/omap-panel-tfp410.h | 35 -----
include/video/omapdss.h | 6 -
35 files changed, 528 insertions(+), 763 deletions(-)
create mode 100644 include/video/omap-panel-data.h
delete mode 100644 include/video/omap-panel-generic-dpi.h
delete mode 100644 include/video/omap-panel-n8x0.h
delete mode 100644 include/video/omap-panel-nokia-dsi.h
delete mode 100644 include/video/omap-panel-picodlp.h
delete mode 100644 include/video/omap-panel-tfp410.h
--
1.7.9.5
^ permalink raw reply [flat|nested] 134+ messages in thread
* [PATCH 01/33] OMAPDSS: panels: keep platform data of all panels in a single header
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:33 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:21 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
Structs for platform data of omapdss panels are found in headers in the
'include/video/' path. Board files populate these structs with platform
specific values, and the panel driver uses these to configure the panel.
Currently, each panel has it's own header in the above path. Move all the
omapdss panel platform data structs to a single header omap-panel-data.h.
This is useful because:
- All other omapdss panel drivers will be modified to use platform data. This
would lead to a lot of panel headers usable only by omapdss. A lot of these
platform data structs are trivial, and don't really need a separate header.
- Platform data would be eventually removed, and platform information would be
passed via device tree. Therefore, omapdss panel platform data structs are
temporary, and will be easier to remove if they are all in the same header.
- All board files will have to include the same header to configure a panel's
platform data, that makes the board files more consistent.
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-2430sdp.c | 2 +-
arch/arm/mach-omap2/board-3430sdp.c | 2 +-
arch/arm/mach-omap2/board-am3517evm.c | 3 +-
arch/arm/mach-omap2/board-apollon.c | 2 +-
arch/arm/mach-omap2/board-cm-t35.c | 3 +-
arch/arm/mach-omap2/board-devkit8000.c | 3 +-
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c | 2 +-
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/board-omap3evm.c | 2 +-
arch/arm/mach-omap2/board-omap3stalker.c | 3 +-
arch/arm/mach-omap2/board-overo.c | 3 +-
arch/arm/mach-omap2/dss-common.c | 4 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 2 +-
drivers/video/omap2/displays/panel-n8x0.c | 2 +-
drivers/video/omap2/displays/panel-picodlp.c | 2 +-
drivers/video/omap2/displays/panel-taal.c | 2 +-
drivers/video/omap2/displays/panel-tfp410.c | 2 +-
include/video/omap-panel-data.h | 101 ++++++++++++++++++++++
include/video/omap-panel-generic-dpi.h | 37 --------
include/video/omap-panel-n8x0.h | 13 ---
include/video/omap-panel-nokia-dsi.h | 32 -------
include/video/omap-panel-picodlp.h | 23 -----
include/video/omap-panel-tfp410.h | 35 --------
25 files changed, 120 insertions(+), 166 deletions(-)
create mode 100644 include/video/omap-panel-data.h
delete mode 100644 include/video/omap-panel-generic-dpi.h
delete mode 100644 include/video/omap-panel-n8x0.h
delete mode 100644 include/video/omap-panel-nokia-dsi.h
delete mode 100644 include/video/omap-panel-picodlp.h
delete mode 100644 include/video/omap-panel-tfp410.h
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 4815ea6..13a1a3b 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -37,7 +37,7 @@
#include "gpmc-smc91x.h"
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
#include "mux.h"
#include "hsmmc.h"
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..fb75a81 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -33,7 +33,7 @@
#include "common.h"
#include <linux/omap-dma.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include "gpmc.h"
#include "gpmc-smc91x.h"
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index f81a303..2988049 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,8 +35,7 @@
#include "common.h"
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include "am35xx-emac.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c
index 5d0a61f..d2a83a8 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -38,7 +38,7 @@
#include "gpmc.h"
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
#include "mux.h"
#include "control.h"
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index b3102c2..f940a79 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -40,8 +40,7 @@
#include <linux/platform_data/mtd-nand-omap2.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include "common.h"
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 12865af..019b212 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -42,8 +42,7 @@
#include "gpmc.h"
#include <linux/platform_data/mtd-nand-omap2.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <linux/input/matrix_keypad.h>
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 3be1311..88d1b5b 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -34,7 +34,7 @@
#include <asm/mach/map.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
#include "common.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 0f24cb8..810e168 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -30,7 +30,7 @@
#include <asm/mach/arch.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/mtd-onenand-omap2.h>
#include "common.h"
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 0869f4f..68e56f1 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -40,7 +40,7 @@
#include "gpmc-smsc911x.h"
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
#include "board-flash.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 22c483d..8d357ce 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -40,7 +40,7 @@
#include <asm/mach/flash.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/mtd-nand-omap2.h>
#include "common.h"
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 3985f35..335127d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -50,7 +50,7 @@
#include "common.h"
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include "soc.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 53a6cbc..621ace1 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -43,8 +43,7 @@
#include "gpmc.h"
#include <linux/platform_data/mtd-nand-omap2.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index c8fde3e..bf6b2ce 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -46,8 +46,7 @@
#include <asm/mach/map.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include "common.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 4be5cfc..9c49bbe 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -27,9 +27,7 @@
#include <linux/gpio.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
-#include <video/omap-panel-nokia-dsi.h>
-#include <video/omap-panel-picodlp.h>
+#include <video/omap-panel-data.h>
#include "soc.h"
#include "dss-common.h"
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index 6cb2fe0..d8d0cd5 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -35,7 +35,7 @@
#include <linux/slab.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
struct panel_config {
struct omap_video_timings timings;
diff --git a/drivers/video/omap2/displays/panel-n8x0.c b/drivers/video/omap2/displays/panel-n8x0.c
index b750480..9c55c91 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -8,7 +8,7 @@
#include <linux/fb.h>
#include <video/omapdss.h>
-#include <video/omap-panel-n8x0.h>
+#include <video/omap-panel-data.h>
#define BLIZZARD_REV_CODE 0x00
#define BLIZZARD_CONFIG 0x02
diff --git a/drivers/video/omap2/displays/panel-picodlp.c b/drivers/video/omap2/displays/panel-picodlp.c
index 3864299..56d536c 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -31,7 +31,7 @@
#include <linux/gpio.h>
#include <video/omapdss.h>
-#include <video/omap-panel-picodlp.h>
+#include <video/omap-panel-data.h>
#include "panel-picodlp.h"
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index a32407a..031d406 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -33,7 +33,7 @@
#include <linux/mutex.h>
#include <video/omapdss.h>
-#include <video/omap-panel-nokia-dsi.h>
+#include <video/omap-panel-data.h>
#include <video/mipi_display.h>
/* DSI Virtual channel. Hardcoded for now. */
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index 8281baa..a1dba868 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -24,7 +24,7 @@
#include <linux/gpio.h>
#include <drm/drm_edid.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
static const struct omap_video_timings tfp410_default_timings = {
.x_res = 640,
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
new file mode 100644
index 0000000..e8e30f9
--- /dev/null
+++ b/include/video/omap-panel-data.h
@@ -0,0 +1,101 @@
+/*
+ * Header containing platform_data structs for omap panels
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ * Archit Taneja <archit@ti.com>
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Mayuresh Janorkar <mayur@ti.com>
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu <bryan.wu@canonical.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __OMAP_PANEL_DATA_H
+#define __OMAP_PANEL_DATA_H
+
+struct omap_dss_device;
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+/**
+ * struct panel_n8x0_data - N800 panel driver configuration data
+ */
+struct panel_n8x0_data {
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+ int panel_reset;
+ int ctrl_pwrdown;
+};
+
+/**
+ * struct nokia_dsi_panel_data - Nokia DSI panel driver configuration data
+ * @name: panel name
+ * @use_ext_te: use external TE
+ * @ext_te_gpio: external TE GPIO
+ * @esd_interval: interval of ESD checks, 0 = disabled (ms)
+ * @ulps_timeout: time to wait before entering ULPS, 0 = disabled (ms)
+ * @use_dsi_backlight: true if panel uses DSI command to control backlight
+ * @pin_config: DSI pin configuration
+ */
+
+struct nokia_dsi_panel_data {
+ const char *name;
+
+ int reset_gpio;
+
+ bool use_ext_te;
+ int ext_te_gpio;
+
+ unsigned esd_interval;
+ unsigned ulps_timeout;
+
+ bool use_dsi_backlight;
+
+ struct omap_dsi_pin_config pin_config;
+};
+
+/**
+ * struct picodlp_panel_data - picodlp panel driver configuration data
+ * @picodlp_adapter_id: i2c_adapter number for picodlp
+ */
+struct picodlp_panel_data {
+ int picodlp_adapter_id;
+ int emu_done_gpio;
+ int pwrgood_gpio;
+};
+
+/**
+ * struct tfp410_platform_data - tfp410 panel driver configuration data
+ * @i2c_bus_num: i2c bus id for the panel
+ * @power_down_gpio: gpio number for PD pin (or -1 if not available)
+ */
+struct tfp410_platform_data {
+ int i2c_bus_num;
+ int power_down_gpio;
+};
+
+#endif /* __OMAP_PANEL_DATA_H */
diff --git a/include/video/omap-panel-generic-dpi.h b/include/video/omap-panel-generic-dpi.h
deleted file mode 100644
index 127e3f2..0000000
--- a/include/video/omap-panel-generic-dpi.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Header for generic DPI panel driver
- *
- * Copyright (C) 2010 Canonical Ltd.
- * Author: Bryan Wu <bryan.wu@canonical.com>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#ifndef __OMAP_PANEL_GENERIC_DPI_H
-#define __OMAP_PANEL_GENERIC_DPI_H
-
-struct omap_dss_device;
-
-/**
- * struct panel_generic_dpi_data - panel driver configuration data
- * @name: panel name
- * @platform_enable: platform specific panel enable function
- * @platform_disable: platform specific panel disable function
- */
-struct panel_generic_dpi_data {
- const char *name;
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
-};
-
-#endif /* __OMAP_PANEL_GENERIC_DPI_H */
diff --git a/include/video/omap-panel-n8x0.h b/include/video/omap-panel-n8x0.h
deleted file mode 100644
index 9cc69c8..0000000
--- a/include/video/omap-panel-n8x0.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __OMAP_PANEL_N8X0_H
-#define __OMAP_PANEL_N8X0_H
-
-struct omap_dss_device;
-
-struct panel_n8x0_data {
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
- int panel_reset;
- int ctrl_pwrdown;
-};
-
-#endif
diff --git a/include/video/omap-panel-nokia-dsi.h b/include/video/omap-panel-nokia-dsi.h
deleted file mode 100644
index 04219a2..0000000
--- a/include/video/omap-panel-nokia-dsi.h
+++ /dev/null
@@ -1,32 +0,0 @@
-#ifndef __OMAP_NOKIA_DSI_PANEL_H
-#define __OMAP_NOKIA_DSI_PANEL_H
-
-struct omap_dss_device;
-
-/**
- * struct nokia_dsi_panel_data - Nokia DSI panel driver configuration
- * @name: panel name
- * @use_ext_te: use external TE
- * @ext_te_gpio: external TE GPIO
- * @esd_interval: interval of ESD checks, 0 = disabled (ms)
- * @ulps_timeout: time to wait before entering ULPS, 0 = disabled (ms)
- * @use_dsi_backlight: true if panel uses DSI command to control backlight
- * @pin_config: DSI pin configuration
- */
-struct nokia_dsi_panel_data {
- const char *name;
-
- int reset_gpio;
-
- bool use_ext_te;
- int ext_te_gpio;
-
- unsigned esd_interval;
- unsigned ulps_timeout;
-
- bool use_dsi_backlight;
-
- struct omap_dsi_pin_config pin_config;
-};
-
-#endif /* __OMAP_NOKIA_DSI_PANEL_H */
diff --git a/include/video/omap-panel-picodlp.h b/include/video/omap-panel-picodlp.h
deleted file mode 100644
index 1c342ef..0000000
--- a/include/video/omap-panel-picodlp.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * panel data for picodlp panel
- *
- * Copyright (C) 2011 Texas Instruments
- *
- * Author: Mayuresh Janorkar <mayur@ti.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#ifndef __PANEL_PICODLP_H
-#define __PANEL_PICODLP_H
-/**
- * struct : picodlp panel data
- * picodlp_adapter_id: i2c_adapter number for picodlp
- */
-struct picodlp_panel_data {
- int picodlp_adapter_id;
- int emu_done_gpio;
- int pwrgood_gpio;
-};
-#endif /* __PANEL_PICODLP_H */
diff --git a/include/video/omap-panel-tfp410.h b/include/video/omap-panel-tfp410.h
deleted file mode 100644
index aef35e4..0000000
--- a/include/video/omap-panel-tfp410.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Header for TFP410 chip driver
- *
- * Copyright (C) 2011 Texas Instruments Inc
- * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#ifndef __OMAP_PANEL_TFP410_H
-#define __OMAP_PANEL_TFP410_H
-
-struct omap_dss_device;
-
-/**
- * struct tfp410_platform_data - panel driver configuration data
- * @i2c_bus_num: i2c bus id for the panel
- * @power_down_gpio: gpio number for PD pin (or -1 if not available)
- */
-struct tfp410_platform_data {
- int i2c_bus_num;
- int power_down_gpio;
-};
-
-#endif /* __OMAP_PANEL_TFP410_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 02/33] OMAPDSS: generic dpi panel: handle gpios in panel driver
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:33 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:21 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
The generic dpi panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Add a generic way of passing gpio information to the generic dpi panel driver
via it's platform_data. This information includes the number of gpios used by
the panel, the gpio number and logic level (active high/low) for each gpio. This
gpio data will be used by the driver to request and configure the gpios required
by the panel.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++++++++++++++++++++--
include/video/omap-panel-data.h | 7 ++++++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index d8d0cd5..4a12db6 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -33,6 +33,7 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -557,7 +558,7 @@ static inline struct panel_generic_dpi_data
static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
{
- int r;
+ int r, i;
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
struct panel_config *panel_config = drv_data->panel_config;
@@ -582,6 +583,11 @@ static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 0 : 1);
+ }
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -594,10 +600,16 @@ static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
struct panel_config *panel_config = drv_data->panel_config;
+ int i;
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ for (i = panel_data->num_gpios - 1; i >= 0; --i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 1 : 0);
+ }
+
if (panel_data->platform_disable)
panel_data->platform_disable(dssdev);
@@ -613,7 +625,7 @@ static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_config *panel_config = NULL;
struct panel_drv_data *drv_data = NULL;
- int i;
+ int i, r;
dev_dbg(&dssdev->dev, "probe\n");
@@ -630,6 +642,15 @@ static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
if (!panel_config)
return -EINVAL;
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->gpios[i],
+ panel_data->gpio_invert[i] ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ "panel gpio");
+ if (r)
+ return r;
+ }
+
dssdev->panel.timings = panel_config->timings;
drv_data = devm_kzalloc(&dssdev->dev, sizeof(*drv_data), GFP_KERNEL);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index e8e30f9..eec93f1 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -34,11 +34,18 @@ struct omap_dss_device;
* @name: panel name
* @platform_enable: platform specific panel enable function
* @platform_disable: platform specific panel disable function
+ * @num_gpios: number of gpios connected to panel
+ * @gpios: gpio numbers on the platform
+ * @gpio_invert: configure gpio as active high or low
*/
struct panel_generic_dpi_data {
const char *name;
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
+
+ int num_gpios;
+ int gpios[10];
+ bool gpio_invert[10];
};
/**
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 03/33] arm: omap: board-2430: use generic dpi panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:33 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:21 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The 2430sdp board file currently requests gpios required to configure the NEC
DPI panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-2430sdp.c | 43 +++++------------------------------
1 file changed, 6 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 13a1a3b..c888a58 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -107,24 +107,13 @@ static struct platform_device *sdp2430_devices[] __initdata = {
#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO 91
#define SDP2430_LCD_PANEL_ENABLE_GPIO 154
-static int sdp2430_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 1);
-
- return 0;
-}
-
-static void sdp2430_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 0);
- gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 0);
-}
-
static struct panel_generic_dpi_data sdp2430_panel_data = {
.name = "nec_nl2432dr22-11b",
- .platform_enable = sdp2430_panel_enable_lcd,
- .platform_disable = sdp2430_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ SDP2430_LCD_PANEL_ENABLE_GPIO,
+ SDP2430_LCD_PANEL_BACKLIGHT_GPIO,
+ },
};
static struct omap_dss_device sdp2430_lcd_device = {
@@ -145,26 +134,6 @@ static struct omap_dss_board_info sdp2430_dss_data = {
.default_device = &sdp2430_lcd_device,
};
-static void __init sdp2430_display_init(void)
-{
- int r;
-
- static struct gpio gpios[] __initdata = {
- { SDP2430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
- "LCD reset" },
- { SDP2430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW,
- "LCD Backlight" },
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- return;
- }
-
- omap_display_init(&sdp2430_dss_data);
-}
-
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
static struct omap_smc91x_platform_data board_smc91x_data = {
@@ -271,7 +240,7 @@ static void __init omap_2430sdp_init(void)
gpio_request_one(SECONDARY_LCD_GPIO, GPIOF_OUT_INIT_LOW,
"Secondary LCD backlight");
- sdp2430_display_init();
+ omap_display_init(&sdp2430_dss_data);
}
MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 04/33] arm: omap: board-devkit8000: use generic dpi panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:33 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:21 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The devkit8000 board file currently requests gpios required to configure the
innolux DPI panel, and provides platform_enable/disable callbacks to configure
them.
These tasks have been moved to the generic dpi panel driver itself and should
be removed from the board files.
Remove the gpio request and the platform callbacks from the board file.
Configure the gpio information in generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-devkit8000.c | 27 +++------------------------
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 019b212..ccef86d 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -102,19 +102,6 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(dssdev->reset_gpio))
- gpio_set_value_cansleep(dssdev->reset_gpio, 1);
- return 0;
-}
-
-static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(dssdev->reset_gpio))
- gpio_set_value_cansleep(dssdev->reset_gpio, 0);
-}
-
static struct regulator_consumer_supply devkit8000_vmmc1_supply[] = {
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
};
@@ -126,8 +113,7 @@ static struct regulator_consumer_supply devkit8000_vio_supply[] = {
static struct panel_generic_dpi_data lcd_panel = {
.name = "innolux_at070tn83",
- .platform_enable = devkit8000_panel_enable_lcd,
- .platform_disable = devkit8000_panel_disable_lcd,
+ /* gpios filled in code */
};
static struct omap_dss_device devkit8000_lcd_device = {
@@ -209,8 +195,6 @@ static struct gpio_led gpio_leds[];
static int devkit8000_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- int ret;
-
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
omap_hsmmc_late_init(mmc);
@@ -219,13 +203,8 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
/* TWL4030_GPIO_MAX + 0 is "LCD_PWREN" (out, active high) */
- devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
- ret = gpio_request_one(devkit8000_lcd_device.reset_gpio,
- GPIOF_OUT_INIT_LOW, "LCD_PWREN");
- if (ret < 0) {
- devkit8000_lcd_device.reset_gpio = -EINVAL;
- printk(KERN_ERR "Failed to request GPIO for LCD_PWRN\n");
- }
+ lcd_panel.num_gpios = 1;
+ lcd_panel.gpios[0] = gpio + TWL4030_GPIO_MAX + 0;
/* gpio + 7 is "DVI_PD" (out, active low) */
dvi_panel.power_down_gpio = gpio + 7;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:33 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:21 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The cm-t35 board file currently requests gpios required to configure the tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
enabled after a 50 millisecond delay. This code has been removed and is not
taken care of in the generic panel driver. The impact of this needs to be
tested. The panel's gpios are also not exported any more. Hence, they can't be
accessed via sysfs interface.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-cm-t35.c | 46 ++++--------------------------------
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index f940a79..563d5ab 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -189,32 +189,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int lcd_enabled;
-static int dvi_enabled;
-
-static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
- gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
-
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- lcd_enabled = 0;
-
- gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
-}
-
static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@ -226,8 +200,11 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
- .platform_enable = cm_t35_panel_enable_lcd,
- .platform_disable = cm_t35_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ CM_T35_LCD_BL_GPIO,
+ CM_T35_LCD_EN_GPIO
+ },
};
static struct omap_dss_device cm_t35_lcd_device = {
@@ -303,19 +280,6 @@ static void __init cm_t35_init_display(void)
spi_register_board_info(cm_t35_lcd_spi_board_info,
ARRAY_SIZE(cm_t35_lcd_spi_board_info));
- err = gpio_request_array(cm_t35_dss_gpios,
- ARRAY_SIZE(cm_t35_dss_gpios));
- if (err) {
- pr_err("CM-T35: failed to request DSS control GPIOs\n");
- return;
- }
-
- gpio_export(CM_T35_LCD_EN_GPIO, 0);
- gpio_export(CM_T35_LCD_BL_GPIO, 0);
-
- msleep(50);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
-
err = omap_display_init(&cm_t35_dss_data);
if (err) {
pr_err("CM-T35: failed to register DSS device\n");
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 06/33] arm: omap: board-apollon: use generic dpi panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:33 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:21 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The apollon board file currently configures the LCD_PWR_EN gpio by muxing the
corresponding pin to gpio 11, and configuring it in PULL UP mode.
Remove this muxing from the board file. Add the gpio information to generic dpi
panel's platform data so that it's passed to the panel driver. The panel driver
will take care of requesting and setting the LCD_PWR_EN gpio.
Note: This should be tested to ensure that setting the GPIO is equivalent to
configuring the GPIO in PULL UP mode. Also, this GPIO was just set once during
init, and never cleared, where as now the gpio will toggle everytime the panel
is disabled/enabled. The impact of this needs to be tested.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-apollon.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c
index d2a83a8..5cc957e 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -55,6 +55,8 @@
#define APOLLON_ETH_CS 1
#define APOLLON_ETHR_GPIO_IRQ 74
+#define APOLLON_LCD_PWR_EN 11
+
static struct mtd_partition apollon_partitions[] = {
{
.name = "X-Loader + U-Boot",
@@ -252,6 +254,10 @@ out:
static struct panel_generic_dpi_data apollon_panel_data = {
.name = "apollon",
+ .num_gpios = 1,
+ .gpios = {
+ APOLLON_LCD_PWR_EN,
+ },
};
static struct omap_dss_device apollon_lcd_device = {
@@ -306,9 +312,6 @@ static void __init omap_apollon_init(void)
/* REVISIT: where's the correct place */
omap_mux_init_signal("sys_nirq", OMAP_PULL_ENA | OMAP_PULL_UP);
- /* LCD PWR_EN */
- omap_mux_init_signal("mcbsp2_dr.gpio_11", OMAP_PULL_ENA | OMAP_PULL_UP);
-
/* Use Internal loop-back in MMC/SDIO Module Input Clock selection */
v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
v |= (1 << 24);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 07/33] arm: omap: board-am3517: use generic dpi panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:33 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:21 UTC (permalink / raw)
To: tomi.valkeinen
Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren, Vaibhav Hiremath
The am3517 board file currently requests gpios required to configure the sharp
lq DPI panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: It's not clear why the GPIOs were muxed as input signals in PULL down mode
in am3517_evm_display_init(). Also, only the LCD_PANEL_PWR was toggled in the
platform_enable/disable calls, the generic DPI panel driver will now toggle all
the three gpios on panel's disable/enable. We need to test if these changes to
see if they have any impact or not.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-am3517evm.c | 63 ++++-----------------------------
1 file changed, 6 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index 2988049..eb245a6 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -120,63 +120,14 @@ static int __init am3517_evm_i2c_init(void)
return 0;
}
-static int lcd_enabled;
-static int dvi_enabled;
-
-#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
- defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
-static struct gpio am3517_evm_dss_gpios[] __initdata = {
- /* GPIO 182 = LCD Backlight Power */
- { LCD_PANEL_BKLIGHT_PWR, GPIOF_OUT_INIT_HIGH, "lcd_backlight_pwr" },
- /* GPIO 181 = LCD Panel PWM */
- { LCD_PANEL_PWM, GPIOF_OUT_INIT_HIGH, "lcd bl enable" },
- /* GPIO 176 = LCD Panel Power enable pin */
- { LCD_PANEL_PWR, GPIOF_OUT_INIT_HIGH, "dvi enable" },
-};
-
-static void __init am3517_evm_display_init(void)
-{
- int r;
-
- omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_gpio(LCD_PANEL_BKLIGHT_PWR, OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_gpio(LCD_PANEL_PWM, OMAP_PIN_INPUT_PULLDOWN);
-
- r = gpio_request_array(am3517_evm_dss_gpios,
- ARRAY_SIZE(am3517_evm_dss_gpios));
- if (r) {
- printk(KERN_ERR "failed to get DSS panel control GPIOs\n");
- return;
- }
-
- printk(KERN_INFO "Display initialized successfully\n");
-}
-#else
-static void __init am3517_evm_display_init(void) {}
-#endif
-
-static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
- gpio_set_value(LCD_PANEL_PWR, 1);
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(LCD_PANEL_PWR, 0);
- lcd_enabled = 0;
-}
-
static struct panel_generic_dpi_data lcd_panel = {
.name = "sharp_lq",
- .platform_enable = am3517_evm_panel_enable_lcd,
- .platform_disable = am3517_evm_panel_disable_lcd,
+ .num_gpios = 3,
+ .gpios = {
+ LCD_PANEL_PWR,
+ LCD_PANEL_BKLIGHT_PWR,
+ LCD_PANEL_PWM,
+ },
};
static struct omap_dss_device am3517_evm_lcd_device = {
@@ -362,8 +313,6 @@ static void __init am3517_evm_init(void)
omap_mux_init_gpio(57, OMAP_PIN_OUTPUT);
usbhs_init(&usbhs_bdata);
am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
- /* DSS */
- am3517_evm_display_init();
/* RTC - S35390A */
am3517_evm_rtc_init();
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 08/33] arm: omap: board-ldp: use generic dpi panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The ldp board file currently requests gpios required to configure the NEC DPI
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Configure the gpio information in generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-ldp.c | 61 ++++++---------------------------------
1 file changed, 9 insertions(+), 52 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 68e56f1..c88d01a 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -180,34 +180,13 @@ static inline void __init ldp_init_smsc911x(void)
/* LCD */
-static int ldp_backlight_gpio;
-static int ldp_lcd_enable_gpio;
-
#define LCD_PANEL_RESET_GPIO 55
#define LCD_PANEL_QVGA_GPIO 56
-static int ldp_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(ldp_lcd_enable_gpio))
- gpio_direction_output(ldp_lcd_enable_gpio, 1);
- if (gpio_is_valid(ldp_backlight_gpio))
- gpio_direction_output(ldp_backlight_gpio, 1);
-
- return 0;
-}
-
-static void ldp_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(ldp_lcd_enable_gpio))
- gpio_direction_output(ldp_lcd_enable_gpio, 0);
- if (gpio_is_valid(ldp_backlight_gpio))
- gpio_direction_output(ldp_backlight_gpio, 0);
-}
-
static struct panel_generic_dpi_data ldp_panel_data = {
.name = "nec_nl2432dr22-11b",
- .platform_enable = ldp_panel_enable_lcd,
- .platform_disable = ldp_panel_disable_lcd,
+ .num_gpios = 4,
+ /* gpios filled in code */
};
static struct omap_dss_device ldp_lcd_device = {
@@ -230,41 +209,19 @@ static struct omap_dss_board_info ldp_dss_data = {
static void __init ldp_display_init(void)
{
- int r;
-
- static struct gpio gpios[] __initdata = {
- {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, "LCD RESET"},
- {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "LCD QVGA"},
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- return;
- }
+ ldp_panel_data.gpios[2] = LCD_PANEL_RESET_GPIO;
+ ldp_panel_data.gpios[3] = LCD_PANEL_QVGA_GPIO;
omap_display_init(&ldp_dss_data);
}
static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
{
- int r;
-
- struct gpio gpios[] = {
- {gpio + 7 , GPIOF_OUT_INIT_LOW, "LCD ENABLE"},
- {gpio + 15, GPIOF_OUT_INIT_LOW, "LCD BACKLIGHT"},
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- ldp_backlight_gpio = -EINVAL;
- ldp_lcd_enable_gpio = -EINVAL;
- return r;
- }
-
- ldp_backlight_gpio = gpio + 15;
- ldp_lcd_enable_gpio = gpio + 7;
+ ldp_panel_data.gpios[0] = gpio + 7;
+ ldp_panel_data.gpio_invert[0] = true;
+
+ ldp_panel_data.gpios[1] = gpio + 15;
+ ldp_panel_data.gpio_invert[1] = true;
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 09/33] OMAPDSS: lb035q02: handle gpios in panel driver
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The lgphilips panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Use the platform data as defined for generic dpi panels to pass gpio information
to the lgphilips driver.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 38 +++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
index 8effea8..63cd8857 100644
--- a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
@@ -20,8 +20,10 @@
#include <linux/delay.h>
#include <linux/spi/spi.h>
#include <linux/mutex.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
struct lb035q02_data {
struct mutex lock;
@@ -48,9 +50,16 @@ static struct omap_video_timings lb035q02_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_generic_dpi_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_generic_dpi_data *) dssdev->data;
+}
+
static int lb035q02_panel_power_on(struct omap_dss_device *dssdev)
{
- int r;
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
+ int r, i;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
return 0;
@@ -68,6 +77,11 @@ static int lb035q02_panel_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 0 : 1);
+ }
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -77,9 +91,17 @@ err0:
static void lb035q02_panel_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
+ int i;
+
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ for (i = panel_data->num_gpios - 1; i >= 0; --i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 1 : 0);
+ }
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
@@ -88,7 +110,12 @@ static void lb035q02_panel_power_off(struct omap_dss_device *dssdev)
static int lb035q02_panel_probe(struct omap_dss_device *dssdev)
{
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct lb035q02_data *ld;
+ int r, i;
+
+ if (!panel_data)
+ return -EINVAL;
dssdev->panel.timings = lb035q02_timings;
@@ -96,6 +123,15 @@ static int lb035q02_panel_probe(struct omap_dss_device *dssdev)
if (!ld)
return -ENOMEM;
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->gpios[i],
+ panel_data->gpio_invert[i] ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ "panel gpio");
+ if (r)
+ return r;
+ }
+
mutex_init(&ld->lock);
dev_set_drvdata(&dssdev->dev, ld);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 10/33] arm: omap: board-overo: use lb035q02 dpi panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The overo board file currently requests gpios required by the lb035q02 panel,
and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the lb035q02 dpi panel driver itself and should
be removed from the board files.
The lb035q02 panel driver uses generic dpi panel's platform data struct
internally. Remove the gpio requests and the platform callbacks from the board
file. Add the gpio information to the generic dpi panel platform data struct so
that it's passed to the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-overo.c | 58 +++++++++----------------------------
1 file changed, 14 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index bf6b2ce..888e150 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -144,28 +144,9 @@ static inline void __init overo_init_smsc911x(void) { return; }
#endif
/* DSS */
-static int lcd_enabled;
-static int dvi_enabled;
-
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145
-static struct gpio overo_dss_gpios[] __initdata = {
- { OVERO_GPIO_LCD_EN, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_EN" },
- { OVERO_GPIO_LCD_BL, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_BL" },
-};
-
-static void __init overo_display_init(void)
-{
- if (gpio_request_array(overo_dss_gpios, ARRAY_SIZE(overo_dss_gpios))) {
- printk(KERN_ERR "could not obtain DSS control GPIOs\n");
- return;
- }
-
- gpio_export(OVERO_GPIO_LCD_EN, 0);
- gpio_export(OVERO_GPIO_LCD_BL, 0);
-}
-
static struct tfp410_platform_data dvi_panel = {
.i2c_bus_num = 3,
.power_down_gpio = -1,
@@ -186,30 +167,13 @@ static struct omap_dss_device overo_tv_device = {
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
};
-static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(OVERO_GPIO_LCD_EN, 1);
- gpio_set_value(OVERO_GPIO_LCD_BL, 1);
- lcd_enabled = 1;
- return 0;
-}
-
-static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(OVERO_GPIO_LCD_EN, 0);
- gpio_set_value(OVERO_GPIO_LCD_BL, 0);
- lcd_enabled = 0;
-}
-
static struct panel_generic_dpi_data lcd43_panel = {
.name = "samsung_lte430wq_f0c",
- .platform_enable = overo_panel_enable_lcd,
- .platform_disable = overo_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ OVERO_GPIO_LCD_EN,
+ OVERO_GPIO_LCD_BL
+ },
};
static struct omap_dss_device overo_lcd43_device = {
@@ -222,13 +186,20 @@ static struct omap_dss_device overo_lcd43_device = {
#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
+static struct panel_generic_dpi_data lcd35_panel = {
+ .num_gpios = 2,
+ .gpios = {
+ OVERO_GPIO_LCD_EN,
+ OVERO_GPIO_LCD_BL
+ },
+};
+
static struct omap_dss_device overo_lcd35_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = "lcd35",
.driver_name = "lgphilips_lb035q02_panel",
.phy.dpi.data_lines = 24,
- .platform_enable = overo_panel_enable_lcd,
- .platform_disable = overo_panel_disable_lcd,
+ .data = &lcd35_panel,
};
#endif
@@ -502,7 +473,6 @@ static void __init overo_init(void)
usbhs_init(&usbhs_bdata);
overo_spi_init();
overo_init_smsc911x();
- overo_display_init();
overo_init_led();
overo_init_keys();
omap_twl4030_audio_init("overo");
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 11/33] OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The lgphilips panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
index 63cd8857..4ea6548 100644
--- a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
@@ -71,20 +71,13 @@ static int lb035q02_panel_power_on(struct omap_dss_device *dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
for (i = 0; i < panel_data->num_gpios; ++i) {
gpio_set_value_cansleep(panel_data->gpios[i],
panel_data->gpio_invert[i] ? 0 : 1);
}
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -102,9 +95,6 @@ static void lb035q02_panel_power_off(struct omap_dss_device *dssdev)
panel_data->gpio_invert[i] ? 1 : 0);
}
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 12/33] OMAPDSS: generic dpi panel: remove platform_enable/disable ops from platform_data
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The generic dpi panel driver now sets the gpios required to configure the panel.
This was previously done in platform_enable/disable callbacks in board files.
All the board files using generic dpi panel now correctly pass the gpio related
information as platform data, which is needed by the panel driver to configure
the panel. Hence, the platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-generic-dpi.c | 12 +---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 71 +++++++++++++++++---
include/video/omap-panel-data.h | 20 ++++--
3 files changed, 77 insertions(+), 26 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index 4a12db6..64d93b1 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -577,20 +577,13 @@ static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
if (panel_config->power_on_delay)
msleep(panel_config->power_on_delay);
- if (panel_data->platform_enable) {
- r = panel_data->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
for (i = 0; i < panel_data->num_gpios; ++i) {
gpio_set_value_cansleep(panel_data->gpios[i],
panel_data->gpio_invert[i] ? 0 : 1);
}
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -610,9 +603,6 @@ static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
panel_data->gpio_invert[i] ? 1 : 0);
}
- if (panel_data->platform_disable)
- panel_data->platform_disable(dssdev);
-
/* wait couple of vsyncs after disabling the LCD */
if (panel_config->power_off_delay)
msleep(panel_config->power_off_delay);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index eb6bd81..e6d9c9b 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -23,11 +23,10 @@
#include <linux/fb.h>
#include <linux/err.h>
#include <linux/slab.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
-
-struct sharp_data {
-};
+#include <video/omap-panel-data.h>
static struct omap_video_timings sharp_ls_timings = {
.x_res = 480,
@@ -50,31 +49,67 @@ static struct omap_video_timings sharp_ls_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_sharp_ls037v7dw01_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_sharp_ls037v7dw01_data *) dssdev->data;
+}
static int sharp_ls_panel_probe(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd;
+ struct panel_sharp_ls037v7dw01_data *pd = get_panel_data(dssdev);
+ int r;
+
+ if (!pd)
+ return -EINVAL;
dssdev->panel.timings = sharp_ls_timings;
- sd = kzalloc(sizeof(*sd), GFP_KERNEL);
- if (!sd)
- return -ENOMEM;
+ if (gpio_is_valid(pd->mo_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->mo_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd MO");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->lr_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->lr_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd LR");
+ if (r)
+ return r;
+ }
- dev_set_drvdata(&dssdev->dev, sd);
+ if (gpio_is_valid(pd->ud_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->ud_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd UD");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->resb_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->resb_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RESB");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->ini_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->ini_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd INI");
+ if (r)
+ return r;
+ }
return 0;
}
static void __exit sharp_ls_panel_remove(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd = dev_get_drvdata(&dssdev->dev);
-
- kfree(sd);
}
static int sharp_ls_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_sharp_ls037v7dw01_data *pd = get_panel_data(dssdev);
int r = 0;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
@@ -96,6 +131,12 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ if (gpio_is_valid(pd->resb_gpio))
+ gpio_set_value_cansleep(pd->resb_gpio, 1);
+
+ if (gpio_is_valid(pd->ini_gpio))
+ gpio_set_value_cansleep(pd->ini_gpio, 1);
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -105,9 +146,17 @@ err0:
static void sharp_ls_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_sharp_ls037v7dw01_data *pd = get_panel_data(dssdev);
+
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ if (gpio_is_valid(pd->ini_gpio))
+ gpio_set_value_cansleep(pd->ini_gpio, 0);
+
+ if (gpio_is_valid(pd->resb_gpio))
+ gpio_set_value_cansleep(pd->resb_gpio, 0);
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index eec93f1..86da8d3 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -32,16 +32,12 @@ struct omap_dss_device;
/**
* struct panel_generic_dpi_data - panel driver configuration data
* @name: panel name
- * @platform_enable: platform specific panel enable function
- * @platform_disable: platform specific panel disable function
* @num_gpios: number of gpios connected to panel
* @gpios: gpio numbers on the platform
* @gpio_invert: configure gpio as active high or low
*/
struct panel_generic_dpi_data {
const char *name;
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
int num_gpios;
int gpios[10];
@@ -105,4 +101,20 @@ struct tfp410_platform_data {
int power_down_gpio;
};
+/**
+ * sharp ls panel driver configuration data
+ * @resb_gpio: reset signal
+ * @ini_gpio: power on control
+ * @mo_gpio: selection for resolution(VGA/QVGA)
+ * @lr_gpio: selection for horizontal scanning direction
+ * @ud_gpio: selection for vertical scanning direction
+ */
+struct panel_sharp_ls037v7dw01_data {
+ int resb_gpio;
+ int ini_gpio;
+ int mo_gpio;
+ int lr_gpio;
+ int ud_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 13/33] arm: omap: board-omap3evm: use sharp panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The omap3evm board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to panel_sharp_ls037v7dw01_data so that it's passed
to the panel driver.
Note: The GPIOs OMAP3EVM_LCD_PANEL_ENVDD and OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO
aren't directly connected to the sharp panel, hence they aren't passed to the
panel driver as platform data. These are set to a default value such that LCD
is enabled and backlight is on. These used to previously toggle through the
platform_enable/disable callbacks, but now these are always on. This needs to
be revisited.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-omap3evm.c | 59 ++++++++++++----------------------
1 file changed, 20 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 335127d..dfb5e1b 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -154,61 +154,43 @@ static inline void __init omap3evm_init_smsc911x(void) { return; }
#define OMAP3EVM_LCD_PANEL_LR 2
#define OMAP3EVM_LCD_PANEL_UD 3
#define OMAP3EVM_LCD_PANEL_INI 152
-#define OMAP3EVM_LCD_PANEL_ENVDD 153
#define OMAP3EVM_LCD_PANEL_QVGA 154
#define OMAP3EVM_LCD_PANEL_RESB 155
+
+#define OMAP3EVM_LCD_PANEL_ENVDD 153
#define OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO 210
+
+/*
+ * OMAP3EVM DVI control signals
+ */
#define OMAP3EVM_DVI_PANEL_EN_GPIO 199
-static struct gpio omap3_evm_dss_gpios[] __initdata = {
- { OMAP3EVM_LCD_PANEL_RESB, GPIOF_OUT_INIT_HIGH, "lcd_panel_resb" },
- { OMAP3EVM_LCD_PANEL_INI, GPIOF_OUT_INIT_HIGH, "lcd_panel_ini" },
- { OMAP3EVM_LCD_PANEL_QVGA, GPIOF_OUT_INIT_LOW, "lcd_panel_qvga" },
- { OMAP3EVM_LCD_PANEL_LR, GPIOF_OUT_INIT_HIGH, "lcd_panel_lr" },
- { OMAP3EVM_LCD_PANEL_UD, GPIOF_OUT_INIT_HIGH, "lcd_panel_ud" },
- { OMAP3EVM_LCD_PANEL_ENVDD, GPIOF_OUT_INIT_LOW, "lcd_panel_envdd" },
+static struct panel_sharp_ls037v7dw01_data omap3_evm_lcd_data = {
+ .resb_gpio = OMAP3EVM_LCD_PANEL_RESB,
+ .ini_gpio = OMAP3EVM_LCD_PANEL_INI,
+ .mo_gpio = OMAP3EVM_LCD_PANEL_QVGA,
+ .lr_gpio = OMAP3EVM_LCD_PANEL_LR,
+ .ud_gpio = OMAP3EVM_LCD_PANEL_UD,
};
-static int lcd_enabled;
-static int dvi_enabled;
-
static void __init omap3_evm_display_init(void)
{
int r;
- r = gpio_request_array(omap3_evm_dss_gpios,
- ARRAY_SIZE(omap3_evm_dss_gpios));
+ r = gpio_request_one(OMAP3EVM_LCD_PANEL_ENVDD, GPIOF_OUT_INIT_LOW,
+ "lcd_panel_envdd");
if (r)
- printk(KERN_ERR "failed to get lcd_panel_* gpios\n");
-}
+ pr_err("failed to get lcd_panel_envdd GPIO\n");
-static int omap3_evm_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
- gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 0);
+ r = gpio_request_one(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO,
+ GPIOF_OUT_INIT_LOW, "lcd_panel_bklight");
+ if (r)
+ pr_err("failed to get lcd_panel_bklight GPIO\n");
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
-
- lcd_enabled = 1;
- return 0;
-}
-
-static void omap3_evm_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 1);
-
- if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
- gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
- else
- gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
-
- lcd_enabled = 0;
}
static struct omap_dss_device omap3_evm_lcd_device = {
@@ -216,8 +198,7 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.driver_name = "sharp_ls_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 18,
- .platform_enable = omap3_evm_enable_lcd,
- .platform_disable = omap3_evm_disable_lcd,
+ .data = &omap3_evm_lcd_data,
};
static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 14/33] arm: omap: board-sdp3430: use sharp panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The omap3430sdp board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to panel_sharp_ls037v7dw01_data so that it's
passed to the panel driver.
Out of sharp panel's configurable pins, all apart from resb_gpio are managed by
a CPLD on the display and set to a default value. Only the configurable pin is
passed to platform data.
The backlight GPIO doesn't go directly to the sharp panel, it is used to set up
a voltage supply which goes to the LED+ pin of the panel, hence it isn't passed
to panel as platform data, and configured in the board file itself. The
backlight used to previously toggle through the platform_enable/disable
callbacks, but now it is always on. This needs to be revisited.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-3430sdp.c | 42 +++++++++++++++--------------------
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index fb75a81..13f1431 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -106,34 +106,22 @@ static struct twl4030_keypad_data sdp3430_kp_data = {
#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
-static struct gpio sdp3430_dss_gpios[] __initdata = {
- {SDP3430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, "LCD reset" },
- {SDP3430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, "LCD Backlight"},
-};
-
static void __init sdp3430_display_init(void)
{
int r;
- r = gpio_request_array(sdp3430_dss_gpios,
- ARRAY_SIZE(sdp3430_dss_gpios));
+ /*
+ * the backlight GPIO doesn't directly go to the panel, it enables
+ * an internal circuit on 3430sdp to create the signal V_BKL_28V,
+ * this is connected to LED+ pin of the sharp panel. This GPIO
+ * is left enabled in the board file, and not passed to the panel
+ * as platform_data.
+ */
+ r = gpio_request_one(SDP3430_LCD_PANEL_BACKLIGHT_GPIO,
+ GPIOF_OUT_INIT_HIGH, "LCD Backlight");
if (r)
- printk(KERN_ERR "failed to get LCD control GPIOs\n");
-
-}
-
-static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP3430_LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 1);
-
- return 0;
-}
+ pr_err("failed to get LCD Backlight GPIO\n");
-static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP3430_LCD_PANEL_ENABLE_GPIO, 0);
- gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 0);
}
static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -145,14 +133,20 @@ static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
{
}
+static struct panel_sharp_ls037v7dw01_data sdp3430_lcd_data = {
+ .resb_gpio = SDP3430_LCD_PANEL_ENABLE_GPIO,
+ .ini_gpio = -1,
+ .mo_gpio = -1,
+ .lr_gpio = -1,
+ .ud_gpio = -1,
+};
static struct omap_dss_device sdp3430_lcd_device = {
.name = "lcd",
.driver_name = "sharp_ls_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 16,
- .platform_enable = sdp3430_panel_enable_lcd,
- .platform_disable = sdp3430_panel_disable_lcd,
+ .data = &sdp3430_lcd_data,
};
static struct tfp410_platform_data dvi_panel = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 15/33] OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The sharp-ls panel driver now manages the gpios required to configure the panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_sharp_ls037v7dw01_data struct, which is needed by the panel
driver to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index e6d9c9b..74cb0eb 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -125,12 +125,6 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
if (gpio_is_valid(pd->resb_gpio))
gpio_set_value_cansleep(pd->resb_gpio, 1);
@@ -138,8 +132,6 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
gpio_set_value_cansleep(pd->ini_gpio, 1);
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
err0:
return r;
}
@@ -157,9 +149,6 @@ static void sharp_ls_power_off(struct omap_dss_device *dssdev)
if (gpio_is_valid(pd->resb_gpio))
gpio_set_value_cansleep(pd->resb_gpio, 0);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
/* wait at least 5 vsyncs after disabling the LCD */
msleep(100);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The acx565akm panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the panel
driver itself.
Create a platform data struct for the panel, this contains the reset gpio number
used by the panel driver, this struct will be passed to the panel driver as
platform data. The driver will request and configure the reset gpio rather than
leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-acx565akm.c | 48 ++++++++++++++++--------
include/video/omap-panel-data.h | 8 ++++
2 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c
index a8fb26b..d7f69c0 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -29,8 +29,10 @@
#include <linux/sched.h>
#include <linux/backlight.h>
#include <linux/fb.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
#define MIPID_CMD_READ_DISP_ID 0x04
#define MIPID_CMD_READ_RED 0x06
@@ -494,21 +496,38 @@ static struct omap_video_timings acx_panel_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device *dssdev)
+{
+ return (struct panel_acx565akm_data *) dssdev->data;
+}
+
static int acx_panel_probe(struct omap_dss_device *dssdev)
{
int r;
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
struct backlight_device *bldev;
int max_brightness, brightness;
struct backlight_properties props;
dev_dbg(&dssdev->dev, "%s\n", __func__);
+ if (!panel_data)
+ return -EINVAL;
+
/* FIXME AC bias ? */
dssdev->panel.timings = acx_panel_timings;
- if (dssdev->platform_enable)
- dssdev->platform_enable(dssdev);
+ if (gpio_is_valid(panel_data->reset_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->reset_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd reset");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 1);
+
/*
* After reset we have to wait 5 msec before the first
* command can be sent.
@@ -520,8 +539,9 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
r = panel_detect(md);
if (r) {
dev_err(&dssdev->dev, "%s panel detect error\n", __func__);
- if (!md->enabled && dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
+ if (!md->enabled && gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 0);
+
return r;
}
@@ -530,8 +550,8 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
mutex_unlock(&acx_dev.mutex);
if (!md->enabled) {
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 0);
}
/*------- Backlight control --------*/
@@ -584,6 +604,7 @@ static void acx_panel_remove(struct omap_dss_device *dssdev)
static int acx_panel_power_on(struct omap_dss_device *dssdev)
{
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
int r;
dev_dbg(&dssdev->dev, "%s\n", __func__);
@@ -605,11 +626,8 @@ static int acx_panel_power_on(struct omap_dss_device *dssdev)
/*FIXME tweak me */
msleep(50);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto fail;
- }
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 1);
if (md->enabled) {
dev_dbg(&md->spi->dev, "panel already enabled\n");
@@ -638,8 +656,7 @@ static int acx_panel_power_on(struct omap_dss_device *dssdev)
mutex_unlock(&md->mutex);
return acx565akm_bl_update_status(md->bl_dev);
-fail:
- omapdss_sdi_display_disable(dssdev);
+
fail_unlock:
mutex_unlock(&md->mutex);
return r;
@@ -648,6 +665,7 @@ fail_unlock:
static void acx_panel_power_off(struct omap_dss_device *dssdev)
{
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
dev_dbg(&dssdev->dev, "%s\n", __func__);
@@ -671,8 +689,8 @@ static void acx_panel_power_off(struct omap_dss_device *dssdev)
*/
msleep(50);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 0);
/* FIXME need to tweak this delay */
msleep(100);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 86da8d3..6faf0c7 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -117,4 +117,12 @@ struct panel_sharp_ls037v7dw01_data {
int ud_gpio;
};
+/**
+ * acx565akm panel driver configuration data
+ * @reset_gpio: reset signal
+ */
+struct panel_acx565akm_data {
+ int reset_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 17/33] arm: omap: board-rx-51: use acx565akm panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The rx-51 board file currently requests gpios required by the acx565akm panel,
and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the acx565akm panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file. Pass
the panel_acx565akm_data instance 'lcd_data' to omap_dss_device instead of
passing the gpio number in omap_dss_device's reset_gpio.
Add the gpio information to panel_acx565akm_data so that it's passed to the
panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-rx51-video.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c
index 46f4fc9..9e8afa4 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -16,6 +16,8 @@
#include <linux/mm.h>
#include <asm/mach-types.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
+
#include <linux/platform_data/spi-omap2-mcspi.h>
#include "board-rx51.h"
@@ -26,25 +28,16 @@
#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
-static int rx51_lcd_enable(struct omap_dss_device *dssdev)
-{
- gpio_set_value(dssdev->reset_gpio, 1);
- return 0;
-}
-
-static void rx51_lcd_disable(struct omap_dss_device *dssdev)
-{
- gpio_set_value(dssdev->reset_gpio, 0);
-}
+static struct panel_acx565akm_data lcd_data = {
+ .reset_gpio = RX51_LCD_RESET_GPIO,
+};
static struct omap_dss_device rx51_lcd_device = {
.name = "lcd",
.driver_name = "panel-acx565akm",
.type = OMAP_DISPLAY_TYPE_SDI,
.phy.sdi.datapairs = 2,
- .reset_gpio = RX51_LCD_RESET_GPIO,
- .platform_enable = rx51_lcd_enable,
- .platform_disable = rx51_lcd_disable,
+ .data = &lcd_data,
};
static struct omap_dss_device rx51_tv_device = {
@@ -75,13 +68,8 @@ static int __init rx51_video_init(void)
return 0;
}
- if (gpio_request_one(RX51_LCD_RESET_GPIO, GPIOF_OUT_INIT_HIGH,
- "LCD ACX565AKM reset")) {
- pr_err("%s failed to get LCD Reset GPIO\n", __func__);
- return 0;
- }
-
omap_display_init(&rx51_dss_board_info);
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 18/33] OMAPDSS: nec-nl8048 panel: handle gpios ins panel driver
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The nec-nl8048hl11-01 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.
Create a platform data struct for the panel, this contains the gpio numbers
used by the panel driver, this struct will be passed to the panel driver as
platform data. The driver will request and configure these gpios rather than
leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 45 +++++++++++++++-----
include/video/omap-panel-data.h | 10 +++++
2 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index c197927..3b85e2a 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -20,8 +20,10 @@
#include <linux/delay.h>
#include <linux/spi/spi.h>
#include <linux/fb.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
#define LCD_XRES 800
#define LCD_YRES 480
@@ -31,9 +33,6 @@
*/
#define LCD_PIXEL_CLOCK 23800
-struct nec_8048_data {
-};
-
static const struct {
unsigned char addr;
unsigned char dat;
@@ -82,30 +81,46 @@ static struct omap_video_timings nec_8048_panel_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
};
+static inline struct panel_nec_nl8048_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_nec_nl8048_data *) dssdev->data;
+}
+
static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
{
- struct nec_8048_data *necd;
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
+ int r;
+
+ if (!pd)
+ return -EINVAL;
dssdev->panel.timings = nec_8048_panel_timings;
- necd = kzalloc(sizeof(*necd), GFP_KERNEL);
- if (!necd)
- return -ENOMEM;
+ if (gpio_is_valid(pd->qvga_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->qvga_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd QVGA");
+ if (r)
+ return r;
+ }
- dev_set_drvdata(&dssdev->dev, necd);
+ if (gpio_is_valid(pd->res_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->res_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RES");
+ if (r)
+ return r;
+ }
return 0;
}
static void nec_8048_panel_remove(struct omap_dss_device *dssdev)
{
- struct nec_8048_data *necd = dev_get_drvdata(&dssdev->dev);
-
- kfree(necd);
}
static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
int r;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
@@ -124,6 +139,9 @@ static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ if (gpio_is_valid(pd->res_gpio))
+ gpio_set_value_cansleep(pd->res_gpio, 1);
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -133,9 +151,14 @@ err0:
static void nec_8048_panel_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
+
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ if (gpio_is_valid(pd->res_gpio))
+ gpio_set_value_cansleep(pd->res_gpio, 0);
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 6faf0c7..e7698e2 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -125,4 +125,14 @@ struct panel_acx565akm_data {
int reset_gpio;
};
+/**
+ * nec nl8048 panel driver configuration data
+ * @res_gpio: reset signal
+ * @qvga_gpio: selection for resolution(QVGA/WVGA)
+ */
+struct panel_nec_nl8048_data {
+ int res_gpio;
+ int qvga_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 19/33] arm: omap: board-zoom: use NEC panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The zoom board file currently requests gpios required by the nec-nl8048hl11-01
dpi panel, and provides dummy platform_enable/disable callbacks.
gpio request and configuration have been moved to the nec-nl8048hl11-01 panel
driver itself and shouldn't be done in the board files.
Remove the gpio requests and the platform callbacks from the board file. Add the
gpio information to panel_nec_nl8048_data so that it's passed to the panel
driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-zoom-display.c | 38 ++++++++++--------------------
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-display.c b/arch/arm/mach-omap2/board-zoom-display.c
index 4717ed5..bd79082 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -16,8 +16,9 @@
#include <linux/spi/spi.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <video/omapdss.h>
-#include "board-zoom.h"
+#include <video/omap-panel-data.h>
+#include "board-zoom.h"
#include "soc.h"
#include "common.h"
@@ -25,30 +26,11 @@
#define LCD_PANEL_RESET_GPIO_PILOT 55
#define LCD_PANEL_QVGA_GPIO 56
-static struct gpio zoom_lcd_gpios[] __initdata = {
- { -EINVAL, GPIOF_OUT_INIT_HIGH, "lcd reset" },
- { LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "lcd qvga" },
+static struct panel_nec_nl8048_data zoom_lcd_data = {
+ /* res_gpio filled in code */
+ .qvga_gpio = LCD_PANEL_QVGA_GPIO,
};
-static void __init zoom_lcd_panel_init(void)
-{
- zoom_lcd_gpios[0].gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
- LCD_PANEL_RESET_GPIO_PROD :
- LCD_PANEL_RESET_GPIO_PILOT;
-
- if (gpio_request_array(zoom_lcd_gpios, ARRAY_SIZE(zoom_lcd_gpios)))
- pr_err("%s: Failed to get LCD GPIOs.\n", __func__);
-}
-
-static int zoom_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void zoom_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
-}
-
/*
* PWMA/B register offsets (TWL4030_MODULE_PWMA)
*/
@@ -107,8 +89,7 @@ static struct omap_dss_device zoom_lcd_device = {
.driver_name = "NEC_8048_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
- .platform_enable = zoom_panel_enable_lcd,
- .platform_disable = zoom_panel_disable_lcd,
+ .data = &zoom_lcd_data,
};
static struct omap_dss_device *zoom_dss_devices[] = {
@@ -121,6 +102,13 @@ static struct omap_dss_board_info zoom_dss_data = {
.default_device = &zoom_lcd_device,
};
+static void __init zoom_lcd_panel_init(void)
+{
+ zoom_lcd_data.res_gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
+ LCD_PANEL_RESET_GPIO_PROD :
+ LCD_PANEL_RESET_GPIO_PILOT;
+}
+
static struct omap2_mcspi_device_config dss_lcd_mcspi_config = {
.turbo_mode = 1,
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 20/33] OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The nec-nl8048 panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_nec_nl8048_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index 3b85e2a..1e0097d 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -133,18 +133,11 @@ static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
if (gpio_is_valid(pd->res_gpio))
gpio_set_value_cansleep(pd->res_gpio, 1);
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -159,9 +152,6 @@ static void nec_8048_panel_power_off(struct omap_dss_device *dssdev)
if (gpio_is_valid(pd->res_gpio))
gpio_set_value_cansleep(pd->res_gpio, 0);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 21/33] OMAPDSS: tpo-td043 panel: handle gpios in panel driver
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The tpo-td043mtea1 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.
Create a platform data struct for the panel, this contains the reset gpio
number used by the panel driver, this struct will be passed to the panel driver
as platform data. The driver will request and configure the reset gpio rather
than leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 36 ++++++++++++--------
include/video/omap-panel-data.h | 8 +++++
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 6b66439..c8244bc 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -18,6 +18,7 @@
#include <linux/slab.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
#define TPO_R02_MODE(x) ((x) & 7)
#define TPO_R02_MODE_800x480 7
@@ -275,9 +276,14 @@ static const struct omap_video_timings tpo_td043_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_tpo_td043_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_tpo_td043_data *) dssdev->data;
+}
+
static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
{
- int nreset_gpio = tpo_td043->nreset_gpio;
int r;
if (tpo_td043->powered_on)
@@ -290,8 +296,8 @@ static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
/* wait for panel to stabilize */
msleep(160);
- if (gpio_is_valid(nreset_gpio))
- gpio_set_value(nreset_gpio, 1);
+ if (gpio_is_valid(tpo_td043->nreset_gpio))
+ gpio_set_value(tpo_td043->nreset_gpio, 1);
tpo_td043_write(tpo_td043->spi, 2,
TPO_R02_MODE(tpo_td043->mode) | TPO_R02_NCLK_RISING);
@@ -308,16 +314,14 @@ static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
static void tpo_td043_power_off(struct tpo_td043_device *tpo_td043)
{
- int nreset_gpio = tpo_td043->nreset_gpio;
-
if (!tpo_td043->powered_on)
return;
tpo_td043_write(tpo_td043->spi, 3,
TPO_R03_VAL_STANDBY | TPO_R03_EN_PWM);
- if (gpio_is_valid(nreset_gpio))
- gpio_set_value(nreset_gpio, 0);
+ if (gpio_is_valid(tpo_td043->nreset_gpio))
+ gpio_set_value(tpo_td043->nreset_gpio, 0);
/* wait for at least 2 vsyncs before cutting off power */
msleep(50);
@@ -404,7 +408,7 @@ static void tpo_td043_disable(struct omap_dss_device *dssdev)
static int tpo_td043_probe(struct omap_dss_device *dssdev)
{
struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
+ struct panel_tpo_td043_data *pdata = get_panel_data(dssdev);
int ret = 0;
dev_dbg(&dssdev->dev, "probe\n");
@@ -414,6 +418,11 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
return -ENODEV;
}
+ if (!pdata)
+ return -EINVAL;
+
+ tpo_td043->nreset_gpio = pdata->nreset_gpio;
+
dssdev->panel.timings = tpo_td043_timings;
dssdev->ctrl.pixel_size = 24;
@@ -427,9 +436,10 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
goto fail_regulator;
}
- if (gpio_is_valid(nreset_gpio)) {
- ret = gpio_request_one(nreset_gpio, GPIOF_OUT_INIT_LOW,
- "lcd reset");
+ if (gpio_is_valid(tpo_td043->nreset_gpio)) {
+ ret = devm_gpio_request_one(&dssdev->dev,
+ tpo_td043->nreset_gpio, GPIOF_OUT_INIT_LOW,
+ "lcd reset");
if (ret < 0) {
dev_err(&dssdev->dev, "couldn't request reset GPIO\n");
goto fail_gpio_req;
@@ -452,14 +462,11 @@ fail_regulator:
static void tpo_td043_remove(struct omap_dss_device *dssdev)
{
struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
dev_dbg(&dssdev->dev, "remove\n");
sysfs_remove_group(&dssdev->dev.kobj, &tpo_td043_attr_group);
regulator_put(tpo_td043->vcc_reg);
- if (gpio_is_valid(nreset_gpio))
- gpio_free(nreset_gpio);
}
static void tpo_td043_set_timings(struct omap_dss_device *dssdev,
@@ -519,7 +526,6 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
return -ENOMEM;
tpo_td043->spi = spi;
- tpo_td043->nreset_gpio = dssdev->reset_gpio;
dev_set_drvdata(&spi->dev, tpo_td043);
dev_set_drvdata(&dssdev->dev, tpo_td043);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index e7698e2..7cac89e 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -135,4 +135,12 @@ struct panel_nec_nl8048_data {
int qvga_gpio;
};
+/**
+ * tpo td043 panel driver configuration data
+ * @nreset_gpio: reset signal
+ */
+struct panel_tpo_td043_data {
+ int nreset_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 22/33] arm: omap: board-omap3pandora: use tpo panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The omap3pandora board file currently passes the reset gpio number to the
tpo-td043mtea1 panel driver via the reset_gpio field in omap_dss_device.
Platform related information should be passed via the panel driver's platform
data struct.
Add the reset gpio information to panel_tpo_td043_data so that it's passed to
the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-omap3pandora.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index a53a668..ddd6322 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -43,6 +43,7 @@
#include "common.h"
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/mtd-nand-omap2.h>
#include "mux.h"
@@ -229,12 +230,16 @@ static struct twl4030_keypad_data pandora_kp_data = {
.rep = 1,
};
+static struct panel_tpo_td043_data lcd_data = {
+ .nreset_gpio = 157,
+};
+
static struct omap_dss_device pandora_lcd_device = {
.name = "lcd",
.driver_name = "tpo_td043mtea1_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
- .reset_gpio = 157,
+ .data = &lcd_data,
};
static struct omap_dss_device pandora_tv_device = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 23/33] OMAPDSS: tpo-td043: remove platform_enable/disable callbacks
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The tpo-td043 panel driver now manages the gpios required to configure the panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_tpo_td043_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the platform_enable/disable
ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index c8244bc..24bb0ff 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -348,12 +348,6 @@ static int tpo_td043_enable_dss(struct omap_dss_device *dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
/*
* If we are resuming from system suspend, SPI clocks might not be
* enabled yet, so we'll program the LCD from SPI PM resume callback.
@@ -380,9 +374,6 @@ static void tpo_td043_disable_dss(struct omap_dss_device *dssdev)
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
if (!tpo_td043->spi_suspended)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 24/33] OMAPDSS: picodlp panel: handle gpio data in panel driver
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The picodlp panel driver leaves gpio requests to the platform's board file.
These should happen in the panel driver itself.
A platform data struct called picodlp_panel_data already exists to hold gpio
numbers and other platform data. Request all the gpios in the panel driver so
that the board files which use the the panel don't need to do it.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-picodlp.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c b/drivers/video/omap2/displays/panel-picodlp.c
index 56d536c..bc8ac77 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -423,10 +423,13 @@ static int picodlp_panel_probe(struct omap_dss_device *dssdev)
struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
struct i2c_adapter *adapter;
struct i2c_client *picodlp_i2c_client;
- int picodlp_adapter_id;
+ int r, picodlp_adapter_id;
dssdev->panel.timings = pico_ls_timings;
+ if (!picodlp_pdata)
+ return -EINVAL;
+
picod = devm_kzalloc(&dssdev->dev, sizeof(*picod), GFP_KERNEL);
if (!picod)
return -ENOMEM;
@@ -452,6 +455,22 @@ static int picodlp_panel_probe(struct omap_dss_device *dssdev)
dev_set_drvdata(&dssdev->dev, picod);
+ if (gpio_is_valid(picodlp_pdata->emu_done_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev,
+ picodlp_pdata->emu_done_gpio,
+ GPIOF_IN, "DLP EMU DONE");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(picodlp_pdata->pwrgood_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev,
+ picodlp_pdata->pwrgood_gpio,
+ GPIOF_OUT_INIT_LOW, "DLP PWRGOOD");
+ if (r)
+ return r;
+ }
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 25/33] arm: omap: dss-common: use picodlp panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The dss-common file currently requests gpios required by the picodlp DPI
panel on the 4430sdp/blaze board. It also requests DISPLAY_SEL_GPIO and
DLP_POWER_ON_GPIO gpios which are board specific gpios to switch between lcd2
panel and picodlp, and setting intermediate power supplies for picodlp
respectively. These gpios are toggled through platform_enable/disable functions
called by the picodlp driver.
Remove the gpio requests for the gpios which are already requested by the panel
driver, and remove the platform callback functions and set the platform specific
gpios in such a way that lcd2 panel is selected for the LCD2 overlay manager and
the power supplies for picodlp are disabled.
Note: We need to revisit this so that we can enable and switch to picodlp if
that's the only panel driver available for the LCD2 overlay manager.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 53 ++++++++++++--------------------------
1 file changed, 16 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 9c49bbe..b073e8b 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -177,45 +177,12 @@ static struct picodlp_panel_data sdp4430_picodlp_pdata = {
.pwrgood_gpio = 45,
};
-static void sdp4430_picodlp_init(void)
-{
- int r;
- const struct gpio picodlp_gpios[] = {
- {DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- "DLP POWER ON"},
- {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
- "DLP EMU DONE"},
- {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
- "DLP PWRGOOD"},
- };
-
- r = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
- if (r)
- pr_err("Cannot request PicoDLP GPIOs, error %d\n", r);
-}
-
-static int sdp4430_panel_enable_picodlp(struct omap_dss_device *dssdev)
-{
- gpio_set_value(DISPLAY_SEL_GPIO, 0);
- gpio_set_value(DLP_POWER_ON_GPIO, 1);
-
- return 0;
-}
-
-static void sdp4430_panel_disable_picodlp(struct omap_dss_device *dssdev)
-{
- gpio_set_value(DLP_POWER_ON_GPIO, 0);
- gpio_set_value(DISPLAY_SEL_GPIO, 1);
-}
-
static struct omap_dss_device sdp4430_picodlp_device = {
.name = "picodlp",
.driver_name = "picodlp_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.channel = OMAP_DSS_CHANNEL_LCD2,
- .platform_enable = sdp4430_panel_enable_picodlp,
- .platform_disable = sdp4430_panel_disable_picodlp,
.data = &sdp4430_picodlp_pdata,
};
@@ -232,17 +199,26 @@ static struct omap_dss_board_info sdp4430_dss_data = {
.default_device = &sdp4430_lcd_device,
};
+/*
+ * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
+ * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
+ * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
+ * selected by default
+ */
void __init omap_4430sdp_display_init(void)
{
int r;
- /* Enable LCD2 by default (instead of Pico DLP) */
r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
"display_sel");
if (r)
pr_err("%s: Could not get display_sel GPIO\n", __func__);
- sdp4430_picodlp_init();
+ r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ "DLP POWER ON");
+ if (r)
+ pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
+
omap_display_init(&sdp4430_dss_data);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -262,12 +238,15 @@ void __init omap_4430sdp_display_init_of(void)
{
int r;
- /* Enable LCD2 by default (instead of Pico DLP) */
r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
"display_sel");
if (r)
pr_err("%s: Could not get display_sel GPIO\n", __func__);
- sdp4430_picodlp_init();
+ r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ "DLP POWER ON");
+ if (r)
+ pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
+
omap_display_init(&sdp4430_dss_data);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 26/33] OMAPDSS: picodlp panel: remove platform_enable/disable callbacks
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The picodlp panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-picodlp.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c b/drivers/video/omap2/displays/panel-picodlp.c
index bc8ac77..62f2db0 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -354,12 +354,6 @@ static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
struct picodlp_data *picod = dev_get_drvdata(&dssdev->dev);
struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- return r;
- }
-
gpio_set_value(picodlp_pdata->pwrgood_gpio, 0);
msleep(1);
gpio_set_value(picodlp_pdata->pwrgood_gpio, 1);
@@ -398,9 +392,6 @@ static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
err:
omapdss_dpi_display_disable(dssdev);
err1:
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
return r;
}
@@ -412,9 +403,6 @@ static void picodlp_panel_power_off(struct omap_dss_device *dssdev)
gpio_set_value(picodlp_pdata->emu_done_gpio, 0);
gpio_set_value(picodlp_pdata->pwrgood_gpio, 0);
-
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
}
static int picodlp_panel_probe(struct omap_dss_device *dssdev)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The n8x0 panel driver leaves gpio configurations to the platform_enable and
disable calls in the platform's board file. These should happen in the panel
driver itself.
A platform data struct called panel_n8x0_data already exists to hold gpio
numbers and other platform data. However, the gpio requests are expected to be
done in the board file and not the panel driver.
Request all the gpios in the panel driver so that the board files which use
the the panel don't need to do it. This will help in removing the need for the
panel drivers to have platform related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-n8x0.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c b/drivers/video/omap2/displays/panel-n8x0.c
index 9c55c91..c146a3d 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -426,6 +426,7 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
{
struct panel_n8x0_data *bdata = get_board_data(dssdev);
struct panel_drv_data *ddata;
+ int r;
dev_dbg(&dssdev->dev, "probe\n");
@@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
+ if (gpio_is_valid(bdata->panel_reset)) {
+ r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
+ GPIOF_OUT_INIT_LOW, "PANEL RESET");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(bdata->ctrl_pwrdown)) {
+ r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
+ GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
+ if (r)
+ return r;
+ }
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 28/33] OMAPDSS: n8x0 panel: remove platform_enable/disable callbacks
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The n8x0 panel driver now manages the gpios required to configure the panel.
This was previously done in panel_n8x0_data's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_n8x0_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the platform_enable/disable
ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-n8x0.c | 12 ------------
include/video/omap-panel-data.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c b/drivers/video/omap2/displays/panel-n8x0.c
index c146a3d..f94ead6 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -295,12 +295,6 @@ static int n8x0_panel_power_on(struct omap_dss_device *dssdev)
gpio_direction_output(bdata->ctrl_pwrdown, 1);
- if (bdata->platform_enable) {
- r = bdata->platform_enable(dssdev);
- if (r)
- goto err_plat_en;
- }
-
omapdss_rfbi_set_size(dssdev, dssdev->panel.timings.x_res,
dssdev->panel.timings.y_res);
omapdss_rfbi_set_pixel_size(dssdev, dssdev->ctrl.pixel_size);
@@ -373,9 +367,6 @@ err_inv_panel:
err_inv_chip:
omapdss_rfbi_display_disable(dssdev);
err_rfbi_en:
- if (bdata->platform_disable)
- bdata->platform_disable(dssdev);
-err_plat_en:
gpio_direction_output(bdata->ctrl_pwrdown, 0);
return r;
}
@@ -392,9 +383,6 @@ static void n8x0_panel_power_off(struct omap_dss_device *dssdev)
send_display_off(spi);
send_sleep_in(spi);
- if (bdata->platform_disable)
- bdata->platform_disable(dssdev);
-
/*
* HACK: we should turn off the panel here, but there is some problem
* with the initialization sequence, and we fail to init the panel if we
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 7cac89e..84f332e 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -48,8 +48,6 @@ struct panel_generic_dpi_data {
* struct panel_n8x0_data - N800 panel driver configuration data
*/
struct panel_n8x0_data {
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
int panel_reset;
int ctrl_pwrdown;
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 29/33] arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC devices
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The omap_dss_device's platform_enable/disable callbacks don't do anything for
any of the boards. The platform calls from the VENC driver will also be removed
in the future. Remove these calls from the board which have a VENC device.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-3430sdp.c | 11 -----------
arch/arm/mach-omap2/board-am3517evm.c | 11 -----------
arch/arm/mach-omap2/board-cm-t35.c | 11 -----------
arch/arm/mach-omap2/board-omap3evm.c | 11 -----------
arch/arm/mach-omap2/board-omap3stalker.c | 11 -----------
5 files changed, 55 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 13f1431..717dd15 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -124,15 +124,6 @@ static void __init sdp3430_display_init(void)
}
-static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct panel_sharp_ls037v7dw01_data sdp3430_lcd_data = {
.resb_gpio = SDP3430_LCD_PANEL_ENABLE_GPIO,
.ini_gpio = -1,
@@ -167,8 +158,6 @@ static struct omap_dss_device sdp3430_tv_device = {
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = sdp3430_panel_enable_tv,
- .platform_disable = sdp3430_panel_disable_tv,
};
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index eb245a6..edb4cce 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -138,22 +138,11 @@ static struct omap_dss_device am3517_evm_lcd_device = {
.phy.dpi.data_lines = 16,
};
-static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void am3517_evm_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device am3517_evm_tv_device = {
.type = OMAP_DISPLAY_TYPE_VENC,
.name = "tv",
.driver_name = "venc",
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = am3517_evm_panel_enable_tv,
- .platform_disable = am3517_evm_panel_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 563d5ab..cb3b078 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -189,15 +189,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
.num_gpios = 2,
@@ -233,8 +224,6 @@ static struct omap_dss_device cm_t35_tv_device = {
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = cm_t35_panel_enable_tv,
- .platform_disable = cm_t35_panel_disable_tv,
};
static struct omap_dss_device *cm_t35_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index dfb5e1b..a471476 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -201,22 +201,11 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.data = &omap3_evm_lcd_data,
};
-static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void omap3_evm_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device omap3_evm_tv_device = {
.name = "tv",
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = omap3_evm_enable_tv,
- .platform_disable = omap3_evm_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 621ace1..8f1b0a1 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -93,15 +93,6 @@ static void __init omap3_stalker_display_init(void)
return;
}
-static int omap3_stalker_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void omap3_stalker_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device omap3_stalker_tv_device = {
.name = "tv",
.driver_name = "venc",
@@ -111,8 +102,6 @@ static struct omap_dss_device omap3_stalker_tv_device = {
#elif defined(CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE)
.u.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
#endif
- .platform_enable = omap3_stalker_enable_tv,
- .platform_disable = omap3_stalker_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 30/33] OMAPDSS: VENC: remove platform_enable/disable calls
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The platform_enable/disable callbacks in board files for VENC omap_dss_device
instances don't do anything. Hence, we can remove these callbacks from the VENC
driver.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/venc.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 006caf3..1598d27 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -519,10 +519,6 @@ int omapdss_venc_display_enable(struct omap_dss_device *dssdev)
goto err0;
}
- if (dssdev->platform_enable)
- dssdev->platform_enable(dssdev);
-
-
r = venc_power_on(dssdev);
if (r)
goto err1;
@@ -533,8 +529,6 @@ int omapdss_venc_display_enable(struct omap_dss_device *dssdev)
return 0;
err1:
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
omap_dss_stop_device(dssdev);
err0:
mutex_unlock(&venc.venc_lock);
@@ -551,9 +545,6 @@ void omapdss_venc_display_disable(struct omap_dss_device *dssdev)
omap_dss_stop_device(dssdev);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
mutex_unlock(&venc.venc_lock);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 31/33] OMAPDSS: remove platform_enable/disable callbacks from omap_dss_device
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
None of the omapdss panel drivers call platform_enable/disable callbacks, and
none of the omap board files define these callbacks for any omap_dss_device.
Hence these callbacks can be removed form the omap_dss_device struct.
Signed-off-by: Archit Taneja <archit@ti.com>
---
include/video/omapdss.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index f0b65a5..e1ebb48 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -650,10 +650,6 @@ struct omap_dss_device {
enum omap_dss_display_state state;
enum omap_dss_audio_state audio_state;
-
- /* platform specific */
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
};
struct omap_dss_hdmi_data
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 32/33] arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
gpio reset info is passed to the tfp410 panel driver via the panel's platform
data struct 'tfp410_platform_data'. The tfp driver doesn't use the reset_gpio
field in the omap4_panda_dvi_device struct. Remove this field.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index b073e8b..393aeef 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -52,7 +52,6 @@ static struct omap_dss_device omap4_panda_dvi_device = {
.driver_name = "tfp410",
.data = &omap4_dvi_panel,
.phy.dpi.data_lines = 24,
- .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
.channel = OMAP_DSS_CHANNEL_LCD2,
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 33/33] OMAPDSS: remove reset_gpio field from omap_dss_device
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 14:34 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The reset_gpio field isn't used by any panel driver to retrieve a reset gpio
number. All the panel drivers receive gpio data from their corresponding
platform_data structs. Remove the reset_gpio field.
Signed-off-by: Archit Taneja <archit@ti.com>
---
include/video/omapdss.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index e1ebb48..fe8672c 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -629,8 +629,6 @@ struct omap_dss_device {
struct rfbi_timings rfbi_timings;
} ctrl;
- int reset_gpio;
-
const char *name;
/* used to match device to driver */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
init functions in omap board files request panel specific gpios, and provide
functions which omapdss panel drivers call to enable or disable them.
Instead of the board files requesting these gpios, they should just pass the
platform specific data(like the gpio numbers), the panel should retrieve the
platform data and request the gpios. Doing this prevents the need of the panel
driver calling platform functions in board files.
Panel drivers have their own platform data struct, and the board files populate
these structs and pass the pointer to the 'data' field of omap_dss_device. This
work will make it easier for the panel drivers be more adaptable to the
DT model.
There is also removal of passing panel reset_gpio numbers through
omap_dss_device struct directly, reset gpios are passed through platform data
only.
Reference tree:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git for-3.9/remove_enable_disable_callbacks
Archit Taneja (32):
OMAPDSS: panels: keep platform data of all panels in a single header
arm: omap: board-2430: use generic dpi panel's gpio handling
arm: omap: board-devkit8000: use generic dpi panel's gpio handling
arm: omap: board-cm-t35: use generic dpi panel's gpio handling
arm: omap: board-apollon: use generic dpi panel's gpio handling
arm: omap: board-am3517: use generic dpi panel's gpio handling
arm: omap: board-ldp: use generic dpi panel's gpio handling
OMAPDSS: lb035q02: handle gpios in panel driver
arm: omap: board-overo: use lb035q02 dpi panel's gpio handling
OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks
OMAPDSS: generic dpi panel: remove platform_enable/disable ops from
platform_data
arm: omap: board-omap3evm: use sharp panel's gpio handling
arm: omap: board-sdp3430: use sharp panel's gpio handling
OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks
OMAPDSS: acx565akm panel: handle gpios in panel driver
arm: omap: board-rx-51: use acx565akm panel's gpio handling
OMAPDSS: nec-nl8048 panel: handle gpios ins panel driver
arm: omap: board-zoom: use NEC panel's gpio handling
OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks
OMAPDSS: tpo-td043 panel: handle gpios in panel driver
arm: omap: board-omap3pandora: use tpo panel's gpio handling
OMAPDSS: tpo-td043: remove platform_enable/disable callbacks
OMAPDSS: picodlp panel: handle gpio data in panel driver
arm: omap: dss-common: use picodlp panel's gpio handling
OMAPDSS: picodlp panel: remove platform_enable/disable callbacks
OMAPDSS: n8x0 panel: handle gpio data in panel driver
OMAPDSS: n8x0 panel: remove platform_enable/disable callbacks
arm: omap boards: Remove unnecessary platform_enable/disable
callbacks for VENC devices
OMAPDSS: VENC: remove platform_enable/disable calls
OMAPDSS: remove platform_enable/disable callbacks from
omap_dss_device
arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device
OMAPDSS: remove reset_gpio field from omap_dss_device
Tomi Valkeinen (1):
OMAPDSS: generic dpi panel: handle gpios in panel driver
arch/arm/mach-omap2/board-2430sdp.c | 45 +-----
arch/arm/mach-omap2/board-3430sdp.c | 55 +++-----
arch/arm/mach-omap2/board-am3517evm.c | 77 +----------
arch/arm/mach-omap2/board-apollon.c | 11 +-
arch/arm/mach-omap2/board-cm-t35.c | 60 +-------
arch/arm/mach-omap2/board-devkit8000.c | 30 +---
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c | 63 ++-------
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/board-omap3evm.c | 72 +++-------
arch/arm/mach-omap2/board-omap3pandora.c | 7 +-
arch/arm/mach-omap2/board-omap3stalker.c | 14 +-
arch/arm/mach-omap2/board-overo.c | 61 ++-------
arch/arm/mach-omap2/board-rx51-video.c | 26 +---
arch/arm/mach-omap2/board-zoom-display.c | 38 ++----
arch/arm/mach-omap2/dss-common.c | 58 +++-----
drivers/video/omap2/displays/panel-acx565akm.c | 48 +++++--
drivers/video/omap2/displays/panel-generic-dpi.c | 33 +++--
.../omap2/displays/panel-lgphilips-lb035q02.c | 44 ++++--
drivers/video/omap2/displays/panel-n8x0.c | 29 ++--
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 53 ++++---
drivers/video/omap2/displays/panel-picodlp.c | 35 +++--
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 78 ++++++++---
drivers/video/omap2/displays/panel-taal.c | 2 +-
drivers/video/omap2/displays/panel-tfp410.c | 2 +-
.../video/omap2/displays/panel-tpo-td043mtea1.c | 45 +++---
drivers/video/omap2/dss/venc.c | 9 --
include/video/omap-panel-data.h | 144 ++++++++++++++++++++
include/video/omap-panel-generic-dpi.h | 37 -----
include/video/omap-panel-n8x0.h | 13 --
include/video/omap-panel-nokia-dsi.h | 32 -----
include/video/omap-panel-picodlp.h | 23 ----
include/video/omap-panel-tfp410.h | 35 -----
include/video/omapdss.h | 6 -
35 files changed, 528 insertions(+), 763 deletions(-)
create mode 100644 include/video/omap-panel-data.h
delete mode 100644 include/video/omap-panel-generic-dpi.h
delete mode 100644 include/video/omap-panel-n8x0.h
delete mode 100644 include/video/omap-panel-nokia-dsi.h
delete mode 100644 include/video/omap-panel-picodlp.h
delete mode 100644 include/video/omap-panel-tfp410.h
--
1.7.9.5
^ permalink raw reply [flat|nested] 134+ messages in thread
* [PATCH 01/33] OMAPDSS: panels: keep platform data of all panels in a single header
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
Structs for platform data of omapdss panels are found in headers in the
'include/video/' path. Board files populate these structs with platform
specific values, and the panel driver uses these to configure the panel.
Currently, each panel has it's own header in the above path. Move all the
omapdss panel platform data structs to a single header omap-panel-data.h.
This is useful because:
- All other omapdss panel drivers will be modified to use platform data. This
would lead to a lot of panel headers usable only by omapdss. A lot of these
platform data structs are trivial, and don't really need a separate header.
- Platform data would be eventually removed, and platform information would be
passed via device tree. Therefore, omapdss panel platform data structs are
temporary, and will be easier to remove if they are all in the same header.
- All board files will have to include the same header to configure a panel's
platform data, that makes the board files more consistent.
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-2430sdp.c | 2 +-
arch/arm/mach-omap2/board-3430sdp.c | 2 +-
arch/arm/mach-omap2/board-am3517evm.c | 3 +-
arch/arm/mach-omap2/board-apollon.c | 2 +-
arch/arm/mach-omap2/board-cm-t35.c | 3 +-
arch/arm/mach-omap2/board-devkit8000.c | 3 +-
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c | 2 +-
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/board-omap3evm.c | 2 +-
arch/arm/mach-omap2/board-omap3stalker.c | 3 +-
arch/arm/mach-omap2/board-overo.c | 3 +-
arch/arm/mach-omap2/dss-common.c | 4 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 2 +-
drivers/video/omap2/displays/panel-n8x0.c | 2 +-
drivers/video/omap2/displays/panel-picodlp.c | 2 +-
drivers/video/omap2/displays/panel-taal.c | 2 +-
drivers/video/omap2/displays/panel-tfp410.c | 2 +-
include/video/omap-panel-data.h | 101 ++++++++++++++++++++++
include/video/omap-panel-generic-dpi.h | 37 --------
include/video/omap-panel-n8x0.h | 13 ---
include/video/omap-panel-nokia-dsi.h | 32 -------
include/video/omap-panel-picodlp.h | 23 -----
include/video/omap-panel-tfp410.h | 35 --------
25 files changed, 120 insertions(+), 166 deletions(-)
create mode 100644 include/video/omap-panel-data.h
delete mode 100644 include/video/omap-panel-generic-dpi.h
delete mode 100644 include/video/omap-panel-n8x0.h
delete mode 100644 include/video/omap-panel-nokia-dsi.h
delete mode 100644 include/video/omap-panel-picodlp.h
delete mode 100644 include/video/omap-panel-tfp410.h
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 4815ea6..13a1a3b 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -37,7 +37,7 @@
#include "gpmc-smc91x.h"
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
#include "mux.h"
#include "hsmmc.h"
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..fb75a81 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -33,7 +33,7 @@
#include "common.h"
#include <linux/omap-dma.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include "gpmc.h"
#include "gpmc-smc91x.h"
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index f81a303..2988049 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,8 +35,7 @@
#include "common.h"
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include "am35xx-emac.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c
index 5d0a61f..d2a83a8 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -38,7 +38,7 @@
#include "gpmc.h"
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
#include "mux.h"
#include "control.h"
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index b3102c2..f940a79 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -40,8 +40,7 @@
#include <linux/platform_data/mtd-nand-omap2.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include "common.h"
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 12865af..019b212 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -42,8 +42,7 @@
#include "gpmc.h"
#include <linux/platform_data/mtd-nand-omap2.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <linux/input/matrix_keypad.h>
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 3be1311..88d1b5b 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -34,7 +34,7 @@
#include <asm/mach/map.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
#include "common.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 0f24cb8..810e168 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -30,7 +30,7 @@
#include <asm/mach/arch.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/mtd-onenand-omap2.h>
#include "common.h"
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 0869f4f..68e56f1 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -40,7 +40,7 @@
#include "gpmc-smsc911x.h"
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
#include "board-flash.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 22c483d..8d357ce 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -40,7 +40,7 @@
#include <asm/mach/flash.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/mtd-nand-omap2.h>
#include "common.h"
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 3985f35..335127d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -50,7 +50,7 @@
#include "common.h"
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include "soc.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 53a6cbc..621ace1 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -43,8 +43,7 @@
#include "gpmc.h"
#include <linux/platform_data/mtd-nand-omap2.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index c8fde3e..bf6b2ce 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -46,8 +46,7 @@
#include <asm/mach/map.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
#include "common.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 4be5cfc..9c49bbe 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -27,9 +27,7 @@
#include <linux/gpio.h>
#include <video/omapdss.h>
-#include <video/omap-panel-tfp410.h>
-#include <video/omap-panel-nokia-dsi.h>
-#include <video/omap-panel-picodlp.h>
+#include <video/omap-panel-data.h>
#include "soc.h"
#include "dss-common.h"
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index 6cb2fe0..d8d0cd5 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -35,7 +35,7 @@
#include <linux/slab.h>
#include <video/omapdss.h>
-#include <video/omap-panel-generic-dpi.h>
+#include <video/omap-panel-data.h>
struct panel_config {
struct omap_video_timings timings;
diff --git a/drivers/video/omap2/displays/panel-n8x0.c b/drivers/video/omap2/displays/panel-n8x0.c
index b750480..9c55c91 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -8,7 +8,7 @@
#include <linux/fb.h>
#include <video/omapdss.h>
-#include <video/omap-panel-n8x0.h>
+#include <video/omap-panel-data.h>
#define BLIZZARD_REV_CODE 0x00
#define BLIZZARD_CONFIG 0x02
diff --git a/drivers/video/omap2/displays/panel-picodlp.c b/drivers/video/omap2/displays/panel-picodlp.c
index 3864299..56d536c 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -31,7 +31,7 @@
#include <linux/gpio.h>
#include <video/omapdss.h>
-#include <video/omap-panel-picodlp.h>
+#include <video/omap-panel-data.h>
#include "panel-picodlp.h"
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index a32407a..031d406 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -33,7 +33,7 @@
#include <linux/mutex.h>
#include <video/omapdss.h>
-#include <video/omap-panel-nokia-dsi.h>
+#include <video/omap-panel-data.h>
#include <video/mipi_display.h>
/* DSI Virtual channel. Hardcoded for now. */
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index 8281baa..a1dba868 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -24,7 +24,7 @@
#include <linux/gpio.h>
#include <drm/drm_edid.h>
-#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-data.h>
static const struct omap_video_timings tfp410_default_timings = {
.x_res = 640,
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
new file mode 100644
index 0000000..e8e30f9
--- /dev/null
+++ b/include/video/omap-panel-data.h
@@ -0,0 +1,101 @@
+/*
+ * Header containing platform_data structs for omap panels
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ * Archit Taneja <archit@ti.com>
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Mayuresh Janorkar <mayur@ti.com>
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu <bryan.wu@canonical.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __OMAP_PANEL_DATA_H
+#define __OMAP_PANEL_DATA_H
+
+struct omap_dss_device;
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+/**
+ * struct panel_n8x0_data - N800 panel driver configuration data
+ */
+struct panel_n8x0_data {
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+ int panel_reset;
+ int ctrl_pwrdown;
+};
+
+/**
+ * struct nokia_dsi_panel_data - Nokia DSI panel driver configuration data
+ * @name: panel name
+ * @use_ext_te: use external TE
+ * @ext_te_gpio: external TE GPIO
+ * @esd_interval: interval of ESD checks, 0 = disabled (ms)
+ * @ulps_timeout: time to wait before entering ULPS, 0 = disabled (ms)
+ * @use_dsi_backlight: true if panel uses DSI command to control backlight
+ * @pin_config: DSI pin configuration
+ */
+
+struct nokia_dsi_panel_data {
+ const char *name;
+
+ int reset_gpio;
+
+ bool use_ext_te;
+ int ext_te_gpio;
+
+ unsigned esd_interval;
+ unsigned ulps_timeout;
+
+ bool use_dsi_backlight;
+
+ struct omap_dsi_pin_config pin_config;
+};
+
+/**
+ * struct picodlp_panel_data - picodlp panel driver configuration data
+ * @picodlp_adapter_id: i2c_adapter number for picodlp
+ */
+struct picodlp_panel_data {
+ int picodlp_adapter_id;
+ int emu_done_gpio;
+ int pwrgood_gpio;
+};
+
+/**
+ * struct tfp410_platform_data - tfp410 panel driver configuration data
+ * @i2c_bus_num: i2c bus id for the panel
+ * @power_down_gpio: gpio number for PD pin (or -1 if not available)
+ */
+struct tfp410_platform_data {
+ int i2c_bus_num;
+ int power_down_gpio;
+};
+
+#endif /* __OMAP_PANEL_DATA_H */
diff --git a/include/video/omap-panel-generic-dpi.h b/include/video/omap-panel-generic-dpi.h
deleted file mode 100644
index 127e3f2..0000000
--- a/include/video/omap-panel-generic-dpi.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Header for generic DPI panel driver
- *
- * Copyright (C) 2010 Canonical Ltd.
- * Author: Bryan Wu <bryan.wu@canonical.com>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#ifndef __OMAP_PANEL_GENERIC_DPI_H
-#define __OMAP_PANEL_GENERIC_DPI_H
-
-struct omap_dss_device;
-
-/**
- * struct panel_generic_dpi_data - panel driver configuration data
- * @name: panel name
- * @platform_enable: platform specific panel enable function
- * @platform_disable: platform specific panel disable function
- */
-struct panel_generic_dpi_data {
- const char *name;
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
-};
-
-#endif /* __OMAP_PANEL_GENERIC_DPI_H */
diff --git a/include/video/omap-panel-n8x0.h b/include/video/omap-panel-n8x0.h
deleted file mode 100644
index 9cc69c8..0000000
--- a/include/video/omap-panel-n8x0.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __OMAP_PANEL_N8X0_H
-#define __OMAP_PANEL_N8X0_H
-
-struct omap_dss_device;
-
-struct panel_n8x0_data {
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
- int panel_reset;
- int ctrl_pwrdown;
-};
-
-#endif
diff --git a/include/video/omap-panel-nokia-dsi.h b/include/video/omap-panel-nokia-dsi.h
deleted file mode 100644
index 04219a2..0000000
--- a/include/video/omap-panel-nokia-dsi.h
+++ /dev/null
@@ -1,32 +0,0 @@
-#ifndef __OMAP_NOKIA_DSI_PANEL_H
-#define __OMAP_NOKIA_DSI_PANEL_H
-
-struct omap_dss_device;
-
-/**
- * struct nokia_dsi_panel_data - Nokia DSI panel driver configuration
- * @name: panel name
- * @use_ext_te: use external TE
- * @ext_te_gpio: external TE GPIO
- * @esd_interval: interval of ESD checks, 0 = disabled (ms)
- * @ulps_timeout: time to wait before entering ULPS, 0 = disabled (ms)
- * @use_dsi_backlight: true if panel uses DSI command to control backlight
- * @pin_config: DSI pin configuration
- */
-struct nokia_dsi_panel_data {
- const char *name;
-
- int reset_gpio;
-
- bool use_ext_te;
- int ext_te_gpio;
-
- unsigned esd_interval;
- unsigned ulps_timeout;
-
- bool use_dsi_backlight;
-
- struct omap_dsi_pin_config pin_config;
-};
-
-#endif /* __OMAP_NOKIA_DSI_PANEL_H */
diff --git a/include/video/omap-panel-picodlp.h b/include/video/omap-panel-picodlp.h
deleted file mode 100644
index 1c342ef..0000000
--- a/include/video/omap-panel-picodlp.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * panel data for picodlp panel
- *
- * Copyright (C) 2011 Texas Instruments
- *
- * Author: Mayuresh Janorkar <mayur@ti.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#ifndef __PANEL_PICODLP_H
-#define __PANEL_PICODLP_H
-/**
- * struct : picodlp panel data
- * picodlp_adapter_id: i2c_adapter number for picodlp
- */
-struct picodlp_panel_data {
- int picodlp_adapter_id;
- int emu_done_gpio;
- int pwrgood_gpio;
-};
-#endif /* __PANEL_PICODLP_H */
diff --git a/include/video/omap-panel-tfp410.h b/include/video/omap-panel-tfp410.h
deleted file mode 100644
index aef35e4..0000000
--- a/include/video/omap-panel-tfp410.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Header for TFP410 chip driver
- *
- * Copyright (C) 2011 Texas Instruments Inc
- * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#ifndef __OMAP_PANEL_TFP410_H
-#define __OMAP_PANEL_TFP410_H
-
-struct omap_dss_device;
-
-/**
- * struct tfp410_platform_data - panel driver configuration data
- * @i2c_bus_num: i2c bus id for the panel
- * @power_down_gpio: gpio number for PD pin (or -1 if not available)
- */
-struct tfp410_platform_data {
- int i2c_bus_num;
- int power_down_gpio;
-};
-
-#endif /* __OMAP_PANEL_TFP410_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 02/33] OMAPDSS: generic dpi panel: handle gpios in panel driver
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
The generic dpi panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Add a generic way of passing gpio information to the generic dpi panel driver
via it's platform_data. This information includes the number of gpios used by
the panel, the gpio number and logic level (active high/low) for each gpio. This
gpio data will be used by the driver to request and configure the gpios required
by the panel.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++++++++++++++++++++--
include/video/omap-panel-data.h | 7 ++++++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index d8d0cd5..4a12db6 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -33,6 +33,7 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -557,7 +558,7 @@ static inline struct panel_generic_dpi_data
static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
{
- int r;
+ int r, i;
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
struct panel_config *panel_config = drv_data->panel_config;
@@ -582,6 +583,11 @@ static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 0 : 1);
+ }
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -594,10 +600,16 @@ static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
struct panel_config *panel_config = drv_data->panel_config;
+ int i;
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ for (i = panel_data->num_gpios - 1; i >= 0; --i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 1 : 0);
+ }
+
if (panel_data->platform_disable)
panel_data->platform_disable(dssdev);
@@ -613,7 +625,7 @@ static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_config *panel_config = NULL;
struct panel_drv_data *drv_data = NULL;
- int i;
+ int i, r;
dev_dbg(&dssdev->dev, "probe\n");
@@ -630,6 +642,15 @@ static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
if (!panel_config)
return -EINVAL;
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->gpios[i],
+ panel_data->gpio_invert[i] ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ "panel gpio");
+ if (r)
+ return r;
+ }
+
dssdev->panel.timings = panel_config->timings;
drv_data = devm_kzalloc(&dssdev->dev, sizeof(*drv_data), GFP_KERNEL);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index e8e30f9..eec93f1 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -34,11 +34,18 @@ struct omap_dss_device;
* @name: panel name
* @platform_enable: platform specific panel enable function
* @platform_disable: platform specific panel disable function
+ * @num_gpios: number of gpios connected to panel
+ * @gpios: gpio numbers on the platform
+ * @gpio_invert: configure gpio as active high or low
*/
struct panel_generic_dpi_data {
const char *name;
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
+
+ int num_gpios;
+ int gpios[10];
+ bool gpio_invert[10];
};
/**
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 03/33] arm: omap: board-2430: use generic dpi panel's gpio handling
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The 2430sdp board file currently requests gpios required to configure the NEC
DPI panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-2430sdp.c | 43 +++++------------------------------
1 file changed, 6 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 13a1a3b..c888a58 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -107,24 +107,13 @@ static struct platform_device *sdp2430_devices[] __initdata = {
#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO 91
#define SDP2430_LCD_PANEL_ENABLE_GPIO 154
-static int sdp2430_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 1);
-
- return 0;
-}
-
-static void sdp2430_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 0);
- gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 0);
-}
-
static struct panel_generic_dpi_data sdp2430_panel_data = {
.name = "nec_nl2432dr22-11b",
- .platform_enable = sdp2430_panel_enable_lcd,
- .platform_disable = sdp2430_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ SDP2430_LCD_PANEL_ENABLE_GPIO,
+ SDP2430_LCD_PANEL_BACKLIGHT_GPIO,
+ },
};
static struct omap_dss_device sdp2430_lcd_device = {
@@ -145,26 +134,6 @@ static struct omap_dss_board_info sdp2430_dss_data = {
.default_device = &sdp2430_lcd_device,
};
-static void __init sdp2430_display_init(void)
-{
- int r;
-
- static struct gpio gpios[] __initdata = {
- { SDP2430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
- "LCD reset" },
- { SDP2430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW,
- "LCD Backlight" },
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- return;
- }
-
- omap_display_init(&sdp2430_dss_data);
-}
-
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
static struct omap_smc91x_platform_data board_smc91x_data = {
@@ -271,7 +240,7 @@ static void __init omap_2430sdp_init(void)
gpio_request_one(SECONDARY_LCD_GPIO, GPIOF_OUT_INIT_LOW,
"Secondary LCD backlight");
- sdp2430_display_init();
+ omap_display_init(&sdp2430_dss_data);
}
MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 04/33] arm: omap: board-devkit8000: use generic dpi panel's gpio handling
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The devkit8000 board file currently requests gpios required to configure the
innolux DPI panel, and provides platform_enable/disable callbacks to configure
them.
These tasks have been moved to the generic dpi panel driver itself and should
be removed from the board files.
Remove the gpio request and the platform callbacks from the board file.
Configure the gpio information in generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-devkit8000.c | 27 +++------------------------
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 019b212..ccef86d 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -102,19 +102,6 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(dssdev->reset_gpio))
- gpio_set_value_cansleep(dssdev->reset_gpio, 1);
- return 0;
-}
-
-static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(dssdev->reset_gpio))
- gpio_set_value_cansleep(dssdev->reset_gpio, 0);
-}
-
static struct regulator_consumer_supply devkit8000_vmmc1_supply[] = {
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
};
@@ -126,8 +113,7 @@ static struct regulator_consumer_supply devkit8000_vio_supply[] = {
static struct panel_generic_dpi_data lcd_panel = {
.name = "innolux_at070tn83",
- .platform_enable = devkit8000_panel_enable_lcd,
- .platform_disable = devkit8000_panel_disable_lcd,
+ /* gpios filled in code */
};
static struct omap_dss_device devkit8000_lcd_device = {
@@ -209,8 +195,6 @@ static struct gpio_led gpio_leds[];
static int devkit8000_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- int ret;
-
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
omap_hsmmc_late_init(mmc);
@@ -219,13 +203,8 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
/* TWL4030_GPIO_MAX + 0 is "LCD_PWREN" (out, active high) */
- devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
- ret = gpio_request_one(devkit8000_lcd_device.reset_gpio,
- GPIOF_OUT_INIT_LOW, "LCD_PWREN");
- if (ret < 0) {
- devkit8000_lcd_device.reset_gpio = -EINVAL;
- printk(KERN_ERR "Failed to request GPIO for LCD_PWRN\n");
- }
+ lcd_panel.num_gpios = 1;
+ lcd_panel.gpios[0] = gpio + TWL4030_GPIO_MAX + 0;
/* gpio + 7 is "DVI_PD" (out, active low) */
dvi_panel.power_down_gpio = gpio + 7;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The cm-t35 board file currently requests gpios required to configure the tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
enabled after a 50 millisecond delay. This code has been removed and is not
taken care of in the generic panel driver. The impact of this needs to be
tested. The panel's gpios are also not exported any more. Hence, they can't be
accessed via sysfs interface.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-cm-t35.c | 46 ++++--------------------------------
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index f940a79..563d5ab 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -189,32 +189,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int lcd_enabled;
-static int dvi_enabled;
-
-static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
- gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
-
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- lcd_enabled = 0;
-
- gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
-}
-
static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@ -226,8 +200,11 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
- .platform_enable = cm_t35_panel_enable_lcd,
- .platform_disable = cm_t35_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ CM_T35_LCD_BL_GPIO,
+ CM_T35_LCD_EN_GPIO
+ },
};
static struct omap_dss_device cm_t35_lcd_device = {
@@ -303,19 +280,6 @@ static void __init cm_t35_init_display(void)
spi_register_board_info(cm_t35_lcd_spi_board_info,
ARRAY_SIZE(cm_t35_lcd_spi_board_info));
- err = gpio_request_array(cm_t35_dss_gpios,
- ARRAY_SIZE(cm_t35_dss_gpios));
- if (err) {
- pr_err("CM-T35: failed to request DSS control GPIOs\n");
- return;
- }
-
- gpio_export(CM_T35_LCD_EN_GPIO, 0);
- gpio_export(CM_T35_LCD_BL_GPIO, 0);
-
- msleep(50);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
-
err = omap_display_init(&cm_t35_dss_data);
if (err) {
pr_err("CM-T35: failed to register DSS device\n");
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 06/33] arm: omap: board-apollon: use generic dpi panel's gpio handling
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The apollon board file currently configures the LCD_PWR_EN gpio by muxing the
corresponding pin to gpio 11, and configuring it in PULL UP mode.
Remove this muxing from the board file. Add the gpio information to generic dpi
panel's platform data so that it's passed to the panel driver. The panel driver
will take care of requesting and setting the LCD_PWR_EN gpio.
Note: This should be tested to ensure that setting the GPIO is equivalent to
configuring the GPIO in PULL UP mode. Also, this GPIO was just set once during
init, and never cleared, where as now the gpio will toggle everytime the panel
is disabled/enabled. The impact of this needs to be tested.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-apollon.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c
index d2a83a8..5cc957e 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -55,6 +55,8 @@
#define APOLLON_ETH_CS 1
#define APOLLON_ETHR_GPIO_IRQ 74
+#define APOLLON_LCD_PWR_EN 11
+
static struct mtd_partition apollon_partitions[] = {
{
.name = "X-Loader + U-Boot",
@@ -252,6 +254,10 @@ out:
static struct panel_generic_dpi_data apollon_panel_data = {
.name = "apollon",
+ .num_gpios = 1,
+ .gpios = {
+ APOLLON_LCD_PWR_EN,
+ },
};
static struct omap_dss_device apollon_lcd_device = {
@@ -306,9 +312,6 @@ static void __init omap_apollon_init(void)
/* REVISIT: where's the correct place */
omap_mux_init_signal("sys_nirq", OMAP_PULL_ENA | OMAP_PULL_UP);
- /* LCD PWR_EN */
- omap_mux_init_signal("mcbsp2_dr.gpio_11", OMAP_PULL_ENA | OMAP_PULL_UP);
-
/* Use Internal loop-back in MMC/SDIO Module Input Clock selection */
v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
v |= (1 << 24);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 07/33] arm: omap: board-am3517: use generic dpi panel's gpio handling
@ 2013-02-13 14:33 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:33 UTC (permalink / raw)
To: tomi.valkeinen
Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren, Vaibhav Hiremath
The am3517 board file currently requests gpios required to configure the sharp
lq DPI panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: It's not clear why the GPIOs were muxed as input signals in PULL down mode
in am3517_evm_display_init(). Also, only the LCD_PANEL_PWR was toggled in the
platform_enable/disable calls, the generic DPI panel driver will now toggle all
the three gpios on panel's disable/enable. We need to test if these changes to
see if they have any impact or not.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-am3517evm.c | 63 ++++-----------------------------
1 file changed, 6 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index 2988049..eb245a6 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -120,63 +120,14 @@ static int __init am3517_evm_i2c_init(void)
return 0;
}
-static int lcd_enabled;
-static int dvi_enabled;
-
-#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
- defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
-static struct gpio am3517_evm_dss_gpios[] __initdata = {
- /* GPIO 182 = LCD Backlight Power */
- { LCD_PANEL_BKLIGHT_PWR, GPIOF_OUT_INIT_HIGH, "lcd_backlight_pwr" },
- /* GPIO 181 = LCD Panel PWM */
- { LCD_PANEL_PWM, GPIOF_OUT_INIT_HIGH, "lcd bl enable" },
- /* GPIO 176 = LCD Panel Power enable pin */
- { LCD_PANEL_PWR, GPIOF_OUT_INIT_HIGH, "dvi enable" },
-};
-
-static void __init am3517_evm_display_init(void)
-{
- int r;
-
- omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_gpio(LCD_PANEL_BKLIGHT_PWR, OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_gpio(LCD_PANEL_PWM, OMAP_PIN_INPUT_PULLDOWN);
-
- r = gpio_request_array(am3517_evm_dss_gpios,
- ARRAY_SIZE(am3517_evm_dss_gpios));
- if (r) {
- printk(KERN_ERR "failed to get DSS panel control GPIOs\n");
- return;
- }
-
- printk(KERN_INFO "Display initialized successfully\n");
-}
-#else
-static void __init am3517_evm_display_init(void) {}
-#endif
-
-static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
- gpio_set_value(LCD_PANEL_PWR, 1);
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(LCD_PANEL_PWR, 0);
- lcd_enabled = 0;
-}
-
static struct panel_generic_dpi_data lcd_panel = {
.name = "sharp_lq",
- .platform_enable = am3517_evm_panel_enable_lcd,
- .platform_disable = am3517_evm_panel_disable_lcd,
+ .num_gpios = 3,
+ .gpios = {
+ LCD_PANEL_PWR,
+ LCD_PANEL_BKLIGHT_PWR,
+ LCD_PANEL_PWM,
+ },
};
static struct omap_dss_device am3517_evm_lcd_device = {
@@ -362,8 +313,6 @@ static void __init am3517_evm_init(void)
omap_mux_init_gpio(57, OMAP_PIN_OUTPUT);
usbhs_init(&usbhs_bdata);
am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
- /* DSS */
- am3517_evm_display_init();
/* RTC - S35390A */
am3517_evm_rtc_init();
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 08/33] arm: omap: board-ldp: use generic dpi panel's gpio handling
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The ldp board file currently requests gpios required to configure the NEC DPI
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Configure the gpio information in generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-ldp.c | 61 ++++++---------------------------------
1 file changed, 9 insertions(+), 52 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 68e56f1..c88d01a 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -180,34 +180,13 @@ static inline void __init ldp_init_smsc911x(void)
/* LCD */
-static int ldp_backlight_gpio;
-static int ldp_lcd_enable_gpio;
-
#define LCD_PANEL_RESET_GPIO 55
#define LCD_PANEL_QVGA_GPIO 56
-static int ldp_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(ldp_lcd_enable_gpio))
- gpio_direction_output(ldp_lcd_enable_gpio, 1);
- if (gpio_is_valid(ldp_backlight_gpio))
- gpio_direction_output(ldp_backlight_gpio, 1);
-
- return 0;
-}
-
-static void ldp_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(ldp_lcd_enable_gpio))
- gpio_direction_output(ldp_lcd_enable_gpio, 0);
- if (gpio_is_valid(ldp_backlight_gpio))
- gpio_direction_output(ldp_backlight_gpio, 0);
-}
-
static struct panel_generic_dpi_data ldp_panel_data = {
.name = "nec_nl2432dr22-11b",
- .platform_enable = ldp_panel_enable_lcd,
- .platform_disable = ldp_panel_disable_lcd,
+ .num_gpios = 4,
+ /* gpios filled in code */
};
static struct omap_dss_device ldp_lcd_device = {
@@ -230,41 +209,19 @@ static struct omap_dss_board_info ldp_dss_data = {
static void __init ldp_display_init(void)
{
- int r;
-
- static struct gpio gpios[] __initdata = {
- {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, "LCD RESET"},
- {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "LCD QVGA"},
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- return;
- }
+ ldp_panel_data.gpios[2] = LCD_PANEL_RESET_GPIO;
+ ldp_panel_data.gpios[3] = LCD_PANEL_QVGA_GPIO;
omap_display_init(&ldp_dss_data);
}
static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
{
- int r;
-
- struct gpio gpios[] = {
- {gpio + 7 , GPIOF_OUT_INIT_LOW, "LCD ENABLE"},
- {gpio + 15, GPIOF_OUT_INIT_LOW, "LCD BACKLIGHT"},
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- ldp_backlight_gpio = -EINVAL;
- ldp_lcd_enable_gpio = -EINVAL;
- return r;
- }
-
- ldp_backlight_gpio = gpio + 15;
- ldp_lcd_enable_gpio = gpio + 7;
+ ldp_panel_data.gpios[0] = gpio + 7;
+ ldp_panel_data.gpio_invert[0] = true;
+
+ ldp_panel_data.gpios[1] = gpio + 15;
+ ldp_panel_data.gpio_invert[1] = true;
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 09/33] OMAPDSS: lb035q02: handle gpios in panel driver
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The lgphilips panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Use the platform data as defined for generic dpi panels to pass gpio information
to the lgphilips driver.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 38 +++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
index 8effea8..63cd8857 100644
--- a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
@@ -20,8 +20,10 @@
#include <linux/delay.h>
#include <linux/spi/spi.h>
#include <linux/mutex.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
struct lb035q02_data {
struct mutex lock;
@@ -48,9 +50,16 @@ static struct omap_video_timings lb035q02_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_generic_dpi_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_generic_dpi_data *) dssdev->data;
+}
+
static int lb035q02_panel_power_on(struct omap_dss_device *dssdev)
{
- int r;
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
+ int r, i;
if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
return 0;
@@ -68,6 +77,11 @@ static int lb035q02_panel_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 0 : 1);
+ }
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -77,9 +91,17 @@ err0:
static void lb035q02_panel_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
+ int i;
+
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ for (i = panel_data->num_gpios - 1; i >= 0; --i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 1 : 0);
+ }
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
@@ -88,7 +110,12 @@ static void lb035q02_panel_power_off(struct omap_dss_device *dssdev)
static int lb035q02_panel_probe(struct omap_dss_device *dssdev)
{
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct lb035q02_data *ld;
+ int r, i;
+
+ if (!panel_data)
+ return -EINVAL;
dssdev->panel.timings = lb035q02_timings;
@@ -96,6 +123,15 @@ static int lb035q02_panel_probe(struct omap_dss_device *dssdev)
if (!ld)
return -ENOMEM;
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->gpios[i],
+ panel_data->gpio_invert[i] ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ "panel gpio");
+ if (r)
+ return r;
+ }
+
mutex_init(&ld->lock);
dev_set_drvdata(&dssdev->dev, ld);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 10/33] arm: omap: board-overo: use lb035q02 dpi panel's gpio handling
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The overo board file currently requests gpios required by the lb035q02 panel,
and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the lb035q02 dpi panel driver itself and should
be removed from the board files.
The lb035q02 panel driver uses generic dpi panel's platform data struct
internally. Remove the gpio requests and the platform callbacks from the board
file. Add the gpio information to the generic dpi panel platform data struct so
that it's passed to the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-overo.c | 58 +++++++++----------------------------
1 file changed, 14 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index bf6b2ce..888e150 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -144,28 +144,9 @@ static inline void __init overo_init_smsc911x(void) { return; }
#endif
/* DSS */
-static int lcd_enabled;
-static int dvi_enabled;
-
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145
-static struct gpio overo_dss_gpios[] __initdata = {
- { OVERO_GPIO_LCD_EN, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_EN" },
- { OVERO_GPIO_LCD_BL, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_BL" },
-};
-
-static void __init overo_display_init(void)
-{
- if (gpio_request_array(overo_dss_gpios, ARRAY_SIZE(overo_dss_gpios))) {
- printk(KERN_ERR "could not obtain DSS control GPIOs\n");
- return;
- }
-
- gpio_export(OVERO_GPIO_LCD_EN, 0);
- gpio_export(OVERO_GPIO_LCD_BL, 0);
-}
-
static struct tfp410_platform_data dvi_panel = {
.i2c_bus_num = 3,
.power_down_gpio = -1,
@@ -186,30 +167,13 @@ static struct omap_dss_device overo_tv_device = {
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
};
-static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(OVERO_GPIO_LCD_EN, 1);
- gpio_set_value(OVERO_GPIO_LCD_BL, 1);
- lcd_enabled = 1;
- return 0;
-}
-
-static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(OVERO_GPIO_LCD_EN, 0);
- gpio_set_value(OVERO_GPIO_LCD_BL, 0);
- lcd_enabled = 0;
-}
-
static struct panel_generic_dpi_data lcd43_panel = {
.name = "samsung_lte430wq_f0c",
- .platform_enable = overo_panel_enable_lcd,
- .platform_disable = overo_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ OVERO_GPIO_LCD_EN,
+ OVERO_GPIO_LCD_BL
+ },
};
static struct omap_dss_device overo_lcd43_device = {
@@ -222,13 +186,20 @@ static struct omap_dss_device overo_lcd43_device = {
#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
+static struct panel_generic_dpi_data lcd35_panel = {
+ .num_gpios = 2,
+ .gpios = {
+ OVERO_GPIO_LCD_EN,
+ OVERO_GPIO_LCD_BL
+ },
+};
+
static struct omap_dss_device overo_lcd35_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = "lcd35",
.driver_name = "lgphilips_lb035q02_panel",
.phy.dpi.data_lines = 24,
- .platform_enable = overo_panel_enable_lcd,
- .platform_disable = overo_panel_disable_lcd,
+ .data = &lcd35_panel,
};
#endif
@@ -502,7 +473,6 @@ static void __init overo_init(void)
usbhs_init(&usbhs_bdata);
overo_spi_init();
overo_init_smsc911x();
- overo_display_init();
overo_init_led();
overo_init_keys();
omap_twl4030_audio_init("overo");
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 11/33] OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The lgphilips panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
index 63cd8857..4ea6548 100644
--- a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
@@ -71,20 +71,13 @@ static int lb035q02_panel_power_on(struct omap_dss_device *dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
for (i = 0; i < panel_data->num_gpios; ++i) {
gpio_set_value_cansleep(panel_data->gpios[i],
panel_data->gpio_invert[i] ? 0 : 1);
}
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -102,9 +95,6 @@ static void lb035q02_panel_power_off(struct omap_dss_device *dssdev)
panel_data->gpio_invert[i] ? 1 : 0);
}
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 12/33] OMAPDSS: generic dpi panel: remove platform_enable/disable ops from platform_data
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The generic dpi panel driver now sets the gpios required to configure the panel.
This was previously done in platform_enable/disable callbacks in board files.
All the board files using generic dpi panel now correctly pass the gpio related
information as platform data, which is needed by the panel driver to configure
the panel. Hence, the platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-generic-dpi.c | 12 +---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 71 +++++++++++++++++---
include/video/omap-panel-data.h | 20 ++++--
3 files changed, 77 insertions(+), 26 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index 4a12db6..64d93b1 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -577,20 +577,13 @@ static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
if (panel_config->power_on_delay)
msleep(panel_config->power_on_delay);
- if (panel_data->platform_enable) {
- r = panel_data->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
for (i = 0; i < panel_data->num_gpios; ++i) {
gpio_set_value_cansleep(panel_data->gpios[i],
panel_data->gpio_invert[i] ? 0 : 1);
}
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -610,9 +603,6 @@ static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
panel_data->gpio_invert[i] ? 1 : 0);
}
- if (panel_data->platform_disable)
- panel_data->platform_disable(dssdev);
-
/* wait couple of vsyncs after disabling the LCD */
if (panel_config->power_off_delay)
msleep(panel_config->power_off_delay);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index eb6bd81..e6d9c9b 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -23,11 +23,10 @@
#include <linux/fb.h>
#include <linux/err.h>
#include <linux/slab.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
-
-struct sharp_data {
-};
+#include <video/omap-panel-data.h>
static struct omap_video_timings sharp_ls_timings = {
.x_res = 480,
@@ -50,31 +49,67 @@ static struct omap_video_timings sharp_ls_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_sharp_ls037v7dw01_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_sharp_ls037v7dw01_data *) dssdev->data;
+}
static int sharp_ls_panel_probe(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd;
+ struct panel_sharp_ls037v7dw01_data *pd = get_panel_data(dssdev);
+ int r;
+
+ if (!pd)
+ return -EINVAL;
dssdev->panel.timings = sharp_ls_timings;
- sd = kzalloc(sizeof(*sd), GFP_KERNEL);
- if (!sd)
- return -ENOMEM;
+ if (gpio_is_valid(pd->mo_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->mo_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd MO");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->lr_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->lr_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd LR");
+ if (r)
+ return r;
+ }
- dev_set_drvdata(&dssdev->dev, sd);
+ if (gpio_is_valid(pd->ud_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->ud_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd UD");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->resb_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->resb_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RESB");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->ini_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->ini_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd INI");
+ if (r)
+ return r;
+ }
return 0;
}
static void __exit sharp_ls_panel_remove(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd = dev_get_drvdata(&dssdev->dev);
-
- kfree(sd);
}
static int sharp_ls_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_sharp_ls037v7dw01_data *pd = get_panel_data(dssdev);
int r = 0;
if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
@@ -96,6 +131,12 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ if (gpio_is_valid(pd->resb_gpio))
+ gpio_set_value_cansleep(pd->resb_gpio, 1);
+
+ if (gpio_is_valid(pd->ini_gpio))
+ gpio_set_value_cansleep(pd->ini_gpio, 1);
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -105,9 +146,17 @@ err0:
static void sharp_ls_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_sharp_ls037v7dw01_data *pd = get_panel_data(dssdev);
+
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ if (gpio_is_valid(pd->ini_gpio))
+ gpio_set_value_cansleep(pd->ini_gpio, 0);
+
+ if (gpio_is_valid(pd->resb_gpio))
+ gpio_set_value_cansleep(pd->resb_gpio, 0);
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index eec93f1..86da8d3 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -32,16 +32,12 @@ struct omap_dss_device;
/**
* struct panel_generic_dpi_data - panel driver configuration data
* @name: panel name
- * @platform_enable: platform specific panel enable function
- * @platform_disable: platform specific panel disable function
* @num_gpios: number of gpios connected to panel
* @gpios: gpio numbers on the platform
* @gpio_invert: configure gpio as active high or low
*/
struct panel_generic_dpi_data {
const char *name;
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
int num_gpios;
int gpios[10];
@@ -105,4 +101,20 @@ struct tfp410_platform_data {
int power_down_gpio;
};
+/**
+ * sharp ls panel driver configuration data
+ * @resb_gpio: reset signal
+ * @ini_gpio: power on control
+ * @mo_gpio: selection for resolution(VGA/QVGA)
+ * @lr_gpio: selection for horizontal scanning direction
+ * @ud_gpio: selection for vertical scanning direction
+ */
+struct panel_sharp_ls037v7dw01_data {
+ int resb_gpio;
+ int ini_gpio;
+ int mo_gpio;
+ int lr_gpio;
+ int ud_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 13/33] arm: omap: board-omap3evm: use sharp panel's gpio handling
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The omap3evm board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to panel_sharp_ls037v7dw01_data so that it's passed
to the panel driver.
Note: The GPIOs OMAP3EVM_LCD_PANEL_ENVDD and OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO
aren't directly connected to the sharp panel, hence they aren't passed to the
panel driver as platform data. These are set to a default value such that LCD
is enabled and backlight is on. These used to previously toggle through the
platform_enable/disable callbacks, but now these are always on. This needs to
be revisited.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-omap3evm.c | 59 ++++++++++++----------------------
1 file changed, 20 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 335127d..dfb5e1b 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -154,61 +154,43 @@ static inline void __init omap3evm_init_smsc911x(void) { return; }
#define OMAP3EVM_LCD_PANEL_LR 2
#define OMAP3EVM_LCD_PANEL_UD 3
#define OMAP3EVM_LCD_PANEL_INI 152
-#define OMAP3EVM_LCD_PANEL_ENVDD 153
#define OMAP3EVM_LCD_PANEL_QVGA 154
#define OMAP3EVM_LCD_PANEL_RESB 155
+
+#define OMAP3EVM_LCD_PANEL_ENVDD 153
#define OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO 210
+
+/*
+ * OMAP3EVM DVI control signals
+ */
#define OMAP3EVM_DVI_PANEL_EN_GPIO 199
-static struct gpio omap3_evm_dss_gpios[] __initdata = {
- { OMAP3EVM_LCD_PANEL_RESB, GPIOF_OUT_INIT_HIGH, "lcd_panel_resb" },
- { OMAP3EVM_LCD_PANEL_INI, GPIOF_OUT_INIT_HIGH, "lcd_panel_ini" },
- { OMAP3EVM_LCD_PANEL_QVGA, GPIOF_OUT_INIT_LOW, "lcd_panel_qvga" },
- { OMAP3EVM_LCD_PANEL_LR, GPIOF_OUT_INIT_HIGH, "lcd_panel_lr" },
- { OMAP3EVM_LCD_PANEL_UD, GPIOF_OUT_INIT_HIGH, "lcd_panel_ud" },
- { OMAP3EVM_LCD_PANEL_ENVDD, GPIOF_OUT_INIT_LOW, "lcd_panel_envdd" },
+static struct panel_sharp_ls037v7dw01_data omap3_evm_lcd_data = {
+ .resb_gpio = OMAP3EVM_LCD_PANEL_RESB,
+ .ini_gpio = OMAP3EVM_LCD_PANEL_INI,
+ .mo_gpio = OMAP3EVM_LCD_PANEL_QVGA,
+ .lr_gpio = OMAP3EVM_LCD_PANEL_LR,
+ .ud_gpio = OMAP3EVM_LCD_PANEL_UD,
};
-static int lcd_enabled;
-static int dvi_enabled;
-
static void __init omap3_evm_display_init(void)
{
int r;
- r = gpio_request_array(omap3_evm_dss_gpios,
- ARRAY_SIZE(omap3_evm_dss_gpios));
+ r = gpio_request_one(OMAP3EVM_LCD_PANEL_ENVDD, GPIOF_OUT_INIT_LOW,
+ "lcd_panel_envdd");
if (r)
- printk(KERN_ERR "failed to get lcd_panel_* gpios\n");
-}
+ pr_err("failed to get lcd_panel_envdd GPIO\n");
-static int omap3_evm_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
- gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 0);
+ r = gpio_request_one(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO,
+ GPIOF_OUT_INIT_LOW, "lcd_panel_bklight");
+ if (r)
+ pr_err("failed to get lcd_panel_bklight GPIO\n");
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
-
- lcd_enabled = 1;
- return 0;
-}
-
-static void omap3_evm_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 1);
-
- if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
- gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
- else
- gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
-
- lcd_enabled = 0;
}
static struct omap_dss_device omap3_evm_lcd_device = {
@@ -216,8 +198,7 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.driver_name = "sharp_ls_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 18,
- .platform_enable = omap3_evm_enable_lcd,
- .platform_disable = omap3_evm_disable_lcd,
+ .data = &omap3_evm_lcd_data,
};
static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 14/33] arm: omap: board-sdp3430: use sharp panel's gpio handling
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The omap3430sdp board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to panel_sharp_ls037v7dw01_data so that it's
passed to the panel driver.
Out of sharp panel's configurable pins, all apart from resb_gpio are managed by
a CPLD on the display and set to a default value. Only the configurable pin is
passed to platform data.
The backlight GPIO doesn't go directly to the sharp panel, it is used to set up
a voltage supply which goes to the LED+ pin of the panel, hence it isn't passed
to panel as platform data, and configured in the board file itself. The
backlight used to previously toggle through the platform_enable/disable
callbacks, but now it is always on. This needs to be revisited.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-3430sdp.c | 42 +++++++++++++++--------------------
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index fb75a81..13f1431 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -106,34 +106,22 @@ static struct twl4030_keypad_data sdp3430_kp_data = {
#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
-static struct gpio sdp3430_dss_gpios[] __initdata = {
- {SDP3430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, "LCD reset" },
- {SDP3430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, "LCD Backlight"},
-};
-
static void __init sdp3430_display_init(void)
{
int r;
- r = gpio_request_array(sdp3430_dss_gpios,
- ARRAY_SIZE(sdp3430_dss_gpios));
+ /*
+ * the backlight GPIO doesn't directly go to the panel, it enables
+ * an internal circuit on 3430sdp to create the signal V_BKL_28V,
+ * this is connected to LED+ pin of the sharp panel. This GPIO
+ * is left enabled in the board file, and not passed to the panel
+ * as platform_data.
+ */
+ r = gpio_request_one(SDP3430_LCD_PANEL_BACKLIGHT_GPIO,
+ GPIOF_OUT_INIT_HIGH, "LCD Backlight");
if (r)
- printk(KERN_ERR "failed to get LCD control GPIOs\n");
-
-}
-
-static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP3430_LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 1);
-
- return 0;
-}
+ pr_err("failed to get LCD Backlight GPIO\n");
-static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP3430_LCD_PANEL_ENABLE_GPIO, 0);
- gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 0);
}
static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -145,14 +133,20 @@ static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
{
}
+static struct panel_sharp_ls037v7dw01_data sdp3430_lcd_data = {
+ .resb_gpio = SDP3430_LCD_PANEL_ENABLE_GPIO,
+ .ini_gpio = -1,
+ .mo_gpio = -1,
+ .lr_gpio = -1,
+ .ud_gpio = -1,
+};
static struct omap_dss_device sdp3430_lcd_device = {
.name = "lcd",
.driver_name = "sharp_ls_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 16,
- .platform_enable = sdp3430_panel_enable_lcd,
- .platform_disable = sdp3430_panel_disable_lcd,
+ .data = &sdp3430_lcd_data,
};
static struct tfp410_platform_data dvi_panel = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 15/33] OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The sharp-ls panel driver now manages the gpios required to configure the panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_sharp_ls037v7dw01_data struct, which is needed by the panel
driver to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index e6d9c9b..74cb0eb 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -125,12 +125,6 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
if (gpio_is_valid(pd->resb_gpio))
gpio_set_value_cansleep(pd->resb_gpio, 1);
@@ -138,8 +132,6 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
gpio_set_value_cansleep(pd->ini_gpio, 1);
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
err0:
return r;
}
@@ -157,9 +149,6 @@ static void sharp_ls_power_off(struct omap_dss_device *dssdev)
if (gpio_is_valid(pd->resb_gpio))
gpio_set_value_cansleep(pd->resb_gpio, 0);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
/* wait at least 5 vsyncs after disabling the LCD */
msleep(100);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The acx565akm panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the panel
driver itself.
Create a platform data struct for the panel, this contains the reset gpio number
used by the panel driver, this struct will be passed to the panel driver as
platform data. The driver will request and configure the reset gpio rather than
leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-acx565akm.c | 48 ++++++++++++++++--------
include/video/omap-panel-data.h | 8 ++++
2 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c
index a8fb26b..d7f69c0 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -29,8 +29,10 @@
#include <linux/sched.h>
#include <linux/backlight.h>
#include <linux/fb.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
#define MIPID_CMD_READ_DISP_ID 0x04
#define MIPID_CMD_READ_RED 0x06
@@ -494,21 +496,38 @@ static struct omap_video_timings acx_panel_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device *dssdev)
+{
+ return (struct panel_acx565akm_data *) dssdev->data;
+}
+
static int acx_panel_probe(struct omap_dss_device *dssdev)
{
int r;
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
struct backlight_device *bldev;
int max_brightness, brightness;
struct backlight_properties props;
dev_dbg(&dssdev->dev, "%s\n", __func__);
+ if (!panel_data)
+ return -EINVAL;
+
/* FIXME AC bias ? */
dssdev->panel.timings = acx_panel_timings;
- if (dssdev->platform_enable)
- dssdev->platform_enable(dssdev);
+ if (gpio_is_valid(panel_data->reset_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->reset_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd reset");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 1);
+
/*
* After reset we have to wait 5 msec before the first
* command can be sent.
@@ -520,8 +539,9 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
r = panel_detect(md);
if (r) {
dev_err(&dssdev->dev, "%s panel detect error\n", __func__);
- if (!md->enabled && dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
+ if (!md->enabled && gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 0);
+
return r;
}
@@ -530,8 +550,8 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
mutex_unlock(&acx_dev.mutex);
if (!md->enabled) {
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 0);
}
/*------- Backlight control --------*/
@@ -584,6 +604,7 @@ static void acx_panel_remove(struct omap_dss_device *dssdev)
static int acx_panel_power_on(struct omap_dss_device *dssdev)
{
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
int r;
dev_dbg(&dssdev->dev, "%s\n", __func__);
@@ -605,11 +626,8 @@ static int acx_panel_power_on(struct omap_dss_device *dssdev)
/*FIXME tweak me */
msleep(50);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto fail;
- }
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 1);
if (md->enabled) {
dev_dbg(&md->spi->dev, "panel already enabled\n");
@@ -638,8 +656,7 @@ static int acx_panel_power_on(struct omap_dss_device *dssdev)
mutex_unlock(&md->mutex);
return acx565akm_bl_update_status(md->bl_dev);
-fail:
- omapdss_sdi_display_disable(dssdev);
+
fail_unlock:
mutex_unlock(&md->mutex);
return r;
@@ -648,6 +665,7 @@ fail_unlock:
static void acx_panel_power_off(struct omap_dss_device *dssdev)
{
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
dev_dbg(&dssdev->dev, "%s\n", __func__);
@@ -671,8 +689,8 @@ static void acx_panel_power_off(struct omap_dss_device *dssdev)
*/
msleep(50);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 0);
/* FIXME need to tweak this delay */
msleep(100);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 86da8d3..6faf0c7 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -117,4 +117,12 @@ struct panel_sharp_ls037v7dw01_data {
int ud_gpio;
};
+/**
+ * acx565akm panel driver configuration data
+ * @reset_gpio: reset signal
+ */
+struct panel_acx565akm_data {
+ int reset_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 17/33] arm: omap: board-rx-51: use acx565akm panel's gpio handling
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The rx-51 board file currently requests gpios required by the acx565akm panel,
and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the acx565akm panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file. Pass
the panel_acx565akm_data instance 'lcd_data' to omap_dss_device instead of
passing the gpio number in omap_dss_device's reset_gpio.
Add the gpio information to panel_acx565akm_data so that it's passed to the
panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-rx51-video.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c
index 46f4fc9..9e8afa4 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -16,6 +16,8 @@
#include <linux/mm.h>
#include <asm/mach-types.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
+
#include <linux/platform_data/spi-omap2-mcspi.h>
#include "board-rx51.h"
@@ -26,25 +28,16 @@
#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
-static int rx51_lcd_enable(struct omap_dss_device *dssdev)
-{
- gpio_set_value(dssdev->reset_gpio, 1);
- return 0;
-}
-
-static void rx51_lcd_disable(struct omap_dss_device *dssdev)
-{
- gpio_set_value(dssdev->reset_gpio, 0);
-}
+static struct panel_acx565akm_data lcd_data = {
+ .reset_gpio = RX51_LCD_RESET_GPIO,
+};
static struct omap_dss_device rx51_lcd_device = {
.name = "lcd",
.driver_name = "panel-acx565akm",
.type = OMAP_DISPLAY_TYPE_SDI,
.phy.sdi.datapairs = 2,
- .reset_gpio = RX51_LCD_RESET_GPIO,
- .platform_enable = rx51_lcd_enable,
- .platform_disable = rx51_lcd_disable,
+ .data = &lcd_data,
};
static struct omap_dss_device rx51_tv_device = {
@@ -75,13 +68,8 @@ static int __init rx51_video_init(void)
return 0;
}
- if (gpio_request_one(RX51_LCD_RESET_GPIO, GPIOF_OUT_INIT_HIGH,
- "LCD ACX565AKM reset")) {
- pr_err("%s failed to get LCD Reset GPIO\n", __func__);
- return 0;
- }
-
omap_display_init(&rx51_dss_board_info);
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 18/33] OMAPDSS: nec-nl8048 panel: handle gpios ins panel driver
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The nec-nl8048hl11-01 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.
Create a platform data struct for the panel, this contains the gpio numbers
used by the panel driver, this struct will be passed to the panel driver as
platform data. The driver will request and configure these gpios rather than
leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 45 +++++++++++++++-----
include/video/omap-panel-data.h | 10 +++++
2 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index c197927..3b85e2a 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -20,8 +20,10 @@
#include <linux/delay.h>
#include <linux/spi/spi.h>
#include <linux/fb.h>
+#include <linux/gpio.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
#define LCD_XRES 800
#define LCD_YRES 480
@@ -31,9 +33,6 @@
*/
#define LCD_PIXEL_CLOCK 23800
-struct nec_8048_data {
-};
-
static const struct {
unsigned char addr;
unsigned char dat;
@@ -82,30 +81,46 @@ static struct omap_video_timings nec_8048_panel_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
};
+static inline struct panel_nec_nl8048_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_nec_nl8048_data *) dssdev->data;
+}
+
static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
{
- struct nec_8048_data *necd;
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
+ int r;
+
+ if (!pd)
+ return -EINVAL;
dssdev->panel.timings = nec_8048_panel_timings;
- necd = kzalloc(sizeof(*necd), GFP_KERNEL);
- if (!necd)
- return -ENOMEM;
+ if (gpio_is_valid(pd->qvga_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->qvga_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd QVGA");
+ if (r)
+ return r;
+ }
- dev_set_drvdata(&dssdev->dev, necd);
+ if (gpio_is_valid(pd->res_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->res_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RES");
+ if (r)
+ return r;
+ }
return 0;
}
static void nec_8048_panel_remove(struct omap_dss_device *dssdev)
{
- struct nec_8048_data *necd = dev_get_drvdata(&dssdev->dev);
-
- kfree(necd);
}
static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
int r;
if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
@@ -124,6 +139,9 @@ static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ if (gpio_is_valid(pd->res_gpio))
+ gpio_set_value_cansleep(pd->res_gpio, 1);
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -133,9 +151,14 @@ err0:
static void nec_8048_panel_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
+
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ if (gpio_is_valid(pd->res_gpio))
+ gpio_set_value_cansleep(pd->res_gpio, 0);
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 6faf0c7..e7698e2 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -125,4 +125,14 @@ struct panel_acx565akm_data {
int reset_gpio;
};
+/**
+ * nec nl8048 panel driver configuration data
+ * @res_gpio: reset signal
+ * @qvga_gpio: selection for resolution(QVGA/WVGA)
+ */
+struct panel_nec_nl8048_data {
+ int res_gpio;
+ int qvga_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 19/33] arm: omap: board-zoom: use NEC panel's gpio handling
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The zoom board file currently requests gpios required by the nec-nl8048hl11-01
dpi panel, and provides dummy platform_enable/disable callbacks.
gpio request and configuration have been moved to the nec-nl8048hl11-01 panel
driver itself and shouldn't be done in the board files.
Remove the gpio requests and the platform callbacks from the board file. Add the
gpio information to panel_nec_nl8048_data so that it's passed to the panel
driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-zoom-display.c | 38 ++++++++++--------------------
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-display.c b/arch/arm/mach-omap2/board-zoom-display.c
index 4717ed5..bd79082 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -16,8 +16,9 @@
#include <linux/spi/spi.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <video/omapdss.h>
-#include "board-zoom.h"
+#include <video/omap-panel-data.h>
+#include "board-zoom.h"
#include "soc.h"
#include "common.h"
@@ -25,30 +26,11 @@
#define LCD_PANEL_RESET_GPIO_PILOT 55
#define LCD_PANEL_QVGA_GPIO 56
-static struct gpio zoom_lcd_gpios[] __initdata = {
- { -EINVAL, GPIOF_OUT_INIT_HIGH, "lcd reset" },
- { LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "lcd qvga" },
+static struct panel_nec_nl8048_data zoom_lcd_data = {
+ /* res_gpio filled in code */
+ .qvga_gpio = LCD_PANEL_QVGA_GPIO,
};
-static void __init zoom_lcd_panel_init(void)
-{
- zoom_lcd_gpios[0].gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
- LCD_PANEL_RESET_GPIO_PROD :
- LCD_PANEL_RESET_GPIO_PILOT;
-
- if (gpio_request_array(zoom_lcd_gpios, ARRAY_SIZE(zoom_lcd_gpios)))
- pr_err("%s: Failed to get LCD GPIOs.\n", __func__);
-}
-
-static int zoom_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void zoom_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
-}
-
/*
* PWMA/B register offsets (TWL4030_MODULE_PWMA)
*/
@@ -107,8 +89,7 @@ static struct omap_dss_device zoom_lcd_device = {
.driver_name = "NEC_8048_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
- .platform_enable = zoom_panel_enable_lcd,
- .platform_disable = zoom_panel_disable_lcd,
+ .data = &zoom_lcd_data,
};
static struct omap_dss_device *zoom_dss_devices[] = {
@@ -121,6 +102,13 @@ static struct omap_dss_board_info zoom_dss_data = {
.default_device = &zoom_lcd_device,
};
+static void __init zoom_lcd_panel_init(void)
+{
+ zoom_lcd_data.res_gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
+ LCD_PANEL_RESET_GPIO_PROD :
+ LCD_PANEL_RESET_GPIO_PILOT;
+}
+
static struct omap2_mcspi_device_config dss_lcd_mcspi_config = {
.turbo_mode = 1,
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 20/33] OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The nec-nl8048 panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_nec_nl8048_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index 3b85e2a..1e0097d 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -133,18 +133,11 @@ static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
if (gpio_is_valid(pd->res_gpio))
gpio_set_value_cansleep(pd->res_gpio, 1);
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -159,9 +152,6 @@ static void nec_8048_panel_power_off(struct omap_dss_device *dssdev)
if (gpio_is_valid(pd->res_gpio))
gpio_set_value_cansleep(pd->res_gpio, 0);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 21/33] OMAPDSS: tpo-td043 panel: handle gpios in panel driver
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The tpo-td043mtea1 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.
Create a platform data struct for the panel, this contains the reset gpio
number used by the panel driver, this struct will be passed to the panel driver
as platform data. The driver will request and configure the reset gpio rather
than leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 36 ++++++++++++--------
include/video/omap-panel-data.h | 8 +++++
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 6b66439..c8244bc 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -18,6 +18,7 @@
#include <linux/slab.h>
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
#define TPO_R02_MODE(x) ((x) & 7)
#define TPO_R02_MODE_800x480 7
@@ -275,9 +276,14 @@ static const struct omap_video_timings tpo_td043_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_tpo_td043_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_tpo_td043_data *) dssdev->data;
+}
+
static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
{
- int nreset_gpio = tpo_td043->nreset_gpio;
int r;
if (tpo_td043->powered_on)
@@ -290,8 +296,8 @@ static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
/* wait for panel to stabilize */
msleep(160);
- if (gpio_is_valid(nreset_gpio))
- gpio_set_value(nreset_gpio, 1);
+ if (gpio_is_valid(tpo_td043->nreset_gpio))
+ gpio_set_value(tpo_td043->nreset_gpio, 1);
tpo_td043_write(tpo_td043->spi, 2,
TPO_R02_MODE(tpo_td043->mode) | TPO_R02_NCLK_RISING);
@@ -308,16 +314,14 @@ static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
static void tpo_td043_power_off(struct tpo_td043_device *tpo_td043)
{
- int nreset_gpio = tpo_td043->nreset_gpio;
-
if (!tpo_td043->powered_on)
return;
tpo_td043_write(tpo_td043->spi, 3,
TPO_R03_VAL_STANDBY | TPO_R03_EN_PWM);
- if (gpio_is_valid(nreset_gpio))
- gpio_set_value(nreset_gpio, 0);
+ if (gpio_is_valid(tpo_td043->nreset_gpio))
+ gpio_set_value(tpo_td043->nreset_gpio, 0);
/* wait for at least 2 vsyncs before cutting off power */
msleep(50);
@@ -404,7 +408,7 @@ static void tpo_td043_disable(struct omap_dss_device *dssdev)
static int tpo_td043_probe(struct omap_dss_device *dssdev)
{
struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
+ struct panel_tpo_td043_data *pdata = get_panel_data(dssdev);
int ret = 0;
dev_dbg(&dssdev->dev, "probe\n");
@@ -414,6 +418,11 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
return -ENODEV;
}
+ if (!pdata)
+ return -EINVAL;
+
+ tpo_td043->nreset_gpio = pdata->nreset_gpio;
+
dssdev->panel.timings = tpo_td043_timings;
dssdev->ctrl.pixel_size = 24;
@@ -427,9 +436,10 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
goto fail_regulator;
}
- if (gpio_is_valid(nreset_gpio)) {
- ret = gpio_request_one(nreset_gpio, GPIOF_OUT_INIT_LOW,
- "lcd reset");
+ if (gpio_is_valid(tpo_td043->nreset_gpio)) {
+ ret = devm_gpio_request_one(&dssdev->dev,
+ tpo_td043->nreset_gpio, GPIOF_OUT_INIT_LOW,
+ "lcd reset");
if (ret < 0) {
dev_err(&dssdev->dev, "couldn't request reset GPIO\n");
goto fail_gpio_req;
@@ -452,14 +462,11 @@ fail_regulator:
static void tpo_td043_remove(struct omap_dss_device *dssdev)
{
struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
dev_dbg(&dssdev->dev, "remove\n");
sysfs_remove_group(&dssdev->dev.kobj, &tpo_td043_attr_group);
regulator_put(tpo_td043->vcc_reg);
- if (gpio_is_valid(nreset_gpio))
- gpio_free(nreset_gpio);
}
static void tpo_td043_set_timings(struct omap_dss_device *dssdev,
@@ -519,7 +526,6 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
return -ENOMEM;
tpo_td043->spi = spi;
- tpo_td043->nreset_gpio = dssdev->reset_gpio;
dev_set_drvdata(&spi->dev, tpo_td043);
dev_set_drvdata(&dssdev->dev, tpo_td043);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index e7698e2..7cac89e 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -135,4 +135,12 @@ struct panel_nec_nl8048_data {
int qvga_gpio;
};
+/**
+ * tpo td043 panel driver configuration data
+ * @nreset_gpio: reset signal
+ */
+struct panel_tpo_td043_data {
+ int nreset_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 22/33] arm: omap: board-omap3pandora: use tpo panel's gpio handling
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The omap3pandora board file currently passes the reset gpio number to the
tpo-td043mtea1 panel driver via the reset_gpio field in omap_dss_device.
Platform related information should be passed via the panel driver's platform
data struct.
Add the reset gpio information to panel_tpo_td043_data so that it's passed to
the panel driver.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-omap3pandora.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index a53a668..ddd6322 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -43,6 +43,7 @@
#include "common.h"
#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
#include <linux/platform_data/mtd-nand-omap2.h>
#include "mux.h"
@@ -229,12 +230,16 @@ static struct twl4030_keypad_data pandora_kp_data = {
.rep = 1,
};
+static struct panel_tpo_td043_data lcd_data = {
+ .nreset_gpio = 157,
+};
+
static struct omap_dss_device pandora_lcd_device = {
.name = "lcd",
.driver_name = "tpo_td043mtea1_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
- .reset_gpio = 157,
+ .data = &lcd_data,
};
static struct omap_dss_device pandora_tv_device = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 23/33] OMAPDSS: tpo-td043: remove platform_enable/disable callbacks
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The tpo-td043 panel driver now manages the gpios required to configure the panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_tpo_td043_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the platform_enable/disable
ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index c8244bc..24bb0ff 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -348,12 +348,6 @@ static int tpo_td043_enable_dss(struct omap_dss_device *dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
/*
* If we are resuming from system suspend, SPI clocks might not be
* enabled yet, so we'll program the LCD from SPI PM resume callback.
@@ -380,9 +374,6 @@ static void tpo_td043_disable_dss(struct omap_dss_device *dssdev)
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
if (!tpo_td043->spi_suspended)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 24/33] OMAPDSS: picodlp panel: handle gpio data in panel driver
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The picodlp panel driver leaves gpio requests to the platform's board file.
These should happen in the panel driver itself.
A platform data struct called picodlp_panel_data already exists to hold gpio
numbers and other platform data. Request all the gpios in the panel driver so
that the board files which use the the panel don't need to do it.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-picodlp.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c b/drivers/video/omap2/displays/panel-picodlp.c
index 56d536c..bc8ac77 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -423,10 +423,13 @@ static int picodlp_panel_probe(struct omap_dss_device *dssdev)
struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
struct i2c_adapter *adapter;
struct i2c_client *picodlp_i2c_client;
- int picodlp_adapter_id;
+ int r, picodlp_adapter_id;
dssdev->panel.timings = pico_ls_timings;
+ if (!picodlp_pdata)
+ return -EINVAL;
+
picod = devm_kzalloc(&dssdev->dev, sizeof(*picod), GFP_KERNEL);
if (!picod)
return -ENOMEM;
@@ -452,6 +455,22 @@ static int picodlp_panel_probe(struct omap_dss_device *dssdev)
dev_set_drvdata(&dssdev->dev, picod);
+ if (gpio_is_valid(picodlp_pdata->emu_done_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev,
+ picodlp_pdata->emu_done_gpio,
+ GPIOF_IN, "DLP EMU DONE");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(picodlp_pdata->pwrgood_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev,
+ picodlp_pdata->pwrgood_gpio,
+ GPIOF_OUT_INIT_LOW, "DLP PWRGOOD");
+ if (r)
+ return r;
+ }
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 25/33] arm: omap: dss-common: use picodlp panel's gpio handling
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The dss-common file currently requests gpios required by the picodlp DPI
panel on the 4430sdp/blaze board. It also requests DISPLAY_SEL_GPIO and
DLP_POWER_ON_GPIO gpios which are board specific gpios to switch between lcd2
panel and picodlp, and setting intermediate power supplies for picodlp
respectively. These gpios are toggled through platform_enable/disable functions
called by the picodlp driver.
Remove the gpio requests for the gpios which are already requested by the panel
driver, and remove the platform callback functions and set the platform specific
gpios in such a way that lcd2 panel is selected for the LCD2 overlay manager and
the power supplies for picodlp are disabled.
Note: We need to revisit this so that we can enable and switch to picodlp if
that's the only panel driver available for the LCD2 overlay manager.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 53 ++++++++++++--------------------------
1 file changed, 16 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 9c49bbe..b073e8b 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -177,45 +177,12 @@ static struct picodlp_panel_data sdp4430_picodlp_pdata = {
.pwrgood_gpio = 45,
};
-static void sdp4430_picodlp_init(void)
-{
- int r;
- const struct gpio picodlp_gpios[] = {
- {DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- "DLP POWER ON"},
- {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
- "DLP EMU DONE"},
- {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
- "DLP PWRGOOD"},
- };
-
- r = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
- if (r)
- pr_err("Cannot request PicoDLP GPIOs, error %d\n", r);
-}
-
-static int sdp4430_panel_enable_picodlp(struct omap_dss_device *dssdev)
-{
- gpio_set_value(DISPLAY_SEL_GPIO, 0);
- gpio_set_value(DLP_POWER_ON_GPIO, 1);
-
- return 0;
-}
-
-static void sdp4430_panel_disable_picodlp(struct omap_dss_device *dssdev)
-{
- gpio_set_value(DLP_POWER_ON_GPIO, 0);
- gpio_set_value(DISPLAY_SEL_GPIO, 1);
-}
-
static struct omap_dss_device sdp4430_picodlp_device = {
.name = "picodlp",
.driver_name = "picodlp_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.channel = OMAP_DSS_CHANNEL_LCD2,
- .platform_enable = sdp4430_panel_enable_picodlp,
- .platform_disable = sdp4430_panel_disable_picodlp,
.data = &sdp4430_picodlp_pdata,
};
@@ -232,17 +199,26 @@ static struct omap_dss_board_info sdp4430_dss_data = {
.default_device = &sdp4430_lcd_device,
};
+/*
+ * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
+ * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
+ * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
+ * selected by default
+ */
void __init omap_4430sdp_display_init(void)
{
int r;
- /* Enable LCD2 by default (instead of Pico DLP) */
r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
"display_sel");
if (r)
pr_err("%s: Could not get display_sel GPIO\n", __func__);
- sdp4430_picodlp_init();
+ r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ "DLP POWER ON");
+ if (r)
+ pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
+
omap_display_init(&sdp4430_dss_data);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -262,12 +238,15 @@ void __init omap_4430sdp_display_init_of(void)
{
int r;
- /* Enable LCD2 by default (instead of Pico DLP) */
r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
"display_sel");
if (r)
pr_err("%s: Could not get display_sel GPIO\n", __func__);
- sdp4430_picodlp_init();
+ r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ "DLP POWER ON");
+ if (r)
+ pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
+
omap_display_init(&sdp4430_dss_data);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 26/33] OMAPDSS: picodlp panel: remove platform_enable/disable callbacks
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The picodlp panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-picodlp.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c b/drivers/video/omap2/displays/panel-picodlp.c
index bc8ac77..62f2db0 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -354,12 +354,6 @@ static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
struct picodlp_data *picod = dev_get_drvdata(&dssdev->dev);
struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- return r;
- }
-
gpio_set_value(picodlp_pdata->pwrgood_gpio, 0);
msleep(1);
gpio_set_value(picodlp_pdata->pwrgood_gpio, 1);
@@ -398,9 +392,6 @@ static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
err:
omapdss_dpi_display_disable(dssdev);
err1:
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
return r;
}
@@ -412,9 +403,6 @@ static void picodlp_panel_power_off(struct omap_dss_device *dssdev)
gpio_set_value(picodlp_pdata->emu_done_gpio, 0);
gpio_set_value(picodlp_pdata->pwrgood_gpio, 0);
-
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
}
static int picodlp_panel_probe(struct omap_dss_device *dssdev)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The n8x0 panel driver leaves gpio configurations to the platform_enable and
disable calls in the platform's board file. These should happen in the panel
driver itself.
A platform data struct called panel_n8x0_data already exists to hold gpio
numbers and other platform data. However, the gpio requests are expected to be
done in the board file and not the panel driver.
Request all the gpios in the panel driver so that the board files which use
the the panel don't need to do it. This will help in removing the need for the
panel drivers to have platform related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-n8x0.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c b/drivers/video/omap2/displays/panel-n8x0.c
index 9c55c91..c146a3d 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -426,6 +426,7 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
{
struct panel_n8x0_data *bdata = get_board_data(dssdev);
struct panel_drv_data *ddata;
+ int r;
dev_dbg(&dssdev->dev, "probe\n");
@@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
+ if (gpio_is_valid(bdata->panel_reset)) {
+ r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
+ GPIOF_OUT_INIT_LOW, "PANEL RESET");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(bdata->ctrl_pwrdown)) {
+ r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
+ GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
+ if (r)
+ return r;
+ }
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 28/33] OMAPDSS: n8x0 panel: remove platform_enable/disable callbacks
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The n8x0 panel driver now manages the gpios required to configure the panel.
This was previously done in panel_n8x0_data's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_n8x0_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the platform_enable/disable
ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-n8x0.c | 12 ------------
include/video/omap-panel-data.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c b/drivers/video/omap2/displays/panel-n8x0.c
index c146a3d..f94ead6 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -295,12 +295,6 @@ static int n8x0_panel_power_on(struct omap_dss_device *dssdev)
gpio_direction_output(bdata->ctrl_pwrdown, 1);
- if (bdata->platform_enable) {
- r = bdata->platform_enable(dssdev);
- if (r)
- goto err_plat_en;
- }
-
omapdss_rfbi_set_size(dssdev, dssdev->panel.timings.x_res,
dssdev->panel.timings.y_res);
omapdss_rfbi_set_pixel_size(dssdev, dssdev->ctrl.pixel_size);
@@ -373,9 +367,6 @@ err_inv_panel:
err_inv_chip:
omapdss_rfbi_display_disable(dssdev);
err_rfbi_en:
- if (bdata->platform_disable)
- bdata->platform_disable(dssdev);
-err_plat_en:
gpio_direction_output(bdata->ctrl_pwrdown, 0);
return r;
}
@@ -392,9 +383,6 @@ static void n8x0_panel_power_off(struct omap_dss_device *dssdev)
send_display_off(spi);
send_sleep_in(spi);
- if (bdata->platform_disable)
- bdata->platform_disable(dssdev);
-
/*
* HACK: we should turn off the panel here, but there is some problem
* with the initialization sequence, and we fail to init the panel if we
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 7cac89e..84f332e 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -48,8 +48,6 @@ struct panel_generic_dpi_data {
* struct panel_n8x0_data - N800 panel driver configuration data
*/
struct panel_n8x0_data {
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
int panel_reset;
int ctrl_pwrdown;
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 29/33] arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC device
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
The omap_dss_device's platform_enable/disable callbacks don't do anything for
any of the boards. The platform calls from the VENC driver will also be removed
in the future. Remove these calls from the board which have a VENC device.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/board-3430sdp.c | 11 -----------
arch/arm/mach-omap2/board-am3517evm.c | 11 -----------
arch/arm/mach-omap2/board-cm-t35.c | 11 -----------
arch/arm/mach-omap2/board-omap3evm.c | 11 -----------
arch/arm/mach-omap2/board-omap3stalker.c | 11 -----------
5 files changed, 55 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 13f1431..717dd15 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -124,15 +124,6 @@ static void __init sdp3430_display_init(void)
}
-static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct panel_sharp_ls037v7dw01_data sdp3430_lcd_data = {
.resb_gpio = SDP3430_LCD_PANEL_ENABLE_GPIO,
.ini_gpio = -1,
@@ -167,8 +158,6 @@ static struct omap_dss_device sdp3430_tv_device = {
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = sdp3430_panel_enable_tv,
- .platform_disable = sdp3430_panel_disable_tv,
};
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index eb245a6..edb4cce 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -138,22 +138,11 @@ static struct omap_dss_device am3517_evm_lcd_device = {
.phy.dpi.data_lines = 16,
};
-static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void am3517_evm_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device am3517_evm_tv_device = {
.type = OMAP_DISPLAY_TYPE_VENC,
.name = "tv",
.driver_name = "venc",
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = am3517_evm_panel_enable_tv,
- .platform_disable = am3517_evm_panel_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 563d5ab..cb3b078 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -189,15 +189,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
.num_gpios = 2,
@@ -233,8 +224,6 @@ static struct omap_dss_device cm_t35_tv_device = {
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = cm_t35_panel_enable_tv,
- .platform_disable = cm_t35_panel_disable_tv,
};
static struct omap_dss_device *cm_t35_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index dfb5e1b..a471476 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -201,22 +201,11 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.data = &omap3_evm_lcd_data,
};
-static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void omap3_evm_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device omap3_evm_tv_device = {
.name = "tv",
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = omap3_evm_enable_tv,
- .platform_disable = omap3_evm_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 621ace1..8f1b0a1 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -93,15 +93,6 @@ static void __init omap3_stalker_display_init(void)
return;
}
-static int omap3_stalker_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void omap3_stalker_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device omap3_stalker_tv_device = {
.name = "tv",
.driver_name = "venc",
@@ -111,8 +102,6 @@ static struct omap_dss_device omap3_stalker_tv_device = {
#elif defined(CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE)
.u.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
#endif
- .platform_enable = omap3_stalker_enable_tv,
- .platform_disable = omap3_stalker_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 30/33] OMAPDSS: VENC: remove platform_enable/disable calls
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The platform_enable/disable callbacks in board files for VENC omap_dss_device
instances don't do anything. Hence, we can remove these callbacks from the VENC
driver.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/venc.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 006caf3..1598d27 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -519,10 +519,6 @@ int omapdss_venc_display_enable(struct omap_dss_device *dssdev)
goto err0;
}
- if (dssdev->platform_enable)
- dssdev->platform_enable(dssdev);
-
-
r = venc_power_on(dssdev);
if (r)
goto err1;
@@ -533,8 +529,6 @@ int omapdss_venc_display_enable(struct omap_dss_device *dssdev)
return 0;
err1:
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
omap_dss_stop_device(dssdev);
err0:
mutex_unlock(&venc.venc_lock);
@@ -551,9 +545,6 @@ void omapdss_venc_display_disable(struct omap_dss_device *dssdev)
omap_dss_stop_device(dssdev);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
mutex_unlock(&venc.venc_lock);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 31/33] OMAPDSS: remove platform_enable/disable callbacks from omap_dss_device
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
None of the omapdss panel drivers call platform_enable/disable callbacks, and
none of the omap board files define these callbacks for any omap_dss_device.
Hence these callbacks can be removed form the omap_dss_device struct.
Signed-off-by: Archit Taneja <archit@ti.com>
---
include/video/omapdss.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index f0b65a5..e1ebb48 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -650,10 +650,6 @@ struct omap_dss_device {
enum omap_dss_display_state state;
enum omap_dss_audio_state audio_state;
-
- /* platform specific */
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
};
struct omap_dss_hdmi_data
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 32/33] arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tony Lindgren
gpio reset info is passed to the tfp410 panel driver via the panel's platform
data struct 'tfp410_platform_data'. The tfp driver doesn't use the reset_gpio
field in the omap4_panda_dvi_device struct. Remove this field.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index b073e8b..393aeef 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -52,7 +52,6 @@ static struct omap_dss_device omap4_panda_dvi_device = {
.driver_name = "tfp410",
.data = &omap4_dvi_panel,
.phy.dpi.data_lines = 24,
- .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
.channel = OMAP_DSS_CHANNEL_LCD2,
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* [PATCH 33/33] OMAPDSS: remove reset_gpio field from omap_dss_device
@ 2013-02-13 14:34 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-13 14:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The reset_gpio field isn't used by any panel driver to retrieve a reset gpio
number. All the panel drivers receive gpio data from their corresponding
platform_data structs. Remove the reset_gpio field.
Signed-off-by: Archit Taneja <archit@ti.com>
---
include/video/omapdss.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index e1ebb48..fe8672c 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -629,8 +629,6 @@ struct omap_dss_device {
struct rfbi_timings rfbi_timings;
} ctrl;
- int reset_gpio;
-
const char *name;
/* used to match device to driver */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 15:16 ` Igor Grinberg
-1 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-13 15:16 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev, Tony Lindgren
Hi Archit,
On 02/13/13 16:21, Archit Taneja wrote:
> The cm-t35 board file currently requests gpios required to configure the tdo35s
> panel, and provides platform_enable/disable callbacks to configure them.
>
> These tasks have been moved to the generic dpi panel driver itself and shouldn't
> be done in the board files.
>
> Remove the gpio requests and the platform callbacks from the board file.
> Add the gpio information to generic dpi panel's platform data so that it's
> passed to the panel driver.
>
> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
> enabled after a 50 millisecond delay. This code has been removed and is not
> taken care of in the generic panel driver. The impact of this needs to be
> tested. The panel's gpios are also not exported any more. Hence, they can't be
> accessed via sysfs interface.
Indeed, there is an impact - the LCD no longer works.
The reason for the LCD_EN gpio being pushed high after the 50ms delay,
is to get the LCD out of reset, so the SPI transaction will succeed
and initialize the LCD.
Now, when you remove the gpio handling for the LCD_EN pin,
the LCD no longer works.
I don't agree with this breakage.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> arch/arm/mach-omap2/board-cm-t35.c | 46 ++++--------------------------------
> 1 file changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
> index f940a79..563d5ab 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -189,32 +189,6 @@ static inline void cm_t35_init_nand(void) {}
> #define CM_T35_LCD_BL_GPIO 58
> #define CM_T35_DVI_EN_GPIO 54
>
> -static int lcd_enabled;
> -static int dvi_enabled;
> -
> -static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
> -{
> - if (dvi_enabled) {
> - printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> - return -EINVAL;
> - }
> -
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
> -
> - lcd_enabled = 1;
> -
> - return 0;
> -}
> -
> -static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
> -{
> - lcd_enabled = 0;
> -
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
> -}
> -
> static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
> {
> return 0;
> @@ -226,8 +200,11 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
>
> static struct panel_generic_dpi_data lcd_panel = {
> .name = "toppoly_tdo35s",
> - .platform_enable = cm_t35_panel_enable_lcd,
> - .platform_disable = cm_t35_panel_disable_lcd,
> + .num_gpios = 2,
> + .gpios = {
> + CM_T35_LCD_BL_GPIO,
> + CM_T35_LCD_EN_GPIO
> + },
> };
>
> static struct omap_dss_device cm_t35_lcd_device = {
> @@ -303,19 +280,6 @@ static void __init cm_t35_init_display(void)
> spi_register_board_info(cm_t35_lcd_spi_board_info,
> ARRAY_SIZE(cm_t35_lcd_spi_board_info));
>
> - err = gpio_request_array(cm_t35_dss_gpios,
> - ARRAY_SIZE(cm_t35_dss_gpios));
> - if (err) {
> - pr_err("CM-T35: failed to request DSS control GPIOs\n");
> - return;
> - }
> -
> - gpio_export(CM_T35_LCD_EN_GPIO, 0);
> - gpio_export(CM_T35_LCD_BL_GPIO, 0);
> -
> - msleep(50);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> -
> err = omap_display_init(&cm_t35_dss_data);
> if (err) {
> pr_err("CM-T35: failed to register DSS device\n");
>
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-13 15:16 ` Igor Grinberg
0 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-13 15:16 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev, Tony Lindgren
Hi Archit,
On 02/13/13 16:21, Archit Taneja wrote:
> The cm-t35 board file currently requests gpios required to configure the tdo35s
> panel, and provides platform_enable/disable callbacks to configure them.
>
> These tasks have been moved to the generic dpi panel driver itself and shouldn't
> be done in the board files.
>
> Remove the gpio requests and the platform callbacks from the board file.
> Add the gpio information to generic dpi panel's platform data so that it's
> passed to the panel driver.
>
> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
> enabled after a 50 millisecond delay. This code has been removed and is not
> taken care of in the generic panel driver. The impact of this needs to be
> tested. The panel's gpios are also not exported any more. Hence, they can't be
> accessed via sysfs interface.
Indeed, there is an impact - the LCD no longer works.
The reason for the LCD_EN gpio being pushed high after the 50ms delay,
is to get the LCD out of reset, so the SPI transaction will succeed
and initialize the LCD.
Now, when you remove the gpio handling for the LCD_EN pin,
the LCD no longer works.
I don't agree with this breakage.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> arch/arm/mach-omap2/board-cm-t35.c | 46 ++++--------------------------------
> 1 file changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
> index f940a79..563d5ab 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -189,32 +189,6 @@ static inline void cm_t35_init_nand(void) {}
> #define CM_T35_LCD_BL_GPIO 58
> #define CM_T35_DVI_EN_GPIO 54
>
> -static int lcd_enabled;
> -static int dvi_enabled;
> -
> -static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
> -{
> - if (dvi_enabled) {
> - printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> - return -EINVAL;
> - }
> -
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
> -
> - lcd_enabled = 1;
> -
> - return 0;
> -}
> -
> -static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
> -{
> - lcd_enabled = 0;
> -
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
> -}
> -
> static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
> {
> return 0;
> @@ -226,8 +200,11 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
>
> static struct panel_generic_dpi_data lcd_panel = {
> .name = "toppoly_tdo35s",
> - .platform_enable = cm_t35_panel_enable_lcd,
> - .platform_disable = cm_t35_panel_disable_lcd,
> + .num_gpios = 2,
> + .gpios = {
> + CM_T35_LCD_BL_GPIO,
> + CM_T35_LCD_EN_GPIO
> + },
> };
>
> static struct omap_dss_device cm_t35_lcd_device = {
> @@ -303,19 +280,6 @@ static void __init cm_t35_init_display(void)
> spi_register_board_info(cm_t35_lcd_spi_board_info,
> ARRAY_SIZE(cm_t35_lcd_spi_board_info));
>
> - err = gpio_request_array(cm_t35_dss_gpios,
> - ARRAY_SIZE(cm_t35_dss_gpios));
> - if (err) {
> - pr_err("CM-T35: failed to request DSS control GPIOs\n");
> - return;
> - }
> -
> - gpio_export(CM_T35_LCD_EN_GPIO, 0);
> - gpio_export(CM_T35_LCD_BL_GPIO, 0);
> -
> - msleep(50);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> -
> err = omap_display_init(&cm_t35_dss_data);
> if (err) {
> pr_err("CM-T35: failed to register DSS device\n");
>
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-13 15:16 ` Igor Grinberg
@ 2013-02-13 15:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-13 15:28 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On 2013-02-13 17:16, Igor Grinberg wrote:
> Hi Archit,
>
> On 02/13/13 16:21, Archit Taneja wrote:
>> The cm-t35 board file currently requests gpios required to configure the tdo35s
>> panel, and provides platform_enable/disable callbacks to configure them.
>>
>> These tasks have been moved to the generic dpi panel driver itself and shouldn't
>> be done in the board files.
>>
>> Remove the gpio requests and the platform callbacks from the board file.
>> Add the gpio information to generic dpi panel's platform data so that it's
>> passed to the panel driver.
>>
>> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
>> enabled after a 50 millisecond delay. This code has been removed and is not
>> taken care of in the generic panel driver. The impact of this needs to be
>> tested. The panel's gpios are also not exported any more. Hence, they can't be
>> accessed via sysfs interface.
>
> Indeed, there is an impact - the LCD no longer works.
> The reason for the LCD_EN gpio being pushed high after the 50ms delay,
> is to get the LCD out of reset, so the SPI transaction will succeed
> and initialize the LCD.
> Now, when you remove the gpio handling for the LCD_EN pin,
> the LCD no longer works.
So between what is the sleep done? It's not clear from the code. LCD_EN
needs to be 0 for 50ms, or...?
If the panel requires specific reset handling, does it work right even
currently when the panel is turned off and later turned on? The msleep
is only used at boot time.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-13 15:28 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-13 15:28 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On 2013-02-13 17:16, Igor Grinberg wrote:
> Hi Archit,
>
> On 02/13/13 16:21, Archit Taneja wrote:
>> The cm-t35 board file currently requests gpios required to configure the tdo35s
>> panel, and provides platform_enable/disable callbacks to configure them.
>>
>> These tasks have been moved to the generic dpi panel driver itself and shouldn't
>> be done in the board files.
>>
>> Remove the gpio requests and the platform callbacks from the board file.
>> Add the gpio information to generic dpi panel's platform data so that it's
>> passed to the panel driver.
>>
>> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
>> enabled after a 50 millisecond delay. This code has been removed and is not
>> taken care of in the generic panel driver. The impact of this needs to be
>> tested. The panel's gpios are also not exported any more. Hence, they can't be
>> accessed via sysfs interface.
>
> Indeed, there is an impact - the LCD no longer works.
> The reason for the LCD_EN gpio being pushed high after the 50ms delay,
> is to get the LCD out of reset, so the SPI transaction will succeed
> and initialize the LCD.
> Now, when you remove the gpio handling for the LCD_EN pin,
> the LCD no longer works.
So between what is the sleep done? It's not clear from the code. LCD_EN
needs to be 0 for 50ms, or...?
If the panel requires specific reset handling, does it work right even
currently when the panel is turned off and later turned on? The msleep
is only used at boot time.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-13 15:28 ` Tomi Valkeinen
@ 2013-02-13 15:59 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-13 15:59 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]
On 2013-02-13 17:28, Tomi Valkeinen wrote:
> On 2013-02-13 17:16, Igor Grinberg wrote:
>> Hi Archit,
>>
>> On 02/13/13 16:21, Archit Taneja wrote:
>>> The cm-t35 board file currently requests gpios required to configure the tdo35s
>>> panel, and provides platform_enable/disable callbacks to configure them.
>>>
>>> These tasks have been moved to the generic dpi panel driver itself and shouldn't
>>> be done in the board files.
>>>
>>> Remove the gpio requests and the platform callbacks from the board file.
>>> Add the gpio information to generic dpi panel's platform data so that it's
>>> passed to the panel driver.
>>>
>>> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
>>> enabled after a 50 millisecond delay. This code has been removed and is not
>>> taken care of in the generic panel driver. The impact of this needs to be
>>> tested. The panel's gpios are also not exported any more. Hence, they can't be
>>> accessed via sysfs interface.
>>
>> Indeed, there is an impact - the LCD no longer works.
>> The reason for the LCD_EN gpio being pushed high after the 50ms delay,
>> is to get the LCD out of reset, so the SPI transaction will succeed
>> and initialize the LCD.
>> Now, when you remove the gpio handling for the LCD_EN pin,
>> the LCD no longer works.
>
> So between what is the sleep done? It's not clear from the code. LCD_EN
> needs to be 0 for 50ms, or...?
>
> If the panel requires specific reset handling, does it work right even
> currently when the panel is turned off and later turned on? The msleep
> is only used at boot time.
Okay, so I just realized there's an spi backlight driver used here, and
that backlight driver is actually handling the SPI transactions with the
panel, instead of the panel driver. So this looks quite messed up.
For a quick solution, can we just set the LCD_EN at boot time (with the
msleep), and not touch it after that?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-13 15:59 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-13 15:59 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]
On 2013-02-13 17:28, Tomi Valkeinen wrote:
> On 2013-02-13 17:16, Igor Grinberg wrote:
>> Hi Archit,
>>
>> On 02/13/13 16:21, Archit Taneja wrote:
>>> The cm-t35 board file currently requests gpios required to configure the tdo35s
>>> panel, and provides platform_enable/disable callbacks to configure them.
>>>
>>> These tasks have been moved to the generic dpi panel driver itself and shouldn't
>>> be done in the board files.
>>>
>>> Remove the gpio requests and the platform callbacks from the board file.
>>> Add the gpio information to generic dpi panel's platform data so that it's
>>> passed to the panel driver.
>>>
>>> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
>>> enabled after a 50 millisecond delay. This code has been removed and is not
>>> taken care of in the generic panel driver. The impact of this needs to be
>>> tested. The panel's gpios are also not exported any more. Hence, they can't be
>>> accessed via sysfs interface.
>>
>> Indeed, there is an impact - the LCD no longer works.
>> The reason for the LCD_EN gpio being pushed high after the 50ms delay,
>> is to get the LCD out of reset, so the SPI transaction will succeed
>> and initialize the LCD.
>> Now, when you remove the gpio handling for the LCD_EN pin,
>> the LCD no longer works.
>
> So between what is the sleep done? It's not clear from the code. LCD_EN
> needs to be 0 for 50ms, or...?
>
> If the panel requires specific reset handling, does it work right even
> currently when the panel is turned off and later turned on? The msleep
> is only used at boot time.
Okay, so I just realized there's an spi backlight driver used here, and
that backlight driver is actually handling the SPI transactions with the
panel, instead of the panel driver. So this looks quite messed up.
For a quick solution, can we just set the LCD_EN at boot time (with the
msleep), and not touch it after that?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-02-13 14:33 ` Archit Taneja
@ 2013-02-13 16:46 ` Tony Lindgren
-1 siblings, 0 replies; 134+ messages in thread
From: Tony Lindgren @ 2013-02-13 16:46 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
* Archit Taneja <archit@ti.com> [130213 06:26]:
> init functions in omap board files request panel specific gpios, and provide
> functions which omapdss panel drivers call to enable or disable them.
>
> Instead of the board files requesting these gpios, they should just pass the
> platform specific data(like the gpio numbers), the panel should retrieve the
> platform data and request the gpios. Doing this prevents the need of the panel
> driver calling platform functions in board files.
>
> Panel drivers have their own platform data struct, and the board files populate
> these structs and pass the pointer to the 'data' field of omap_dss_device. This
> work will make it easier for the panel drivers be more adaptable to the
> DT model.
>
> There is also removal of passing panel reset_gpio numbers through
> omap_dss_device struct directly, reset gpios are passed through platform data
> only.
To avoid merge conflicts and dependencies between drivers and core
Soc code, please break thes kind of patches into following parts:
1. Any platform_data header changes needed so both I and Tomi
can pull it in as needed.
2. Changes to DSS drivers. Please keep stubs around for the
board specific callback functions so omap2plus_defconfig
won't break with just #1 merged into arm soc tree.
3. All the arch/arm/*omap* changes based on #1 above to
drop obsolete callback functions and add new pdata if still
needed. This needs to build and boot on #1 so I can merge
this in via arm soc tree.
4. Any .dts changes needed.
Regards,
Tony
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-02-13 16:46 ` Tony Lindgren
0 siblings, 0 replies; 134+ messages in thread
From: Tony Lindgren @ 2013-02-13 16:46 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
* Archit Taneja <archit@ti.com> [130213 06:26]:
> init functions in omap board files request panel specific gpios, and provide
> functions which omapdss panel drivers call to enable or disable them.
>
> Instead of the board files requesting these gpios, they should just pass the
> platform specific data(like the gpio numbers), the panel should retrieve the
> platform data and request the gpios. Doing this prevents the need of the panel
> driver calling platform functions in board files.
>
> Panel drivers have their own platform data struct, and the board files populate
> these structs and pass the pointer to the 'data' field of omap_dss_device. This
> work will make it easier for the panel drivers be more adaptable to the
> DT model.
>
> There is also removal of passing panel reset_gpio numbers through
> omap_dss_device struct directly, reset gpios are passed through platform data
> only.
To avoid merge conflicts and dependencies between drivers and core
Soc code, please break thes kind of patches into following parts:
1. Any platform_data header changes needed so both I and Tomi
can pull it in as needed.
2. Changes to DSS drivers. Please keep stubs around for the
board specific callback functions so omap2plus_defconfig
won't break with just #1 merged into arm soc tree.
3. All the arch/arm/*omap* changes based on #1 above to
drop obsolete callback functions and add new pdata if still
needed. This needs to build and boot on #1 so I can merge
this in via arm soc tree.
4. Any .dts changes needed.
Regards,
Tony
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
2013-02-13 14:34 ` Archit Taneja
@ 2013-02-13 17:29 ` Aaro Koskinen
-1 siblings, 0 replies; 134+ messages in thread
From: Aaro Koskinen @ 2013-02-13 17:29 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
> +static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device *dssdev)
> +{
> + return (struct panel_acx565akm_data *) dssdev->data;
> +}
> +
> static int acx_panel_probe(struct omap_dss_device *dssdev)
> {
> int r;
> struct acx565akm_device *md = &acx_dev;
> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
Why the get_panel_data function is needed, isn't the cast unnecessary?
A.
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
@ 2013-02-13 17:29 ` Aaro Koskinen
0 siblings, 0 replies; 134+ messages in thread
From: Aaro Koskinen @ 2013-02-13 17:29 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
> +static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device *dssdev)
> +{
> + return (struct panel_acx565akm_data *) dssdev->data;
> +}
> +
> static int acx_panel_probe(struct omap_dss_device *dssdev)
> {
> int r;
> struct acx565akm_device *md = &acx_dev;
> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
Why the get_panel_data function is needed, isn't the cast unnecessary?
A.
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
2013-02-13 14:34 ` Archit Taneja
@ 2013-02-13 17:35 ` Aaro Koskinen
-1 siblings, 0 replies; 134+ messages in thread
From: Aaro Koskinen @ 2013-02-13 17:35 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
Hi,
On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
> @@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
> dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
> dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
>
> + if (gpio_is_valid(bdata->panel_reset)) {
> + r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
> + GPIOF_OUT_INIT_LOW, "PANEL RESET");
> + if (r)
> + return r;
> + }
> +
> + if (gpio_is_valid(bdata->ctrl_pwrdown)) {
> + r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
> + GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
> + if (r)
> + return r;
> + }
> +
In the error case, the other GPIO is not freed. Also maybe you should
free them on module removal, because now the module owns the GPIOs.
A.
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
@ 2013-02-13 17:35 ` Aaro Koskinen
0 siblings, 0 replies; 134+ messages in thread
From: Aaro Koskinen @ 2013-02-13 17:35 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
Hi,
On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
> @@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
> dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
> dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
>
> + if (gpio_is_valid(bdata->panel_reset)) {
> + r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
> + GPIOF_OUT_INIT_LOW, "PANEL RESET");
> + if (r)
> + return r;
> + }
> +
> + if (gpio_is_valid(bdata->ctrl_pwrdown)) {
> + r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
> + GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
> + if (r)
> + return r;
> + }
> +
In the error case, the other GPIO is not freed. Also maybe you should
free them on module removal, because now the module owns the GPIOs.
A.
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
2013-02-13 17:35 ` Aaro Koskinen
@ 2013-02-14 6:46 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-14 6:34 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
Hi,
On Wednesday 13 February 2013 11:05 PM, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
>> @@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
>> dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
>> dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
>>
>> + if (gpio_is_valid(bdata->panel_reset)) {
>> + r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
>> + GPIOF_OUT_INIT_LOW, "PANEL RESET");
>> + if (r)
>> + return r;
>> + }
>> +
>> + if (gpio_is_valid(bdata->ctrl_pwrdown)) {
>> + r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
>> + GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
>> + if (r)
>> + return r;
>> + }
>> +
>
> In the error case, the other GPIO is not freed. Also maybe you should
> free them on module removal, because now the module owns the GPIOs.
Wouldn't the usage of devm_* functions take care of this? If the device
isn't registered successfully, then all allocations/requests done using
devm_* functions will be free'd automatically.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
@ 2013-02-14 6:46 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-14 6:46 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
Hi,
On Wednesday 13 February 2013 11:05 PM, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
>> @@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
>> dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
>> dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
>>
>> + if (gpio_is_valid(bdata->panel_reset)) {
>> + r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
>> + GPIOF_OUT_INIT_LOW, "PANEL RESET");
>> + if (r)
>> + return r;
>> + }
>> +
>> + if (gpio_is_valid(bdata->ctrl_pwrdown)) {
>> + r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
>> + GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
>> + if (r)
>> + return r;
>> + }
>> +
>
> In the error case, the other GPIO is not freed. Also maybe you should
> free them on module removal, because now the module owns the GPIOs.
Wouldn't the usage of devm_* functions take care of this? If the device
isn't registered successfully, then all allocations/requests done using
devm_* functions will be free'd automatically.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
2013-02-13 17:29 ` Aaro Koskinen
@ 2013-02-14 6:52 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-14 6:51 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>> +static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device *dssdev)
>> +{
>> + return (struct panel_acx565akm_data *) dssdev->data;
>> +}
>> +
>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>> {
>> int r;
>> struct acx565akm_device *md = &acx_dev;
>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>
> Why the get_panel_data function is needed, isn't the cast unnecessary?
the 'data' member of omap_dss_device has the type 'void *', we need to
cast it to access the panel_acx565akm_data struct pointer.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
@ 2013-02-14 6:52 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-14 6:52 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>> +static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device *dssdev)
>> +{
>> + return (struct panel_acx565akm_data *) dssdev->data;
>> +}
>> +
>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>> {
>> int r;
>> struct acx565akm_device *md = &acx_dev;
>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>
> Why the get_panel_data function is needed, isn't the cast unnecessary?
the 'data' member of omap_dss_device has the type 'void *', we need to
cast it to access the panel_acx565akm_data struct pointer.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-13 15:59 ` Tomi Valkeinen
@ 2013-02-14 6:56 ` Igor Grinberg
-1 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 6:56 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/13/13 17:59, Tomi Valkeinen wrote:
> On 2013-02-13 17:28, Tomi Valkeinen wrote:
>> On 2013-02-13 17:16, Igor Grinberg wrote:
>>> Hi Archit,
>>>
>>> On 02/13/13 16:21, Archit Taneja wrote:
>>>> The cm-t35 board file currently requests gpios required to configure the tdo35s
>>>> panel, and provides platform_enable/disable callbacks to configure them.
>>>>
>>>> These tasks have been moved to the generic dpi panel driver itself and shouldn't
>>>> be done in the board files.
>>>>
>>>> Remove the gpio requests and the platform callbacks from the board file.
>>>> Add the gpio information to generic dpi panel's platform data so that it's
>>>> passed to the panel driver.
>>>>
>>>> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
>>>> enabled after a 50 millisecond delay. This code has been removed and is not
>>>> taken care of in the generic panel driver. The impact of this needs to be
>>>> tested. The panel's gpios are also not exported any more. Hence, they can't be
>>>> accessed via sysfs interface.
>>>
>>> Indeed, there is an impact - the LCD no longer works.
>>> The reason for the LCD_EN gpio being pushed high after the 50ms delay,
>>> is to get the LCD out of reset, so the SPI transaction will succeed
>>> and initialize the LCD.
>>> Now, when you remove the gpio handling for the LCD_EN pin,
>>> the LCD no longer works.
>>
>> So between what is the sleep done? It's not clear from the code. LCD_EN
>> needs to be 0 for 50ms, or...?
>>
>> If the panel requires specific reset handling, does it work right even
>> currently when the panel is turned off and later turned on? The msleep
>> is only used at boot time.
>
> Okay, so I just realized there's an spi backlight driver used here, and
> that backlight driver is actually handling the SPI transactions with the
> panel, instead of the panel driver. So this looks quite messed up.
Yep, it always was.
The whole DSS specific panel handling inside the
drivers/video/omap2/displays is a mess.
Those panels can be (and are) used not only with OMAP based boards.
>
> For a quick solution, can we just set the LCD_EN at boot time (with the
> msleep), and not touch it after that?
That would be sensible for now, so this series can be merged.
As a more appropriate (and long term) solution,
I plan on moving the panel reset pin handling to the spi backlight
driver itself.
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHIqCAAoJEBDE8YO64Efamw0P/R2wt0tpCI1ecrnutVGMX4bF
Pyjk2B65uDWqoqZ/cpJUqnvmupXl5UdrA7eqKjTBh1A+g81UVFcNDMuJsbPIIiYI
1pimZieAq0T6Vag00PKImKlkhJYfC7JVBbESij/NONlzYtPkbZ91Y+Ik4DZXnyZf
1TS4GbHQ25tjl73PkwlzLUcJIDIogsimSrkM+aWXPE8LmvrBEQs0LhAObPsAFtgL
1An3hvA2Tkhh9QgerWQd9YiqX994tv1PGRLBEXTbjh1yihzKSNleuvw3NdM+wf9i
9Y5l9IV6L2dtYBMLCpzkiGQBDdOzoq+fObRnSgK6Kr1mfXot+MAlLrk9gCeWcq1b
c2oU/imKWB4sZys21pTnjIxAIzzRDoGW40qXuibTW4DoAYaVHuEBPtphjMVCBCcQ
sJaIVXpsChQ3vvtHOgllnInMjCnlXJ3Piqr4y5glTPxu9mZHdPr6VDpWdqRmvyr9
V7fRQztwXB3Td+SZVDD1yBqoXKlKCX4QPlLAqH3FI9s1WhDHcJePcoDJY0/QyXB1
IeQRlEwBBEZAYy/kr9/pwbZzXeh5V5dK6wAq8aT+thS22zl3nJbKjW//vN06+ib+
WAnHRSZ8iCbUX2cRVF1k+DCQOTi8QCbI6WTcLsgenLeSrbEuzilfgsrsvd6LHfjD
oTODiiD9QInP2sBfknUp
=tWsB
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 6:56 ` Igor Grinberg
0 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 6:56 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/13/13 17:59, Tomi Valkeinen wrote:
> On 2013-02-13 17:28, Tomi Valkeinen wrote:
>> On 2013-02-13 17:16, Igor Grinberg wrote:
>>> Hi Archit,
>>>
>>> On 02/13/13 16:21, Archit Taneja wrote:
>>>> The cm-t35 board file currently requests gpios required to configure the tdo35s
>>>> panel, and provides platform_enable/disable callbacks to configure them.
>>>>
>>>> These tasks have been moved to the generic dpi panel driver itself and shouldn't
>>>> be done in the board files.
>>>>
>>>> Remove the gpio requests and the platform callbacks from the board file.
>>>> Add the gpio information to generic dpi panel's platform data so that it's
>>>> passed to the panel driver.
>>>>
>>>> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
>>>> enabled after a 50 millisecond delay. This code has been removed and is not
>>>> taken care of in the generic panel driver. The impact of this needs to be
>>>> tested. The panel's gpios are also not exported any more. Hence, they can't be
>>>> accessed via sysfs interface.
>>>
>>> Indeed, there is an impact - the LCD no longer works.
>>> The reason for the LCD_EN gpio being pushed high after the 50ms delay,
>>> is to get the LCD out of reset, so the SPI transaction will succeed
>>> and initialize the LCD.
>>> Now, when you remove the gpio handling for the LCD_EN pin,
>>> the LCD no longer works.
>>
>> So between what is the sleep done? It's not clear from the code. LCD_EN
>> needs to be 0 for 50ms, or...?
>>
>> If the panel requires specific reset handling, does it work right even
>> currently when the panel is turned off and later turned on? The msleep
>> is only used at boot time.
>
> Okay, so I just realized there's an spi backlight driver used here, and
> that backlight driver is actually handling the SPI transactions with the
> panel, instead of the panel driver. So this looks quite messed up.
Yep, it always was.
The whole DSS specific panel handling inside the
drivers/video/omap2/displays is a mess.
Those panels can be (and are) used not only with OMAP based boards.
>
> For a quick solution, can we just set the LCD_EN at boot time (with the
> msleep), and not touch it after that?
That would be sensible for now, so this series can be merged.
As a more appropriate (and long term) solution,
I plan on moving the panel reset pin handling to the spi backlight
driver itself.
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHIqCAAoJEBDE8YO64Efamw0P/R2wt0tpCI1ecrnutVGMX4bF
Pyjk2B65uDWqoqZ/cpJUqnvmupXl5UdrA7eqKjTBh1A+g81UVFcNDMuJsbPIIiYI
1pimZieAq0T6Vag00PKImKlkhJYfC7JVBbESij/NONlzYtPkbZ91Y+Ik4DZXnyZf
1TS4GbHQ25tjl73PkwlzLUcJIDIogsimSrkM+aWXPE8LmvrBEQs0LhAObPsAFtgL
1An3hvA2Tkhh9QgerWQd9YiqX994tv1PGRLBEXTbjh1yihzKSNleuvw3NdM+wf9i
9Y5l9IV6L2dtYBMLCpzkiGQBDdOzoq+fObRnSgK6Kr1mfXot+MAlLrk9gCeWcq1b
c2oU/imKWB4sZys21pTnjIxAIzzRDoGW40qXuibTW4DoAYaVHuEBPtphjMVCBCcQ
sJaIVXpsChQ3vvtHOgllnInMjCnlXJ3Piqr4y5glTPxu9mZHdPr6VDpWdqRmvyr9
V7fRQztwXB3Td+SZVDD1yBqoXKlKCX4QPlLAqH3FI9s1WhDHcJePcoDJY0/QyXB1
IeQRlEwBBEZAYy/kr9/pwbZzXeh5V5dK6wAq8aT+thS22zl3nJbKjW//vN06+ib+
WAnHRSZ8iCbUX2cRVF1k+DCQOTi8QCbI6WTcLsgenLeSrbEuzilfgsrsvd6LHfjD
oTODiiD9QInP2sBfknUp
=tWsB
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
2013-02-14 6:52 ` Archit Taneja
@ 2013-02-14 6:58 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 6:58 UTC (permalink / raw)
To: Archit Taneja; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
On 2013-02-14 08:51, Archit Taneja wrote:
> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>> Hi,
>>
>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>> omap_dss_device *dssdev)
>>> +{
>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>> +}
>>> +
>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>> {
>>> int r;
>>> struct acx565akm_device *md = &acx_dev;
>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>
>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>
> the 'data' member of omap_dss_device has the type 'void *', we need to
> cast it to access the panel_acx565akm_data struct pointer.
You don't need an explicit cast to assign a void pointer to a pointer to
something else (or vice versa, I think).
I remember us having similar constructs in some other panel drivers
also. I think they are unnecessary also.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
@ 2013-02-14 6:58 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 6:58 UTC (permalink / raw)
To: Archit Taneja; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
On 2013-02-14 08:51, Archit Taneja wrote:
> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>> Hi,
>>
>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>> omap_dss_device *dssdev)
>>> +{
>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>> +}
>>> +
>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>> {
>>> int r;
>>> struct acx565akm_device *md = &acx_dev;
>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>
>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>
> the 'data' member of omap_dss_device has the type 'void *', we need to
> cast it to access the panel_acx565akm_data struct pointer.
You don't need an explicit cast to assign a void pointer to a pointer to
something else (or vice versa, I think).
I remember us having similar constructs in some other panel drivers
also. I think they are unnecessary also.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
2013-02-14 6:58 ` Tomi Valkeinen
@ 2013-02-14 7:20 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-14 7:08 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
> On 2013-02-14 08:51, Archit Taneja wrote:
>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>> Hi,
>>>
>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>> omap_dss_device *dssdev)
>>>> +{
>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>> +}
>>>> +
>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>> {
>>>> int r;
>>>> struct acx565akm_device *md = &acx_dev;
>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>
>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>
>> the 'data' member of omap_dss_device has the type 'void *', we need to
>> cast it to access the panel_acx565akm_data struct pointer.
>
> You don't need an explicit cast to assign a void pointer to a pointer to
> something else (or vice versa, I think).
>
> I remember us having similar constructs in some other panel drivers
> also. I think they are unnecessary also.
Ah okay, I'll take care of it.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 6:56 ` Igor Grinberg
@ 2013-02-14 7:09 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 7:09 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]
On 2013-02-14 08:56, Igor Grinberg wrote:
> On 02/13/13 17:59, Tomi Valkeinen wrote:
>> Okay, so I just realized there's an spi backlight driver used here, and
>> that backlight driver is actually handling the SPI transactions with the
>> panel, instead of the panel driver. So this looks quite messed up.
>
> Yep, it always was.
> The whole DSS specific panel handling inside the
> drivers/video/omap2/displays is a mess.
Well, that's not mess itself, it's just omap specific panel framework.
But dividing single device handling into two separate places is a mess.
> Those panels can be (and are) used not only with OMAP based boards.
True, but as there's no generic panel framework, that's the best we can
do. But see CDF (common display framework) discussions if you're
interested in what's hopefully coming soon.
>> For a quick solution, can we just set the LCD_EN at boot time (with the
>> msleep), and not touch it after that?
>
> That would be sensible for now, so this series can be merged.
> As a more appropriate (and long term) solution,
> I plan on moving the panel reset pin handling to the spi backlight
> driver itself.
Well, if you must. But I suggest moving the whole panel handling into a
(omap specific) panel driver, as it's done for other panels. That way
you'll have a proper panel driver for it, for omap, and when CDF comes,
you'll get a platform independent panel driver for it.
Of course, if you have multiple platforms already using that backlight
driver, the omap specific approach may not be enticing. So perhaps it's
easier to just do the quick fix and wait for CDF.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 7:09 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 7:09 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]
On 2013-02-14 08:56, Igor Grinberg wrote:
> On 02/13/13 17:59, Tomi Valkeinen wrote:
>> Okay, so I just realized there's an spi backlight driver used here, and
>> that backlight driver is actually handling the SPI transactions with the
>> panel, instead of the panel driver. So this looks quite messed up.
>
> Yep, it always was.
> The whole DSS specific panel handling inside the
> drivers/video/omap2/displays is a mess.
Well, that's not mess itself, it's just omap specific panel framework.
But dividing single device handling into two separate places is a mess.
> Those panels can be (and are) used not only with OMAP based boards.
True, but as there's no generic panel framework, that's the best we can
do. But see CDF (common display framework) discussions if you're
interested in what's hopefully coming soon.
>> For a quick solution, can we just set the LCD_EN at boot time (with the
>> msleep), and not touch it after that?
>
> That would be sensible for now, so this series can be merged.
> As a more appropriate (and long term) solution,
> I plan on moving the panel reset pin handling to the spi backlight
> driver itself.
Well, if you must. But I suggest moving the whole panel handling into a
(omap specific) panel driver, as it's done for other panels. That way
you'll have a proper panel driver for it, for omap, and when CDF comes,
you'll get a platform independent panel driver for it.
Of course, if you have multiple platforms already using that backlight
driver, the omap specific approach may not be enticing. So perhaps it's
easier to just do the quick fix and wait for CDF.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-02-13 16:46 ` Tony Lindgren
@ 2013-02-14 7:29 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-14 7:17 UTC (permalink / raw)
To: Tony Lindgren; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
Hi,
On Wednesday 13 February 2013 10:16 PM, Tony Lindgren wrote:
> * Archit Taneja <archit@ti.com> [130213 06:26]:
>> init functions in omap board files request panel specific gpios, and provide
>> functions which omapdss panel drivers call to enable or disable them.
>>
>> Instead of the board files requesting these gpios, they should just pass the
>> platform specific data(like the gpio numbers), the panel should retrieve the
>> platform data and request the gpios. Doing this prevents the need of the panel
>> driver calling platform functions in board files.
>>
>> Panel drivers have their own platform data struct, and the board files populate
>> these structs and pass the pointer to the 'data' field of omap_dss_device. This
>> work will make it easier for the panel drivers be more adaptable to the
>> DT model.
>>
>> There is also removal of passing panel reset_gpio numbers through
>> omap_dss_device struct directly, reset gpios are passed through platform data
>> only.
>
> To avoid merge conflicts and dependencies between drivers and core
> Soc code, please break thes kind of patches into following parts:
>
> 1. Any platform_data header changes needed so both I and Tomi
> can pull it in as needed.
>
> 2. Changes to DSS drivers. Please keep stubs around for the
> board specific callback functions so omap2plus_defconfig
> won't break with just #1 merged into arm soc tree.
The build won't break, and the kernel will boot up properly, but the
panels won't work till the time #3 is also merged,
>
> 3. All the arch/arm/*omap* changes based on #1 above to
> drop obsolete callback functions and add new pdata if still
> needed. This needs to build and boot on #1 so I can merge
> this in via arm soc tree.
>
> 4. Any .dts changes needed.
We don't have any .dts changes for DSS as of now.
I'll split the patches accordingly.
Thanks,
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
@ 2013-02-14 7:20 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-14 7:20 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
> On 2013-02-14 08:51, Archit Taneja wrote:
>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>> Hi,
>>>
>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>> omap_dss_device *dssdev)
>>>> +{
>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>> +}
>>>> +
>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>> {
>>>> int r;
>>>> struct acx565akm_device *md = &acx_dev;
>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>
>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>
>> the 'data' member of omap_dss_device has the type 'void *', we need to
>> cast it to access the panel_acx565akm_data struct pointer.
>
> You don't need an explicit cast to assign a void pointer to a pointer to
> something else (or vice versa, I think).
>
> I remember us having similar constructs in some other panel drivers
> also. I think they are unnecessary also.
Ah okay, I'll take care of it.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-02-14 7:29 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-14 7:29 UTC (permalink / raw)
To: Tony Lindgren; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
Hi,
On Wednesday 13 February 2013 10:16 PM, Tony Lindgren wrote:
> * Archit Taneja <archit@ti.com> [130213 06:26]:
>> init functions in omap board files request panel specific gpios, and provide
>> functions which omapdss panel drivers call to enable or disable them.
>>
>> Instead of the board files requesting these gpios, they should just pass the
>> platform specific data(like the gpio numbers), the panel should retrieve the
>> platform data and request the gpios. Doing this prevents the need of the panel
>> driver calling platform functions in board files.
>>
>> Panel drivers have their own platform data struct, and the board files populate
>> these structs and pass the pointer to the 'data' field of omap_dss_device. This
>> work will make it easier for the panel drivers be more adaptable to the
>> DT model.
>>
>> There is also removal of passing panel reset_gpio numbers through
>> omap_dss_device struct directly, reset gpios are passed through platform data
>> only.
>
> To avoid merge conflicts and dependencies between drivers and core
> Soc code, please break thes kind of patches into following parts:
>
> 1. Any platform_data header changes needed so both I and Tomi
> can pull it in as needed.
>
> 2. Changes to DSS drivers. Please keep stubs around for the
> board specific callback functions so omap2plus_defconfig
> won't break with just #1 merged into arm soc tree.
The build won't break, and the kernel will boot up properly, but the
panels won't work till the time #3 is also merged,
>
> 3. All the arch/arm/*omap* changes based on #1 above to
> drop obsolete callback functions and add new pdata if still
> needed. This needs to build and boot on #1 so I can merge
> this in via arm soc tree.
>
> 4. Any .dts changes needed.
We don't have any .dts changes for DSS as of now.
I'll split the patches accordingly.
Thanks,
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 7:09 ` Tomi Valkeinen
@ 2013-02-14 8:37 ` Igor Grinberg
-1 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 8:37 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 09:09, Tomi Valkeinen wrote:
> On 2013-02-14 08:56, Igor Grinberg wrote:
>> On 02/13/13 17:59, Tomi Valkeinen wrote:
>
>>> Okay, so I just realized there's an spi backlight driver used here, and
>>> that backlight driver is actually handling the SPI transactions with the
>>> panel, instead of the panel driver. So this looks quite messed up.
>>
>> Yep, it always was.
>> The whole DSS specific panel handling inside the
>> drivers/video/omap2/displays is a mess.
>
> Well, that's not mess itself, it's just omap specific panel framework.
> But dividing single device handling into two separate places is a mess.
Yes, you are right it is not the mess, but it prevents the panel to
be used on other systems and that is BAD.
At the very least, drivers/video/backlight is a generic place that can be
used not just on OMAP.
And since the toppoly was and is used on other systems, why the hell
should anyone duplicate the driver just to please the OMAP specific
panel framework? The real problem is that this framework should not be
OMAP specific...
Of course I'm aware of the fact that currently there is no generic
panel framework, but forging something OMAP specific which is obviously
used on most of the other architectures/platforms (and I mean
panel<->controller relations), is not a good way to go.
Although, I'm also aware of the fact that most things are done this way:
do several specific drivers/frameworks, find the common stuff, and extract
it into a core driver/framework. So I don't want to blame anyone - that's
just the way how we do things, right?
>
>> Those panels can be (and are) used not only with OMAP based boards.
>
> True, but as there's no generic panel framework, that's the best we can
> do. But see CDF (common display framework) discussions if you're
> interested in what's hopefully coming soon.
Yep, I've seen the CDF discussion and I think this is a good way to go.
>
>>> For a quick solution, can we just set the LCD_EN at boot time (with the
>>> msleep), and not touch it after that?
>>
>> That would be sensible for now, so this series can be merged.
>> As a more appropriate (and long term) solution,
>> I plan on moving the panel reset pin handling to the spi backlight
>> driver itself.
>
> Well, if you must. But I suggest moving the whole panel handling into a
> (omap specific) panel driver, as it's done for other panels. That way
> you'll have a proper panel driver for it, for omap, and when CDF comes,
> you'll get a platform independent panel driver for it.
You can't just move generic architecture/platform independent stuff
into OMAP specific framework... Just think about this... It's insane.
>
> Of course, if you have multiple platforms already using that backlight
> driver, the omap specific approach may not be enticing. So perhaps it's
> easier to just do the quick fix and wait for CDF.
That is exactly what I am talking about.
In addition, AFAIR, the reset pin is the property of the toppoly panel
hardware, so that is why I think, we should let the toppoly driver
(currently spi backlight, later hopefully CDF) handle it correctly
along with the spi sequences.
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHKJGAAoJEBDE8YO64EfacksP/j79jaDbnXpFcwT9KlInp8OE
e+XNi5Vt8zbqhj4gHtxZlN/eIQsVRfuivm9CTp5aJSZHBDAJlPNKobmwjFrDLO9V
RtYTwLAcuWyOdnutIQ52xNwXSntQknd8yxm1qJZMEBjEP+mcQxISWXXMsdxlQEiT
emNtU42W16ZOR34kHUoVfYLkV0v02/JVygt3oaU71+mrNBOt+5L6cHcXaQZPKSes
LUOcyz0qJfzKbnmmZnP/+clTIids83u8rVCNZ1/JoIIlR4rvtNcxRM8Apa8KFJx/
PVT38ds62F0L0qbxL3UmI1uJS2KuEHuJyjYo0uDeQqeeSyz7Q3ZG4TwAJYkWZdWQ
TdFbVrsXbK408FT33VIP4rOzDjqO93IK6f5ld0tZoIvL59NLwgXIejJn6jTNNcU4
p25mUXGSDnaZrNU5cC7d/MzSMt60XQx3UiHjEXD3eJAT33yb+DdBaQwloMCXJQOx
vnseFqhuAzgFHd9LEl47LBg7eXudjaSvWYfJOV0SoB9s7QM8m/YUhnmqmtvdCqZL
fKMJcAjCgm0BG2P6ss79sl6P4XDoBF1LOwSwz4dRmocA3TP7vBNkuRoK08vQe6gv
Qi7hJ05ioa8THt77FxMHtf+ZrO34/L6gHxZqrOD++OgPPdL6qtegemyp4IaKKbUg
q3Mpgsr4ODyStdjEXxTC
=lIHm
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 8:37 ` Igor Grinberg
0 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 8:37 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 09:09, Tomi Valkeinen wrote:
> On 2013-02-14 08:56, Igor Grinberg wrote:
>> On 02/13/13 17:59, Tomi Valkeinen wrote:
>
>>> Okay, so I just realized there's an spi backlight driver used here, and
>>> that backlight driver is actually handling the SPI transactions with the
>>> panel, instead of the panel driver. So this looks quite messed up.
>>
>> Yep, it always was.
>> The whole DSS specific panel handling inside the
>> drivers/video/omap2/displays is a mess.
>
> Well, that's not mess itself, it's just omap specific panel framework.
> But dividing single device handling into two separate places is a mess.
Yes, you are right it is not the mess, but it prevents the panel to
be used on other systems and that is BAD.
At the very least, drivers/video/backlight is a generic place that can be
used not just on OMAP.
And since the toppoly was and is used on other systems, why the hell
should anyone duplicate the driver just to please the OMAP specific
panel framework? The real problem is that this framework should not be
OMAP specific...
Of course I'm aware of the fact that currently there is no generic
panel framework, but forging something OMAP specific which is obviously
used on most of the other architectures/platforms (and I mean
panel<->controller relations), is not a good way to go.
Although, I'm also aware of the fact that most things are done this way:
do several specific drivers/frameworks, find the common stuff, and extract
it into a core driver/framework. So I don't want to blame anyone - that's
just the way how we do things, right?
>
>> Those panels can be (and are) used not only with OMAP based boards.
>
> True, but as there's no generic panel framework, that's the best we can
> do. But see CDF (common display framework) discussions if you're
> interested in what's hopefully coming soon.
Yep, I've seen the CDF discussion and I think this is a good way to go.
>
>>> For a quick solution, can we just set the LCD_EN at boot time (with the
>>> msleep), and not touch it after that?
>>
>> That would be sensible for now, so this series can be merged.
>> As a more appropriate (and long term) solution,
>> I plan on moving the panel reset pin handling to the spi backlight
>> driver itself.
>
> Well, if you must. But I suggest moving the whole panel handling into a
> (omap specific) panel driver, as it's done for other panels. That way
> you'll have a proper panel driver for it, for omap, and when CDF comes,
> you'll get a platform independent panel driver for it.
You can't just move generic architecture/platform independent stuff
into OMAP specific framework... Just think about this... It's insane.
>
> Of course, if you have multiple platforms already using that backlight
> driver, the omap specific approach may not be enticing. So perhaps it's
> easier to just do the quick fix and wait for CDF.
That is exactly what I am talking about.
In addition, AFAIR, the reset pin is the property of the toppoly panel
hardware, so that is why I think, we should let the toppoly driver
(currently spi backlight, later hopefully CDF) handle it correctly
along with the spi sequences.
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHKJGAAoJEBDE8YO64EfacksP/j79jaDbnXpFcwT9KlInp8OE
e+XNi5Vt8zbqhj4gHtxZlN/eIQsVRfuivm9CTp5aJSZHBDAJlPNKobmwjFrDLO9V
RtYTwLAcuWyOdnutIQ52xNwXSntQknd8yxm1qJZMEBjEP+mcQxISWXXMsdxlQEiT
emNtU42W16ZOR34kHUoVfYLkV0v02/JVygt3oaU71+mrNBOt+5L6cHcXaQZPKSes
LUOcyz0qJfzKbnmmZnP/+clTIids83u8rVCNZ1/JoIIlR4rvtNcxRM8Apa8KFJx/
PVT38ds62F0L0qbxL3UmI1uJS2KuEHuJyjYo0uDeQqeeSyz7Q3ZG4TwAJYkWZdWQ
TdFbVrsXbK408FT33VIP4rOzDjqO93IK6f5ld0tZoIvL59NLwgXIejJn6jTNNcU4
p25mUXGSDnaZrNU5cC7d/MzSMt60XQx3UiHjEXD3eJAT33yb+DdBaQwloMCXJQOx
vnseFqhuAzgFHd9LEl47LBg7eXudjaSvWYfJOV0SoB9s7QM8m/YUhnmqmtvdCqZL
fKMJcAjCgm0BG2P6ss79sl6P4XDoBF1LOwSwz4dRmocA3TP7vBNkuRoK08vQe6gv
Qi7hJ05ioa8THt77FxMHtf+ZrO34/L6gHxZqrOD++OgPPdL6qtegemyp4IaKKbUg
q3Mpgsr4ODyStdjEXxTC
=lIHm
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 8:37 ` Igor Grinberg
@ 2013-02-14 9:09 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 9:09 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 4247 bytes --]
On 2013-02-14 10:37, Igor Grinberg wrote:
> On 02/14/13 09:09, Tomi Valkeinen wrote:
>> On 2013-02-14 08:56, Igor Grinberg wrote:
>>> On 02/13/13 17:59, Tomi Valkeinen wrote:
>
>>>> Okay, so I just realized there's an spi backlight driver used here, and
>>>> that backlight driver is actually handling the SPI transactions with the
>>>> panel, instead of the panel driver. So this looks quite messed up.
>>>
>>> Yep, it always was.
>>> The whole DSS specific panel handling inside the
>>> drivers/video/omap2/displays is a mess.
>
>> Well, that's not mess itself, it's just omap specific panel framework.
>> But dividing single device handling into two separate places is a mess.
>
> Yes, you are right it is not the mess, but it prevents the panel to
> be used on other systems and that is BAD.
> At the very least, drivers/video/backlight is a generic place that can be
> used not just on OMAP.
True, it's generic, but does it work reliably? The panel hardware is now
partly handled in the backlight driver, and partly in the omap's panel
driver (and wherever on other platforms).
At least currently there's a dependency between the two, as the LCD_EN
gpio is handled by the panel driver, which affects the functioning of
the backlight driver. Is it ensured that the panel driver does not
disable the panel when the backlight driver does spi transactions?
That's what I meant with the mess, it's difficult to make it work
reliably. I know that for some panels such a two-driver approach would
not work at all. Although I guess it's working well enough for you for
this panel.
Thinking about it, if you do move the gpio handling to the backlight
driver, the panel driver will only handle the DPI video stream. Then it
should not have any effect on the SPI side (presuming the panel doesn't
use the pixel clock as func clock), although there's probably still
possibility for display artifacts on enable and disable, if the order of
operations goes the wrong way.
> And since the toppoly was and is used on other systems, why the hell
> should anyone duplicate the driver just to please the OMAP specific
> panel framework? The real problem is that this framework should not be
Not to please. To make it reliable.
> OMAP specific...
> Of course I'm aware of the fact that currently there is no generic
> panel framework, but forging something OMAP specific which is obviously
> used on most of the other architectures/platforms (and I mean
> panel<->controller relations), is not a good way to go.
Well, if duplicating the code gives us reliable drivers, versus
unreliable without duplicating, then... I don't see it as that bad.
> Although, I'm also aware of the fact that most things are done this way:
> do several specific drivers/frameworks, find the common stuff, and extract
> it into a core driver/framework. So I don't want to blame anyone - that's
> just the way how we do things, right?
If it was easy, somebody would've done it.
>>>> For a quick solution, can we just set the LCD_EN at boot time (with the
>>>> msleep), and not touch it after that?
>>>
>>> That would be sensible for now, so this series can be merged.
>>> As a more appropriate (and long term) solution,
>>> I plan on moving the panel reset pin handling to the spi backlight
>>> driver itself.
>
>> Well, if you must. But I suggest moving the whole panel handling into a
>> (omap specific) panel driver, as it's done for other panels. That way
>> you'll have a proper panel driver for it, for omap, and when CDF comes,
>> you'll get a platform independent panel driver for it.
>
> You can't just move generic architecture/platform independent stuff
> into OMAP specific framework... Just think about this... It's insane.
As I said, reliable vs unreliable. That's not insane.
But again, if you can handle this particular panel reliably with the
two-driver approach, I'm fine with it.
> In addition, AFAIR, the reset pin is the property of the toppoly panel
> hardware, so that is why I think, we should let the toppoly driver
> (currently spi backlight, later hopefully CDF) handle it correctly
> along with the spi sequences.
Yes, that sounds ok.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 9:09 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 9:09 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 4247 bytes --]
On 2013-02-14 10:37, Igor Grinberg wrote:
> On 02/14/13 09:09, Tomi Valkeinen wrote:
>> On 2013-02-14 08:56, Igor Grinberg wrote:
>>> On 02/13/13 17:59, Tomi Valkeinen wrote:
>
>>>> Okay, so I just realized there's an spi backlight driver used here, and
>>>> that backlight driver is actually handling the SPI transactions with the
>>>> panel, instead of the panel driver. So this looks quite messed up.
>>>
>>> Yep, it always was.
>>> The whole DSS specific panel handling inside the
>>> drivers/video/omap2/displays is a mess.
>
>> Well, that's not mess itself, it's just omap specific panel framework.
>> But dividing single device handling into two separate places is a mess.
>
> Yes, you are right it is not the mess, but it prevents the panel to
> be used on other systems and that is BAD.
> At the very least, drivers/video/backlight is a generic place that can be
> used not just on OMAP.
True, it's generic, but does it work reliably? The panel hardware is now
partly handled in the backlight driver, and partly in the omap's panel
driver (and wherever on other platforms).
At least currently there's a dependency between the two, as the LCD_EN
gpio is handled by the panel driver, which affects the functioning of
the backlight driver. Is it ensured that the panel driver does not
disable the panel when the backlight driver does spi transactions?
That's what I meant with the mess, it's difficult to make it work
reliably. I know that for some panels such a two-driver approach would
not work at all. Although I guess it's working well enough for you for
this panel.
Thinking about it, if you do move the gpio handling to the backlight
driver, the panel driver will only handle the DPI video stream. Then it
should not have any effect on the SPI side (presuming the panel doesn't
use the pixel clock as func clock), although there's probably still
possibility for display artifacts on enable and disable, if the order of
operations goes the wrong way.
> And since the toppoly was and is used on other systems, why the hell
> should anyone duplicate the driver just to please the OMAP specific
> panel framework? The real problem is that this framework should not be
Not to please. To make it reliable.
> OMAP specific...
> Of course I'm aware of the fact that currently there is no generic
> panel framework, but forging something OMAP specific which is obviously
> used on most of the other architectures/platforms (and I mean
> panel<->controller relations), is not a good way to go.
Well, if duplicating the code gives us reliable drivers, versus
unreliable without duplicating, then... I don't see it as that bad.
> Although, I'm also aware of the fact that most things are done this way:
> do several specific drivers/frameworks, find the common stuff, and extract
> it into a core driver/framework. So I don't want to blame anyone - that's
> just the way how we do things, right?
If it was easy, somebody would've done it.
>>>> For a quick solution, can we just set the LCD_EN at boot time (with the
>>>> msleep), and not touch it after that?
>>>
>>> That would be sensible for now, so this series can be merged.
>>> As a more appropriate (and long term) solution,
>>> I plan on moving the panel reset pin handling to the spi backlight
>>> driver itself.
>
>> Well, if you must. But I suggest moving the whole panel handling into a
>> (omap specific) panel driver, as it's done for other panels. That way
>> you'll have a proper panel driver for it, for omap, and when CDF comes,
>> you'll get a platform independent panel driver for it.
>
> You can't just move generic architecture/platform independent stuff
> into OMAP specific framework... Just think about this... It's insane.
As I said, reliable vs unreliable. That's not insane.
But again, if you can handle this particular panel reliably with the
two-driver approach, I'm fine with it.
> In addition, AFAIR, the reset pin is the property of the toppoly panel
> hardware, so that is why I think, we should let the toppoly driver
> (currently spi backlight, later hopefully CDF) handle it correctly
> along with the spi sequences.
Yes, that sounds ok.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 9:09 ` Tomi Valkeinen
@ 2013-02-14 9:43 ` Igor Grinberg
-1 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 9:43 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 11:09, Tomi Valkeinen wrote:
> On 2013-02-14 10:37, Igor Grinberg wrote:
>> On 02/14/13 09:09, Tomi Valkeinen wrote:
>>> On 2013-02-14 08:56, Igor Grinberg wrote:
>>>> On 02/13/13 17:59, Tomi Valkeinen wrote:
>>
>>>>> Okay, so I just realized there's an spi backlight driver used here, and
>>>>> that backlight driver is actually handling the SPI transactions with the
>>>>> panel, instead of the panel driver. So this looks quite messed up.
>>>>
>>>> Yep, it always was.
>>>> The whole DSS specific panel handling inside the
>>>> drivers/video/omap2/displays is a mess.
>>
>>> Well, that's not mess itself, it's just omap specific panel framework.
>>> But dividing single device handling into two separate places is a mess.
>>
>> Yes, you are right it is not the mess, but it prevents the panel to
>> be used on other systems and that is BAD.
>> At the very least, drivers/video/backlight is a generic place that can be
>> used not just on OMAP.
>
> True, it's generic, but does it work reliably? The panel hardware is now
> partly handled in the backlight driver, and partly in the omap's panel
> driver (and wherever on other platforms).
It works reliably on other platforms, but not on OMAP - because
we need to cope with the OMAP specific framework...
>
> At least currently there's a dependency between the two, as the LCD_EN
> gpio is handled by the panel driver, which affects the functioning of
> the backlight driver. Is it ensured that the panel driver does not
> disable the panel when the backlight driver does spi transactions?
>
> That's what I meant with the mess, it's difficult to make it work
> reliably. I know that for some panels such a two-driver approach would
> not work at all. Although I guess it's working well enough for you for
> this panel.
Yep, that is correct - this is the mess.
>
> Thinking about it, if you do move the gpio handling to the backlight
> driver, the panel driver will only handle the DPI video stream. Then it
> should not have any effect on the SPI side (presuming the panel doesn't
> use the pixel clock as func clock), although there's probably still
> possibility for display artifacts on enable and disable, if the order of
> operations goes the wrong way.
Yep, again, that is correct.
>
>> And since the toppoly was and is used on other systems, why the hell
>> should anyone duplicate the driver just to please the OMAP specific
>> panel framework? The real problem is that this framework should not be
>
> Not to please. To make it reliable.
Well, there are multiple ways to make it reliable.
And I don't think that the best would be: make it OMAP specific.
>
>> OMAP specific...
>> Of course I'm aware of the fact that currently there is no generic
>> panel framework, but forging something OMAP specific which is obviously
>> used on most of the other architectures/platforms (and I mean
>> panel<->controller relations), is not a good way to go.
>
> Well, if duplicating the code gives us reliable drivers, versus
> unreliable without duplicating, then... I don't see it as that bad.
Hmmm... I don't think this fits the mainline (upstream) philosophy.
This can be also extrapolated into: let's make our own Linux ARM fork
so it will be more reliable...
This is the way how vendor specific kernel releases work.
>
>> Although, I'm also aware of the fact that most things are done this way:
>> do several specific drivers/frameworks, find the common stuff, and extract
>> it into a core driver/framework. So I don't want to blame anyone - that's
>> just the way how we do things, right?
>
> If it was easy, somebody would've done it.
In fact this is done all the time on multiple drivers and frameworks.
Also, I don't say this is easy, but I also don't think this too hard.
It is also a function of resources (time/will/experience/etc.).
>
>>>>> For a quick solution, can we just set the LCD_EN at boot time (with the
>>>>> msleep), and not touch it after that?
>>>>
>>>> That would be sensible for now, so this series can be merged.
>>>> As a more appropriate (and long term) solution,
>>>> I plan on moving the panel reset pin handling to the spi backlight
>>>> driver itself.
>>
>>> Well, if you must. But I suggest moving the whole panel handling into a
>>> (omap specific) panel driver, as it's done for other panels. That way
>>> you'll have a proper panel driver for it, for omap, and when CDF comes,
>>> you'll get a platform independent panel driver for it.
>>
>> You can't just move generic architecture/platform independent stuff
>> into OMAP specific framework... Just think about this... It's insane.
>
> As I said, reliable vs unreliable. That's not insane.
>
> But again, if you can handle this particular panel reliably with the
> two-driver approach, I'm fine with it.
Again, it works reliably on other platforms,
why would OMAP be an exception?
>
>> In addition, AFAIR, the reset pin is the property of the toppoly panel
>> hardware, so that is why I think, we should let the toppoly driver
>> (currently spi backlight, later hopefully CDF) handle it correctly
>> along with the spi sequences.
>
> Yes, that sounds ok.
>
> Tomi
>
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHLGzAAoJEBDE8YO64EfaOJMP/AtR9IkN+eWwdbt0R1Vu9vKH
mFgSCENqErAjYi3zM0YScj+E2zSby4rfXCY14Goh46DBCBXjRWYms6P/nZgGSLYT
lIup5YljWxWJxM0nvrykok872Atx+TSJukx3nD5foWieu4tNRRvhqN7+ckBO7R4D
J1D5uy3wH8Ea3SZ/foPrzewTeajnOeZxzhprfodLdmKIuqxInVE0KrWqrcefspNI
TvWAjLCHtoM4LDCZRaiHs3mN03QMdcJc1BfWeJe1eVx6YXSBqNTTG6mSgUegQyOG
PnC1T3kzS5Vuhmk9NfUmL19LInAljPVDoQomUqG6N140M6jol4ru+A5yE/NZ/tSl
j/8vz5pE8JXp0ueQt1X1vkAGL+Lgzbyrf38xQTxnjSLggO3OFHOv6AzlY453Lfem
gz6Xpjq+2Kcqxghfndd4yXnOjdlyWDN6dvYBthBBixmt34c6nNtdoXmakAXyw8wW
qSyT3sO6WgE53ROZRh9W2FCiLXdJ1rHYMBRRY4nbKNhOhtC/vSF4UVsFBUuAaqul
a6QToMggpugY8n3lm/SZ6LFWJDaHjnkUAVXxq3/GiclJSFwBnHqsOT1bfjsF5OfC
YnaldNBbH0WvmFN89Ds/inW1MLcFc/yWirB0Utj7ysb5AL4vH4QLs1dokzjxnTyK
WJmOMyQi7Jk+ocUSBgu2
=G6lL
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 9:43 ` Igor Grinberg
0 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 9:43 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 11:09, Tomi Valkeinen wrote:
> On 2013-02-14 10:37, Igor Grinberg wrote:
>> On 02/14/13 09:09, Tomi Valkeinen wrote:
>>> On 2013-02-14 08:56, Igor Grinberg wrote:
>>>> On 02/13/13 17:59, Tomi Valkeinen wrote:
>>
>>>>> Okay, so I just realized there's an spi backlight driver used here, and
>>>>> that backlight driver is actually handling the SPI transactions with the
>>>>> panel, instead of the panel driver. So this looks quite messed up.
>>>>
>>>> Yep, it always was.
>>>> The whole DSS specific panel handling inside the
>>>> drivers/video/omap2/displays is a mess.
>>
>>> Well, that's not mess itself, it's just omap specific panel framework.
>>> But dividing single device handling into two separate places is a mess.
>>
>> Yes, you are right it is not the mess, but it prevents the panel to
>> be used on other systems and that is BAD.
>> At the very least, drivers/video/backlight is a generic place that can be
>> used not just on OMAP.
>
> True, it's generic, but does it work reliably? The panel hardware is now
> partly handled in the backlight driver, and partly in the omap's panel
> driver (and wherever on other platforms).
It works reliably on other platforms, but not on OMAP - because
we need to cope with the OMAP specific framework...
>
> At least currently there's a dependency between the two, as the LCD_EN
> gpio is handled by the panel driver, which affects the functioning of
> the backlight driver. Is it ensured that the panel driver does not
> disable the panel when the backlight driver does spi transactions?
>
> That's what I meant with the mess, it's difficult to make it work
> reliably. I know that for some panels such a two-driver approach would
> not work at all. Although I guess it's working well enough for you for
> this panel.
Yep, that is correct - this is the mess.
>
> Thinking about it, if you do move the gpio handling to the backlight
> driver, the panel driver will only handle the DPI video stream. Then it
> should not have any effect on the SPI side (presuming the panel doesn't
> use the pixel clock as func clock), although there's probably still
> possibility for display artifacts on enable and disable, if the order of
> operations goes the wrong way.
Yep, again, that is correct.
>
>> And since the toppoly was and is used on other systems, why the hell
>> should anyone duplicate the driver just to please the OMAP specific
>> panel framework? The real problem is that this framework should not be
>
> Not to please. To make it reliable.
Well, there are multiple ways to make it reliable.
And I don't think that the best would be: make it OMAP specific.
>
>> OMAP specific...
>> Of course I'm aware of the fact that currently there is no generic
>> panel framework, but forging something OMAP specific which is obviously
>> used on most of the other architectures/platforms (and I mean
>> panel<->controller relations), is not a good way to go.
>
> Well, if duplicating the code gives us reliable drivers, versus
> unreliable without duplicating, then... I don't see it as that bad.
Hmmm... I don't think this fits the mainline (upstream) philosophy.
This can be also extrapolated into: let's make our own Linux ARM fork
so it will be more reliable...
This is the way how vendor specific kernel releases work.
>
>> Although, I'm also aware of the fact that most things are done this way:
>> do several specific drivers/frameworks, find the common stuff, and extract
>> it into a core driver/framework. So I don't want to blame anyone - that's
>> just the way how we do things, right?
>
> If it was easy, somebody would've done it.
In fact this is done all the time on multiple drivers and frameworks.
Also, I don't say this is easy, but I also don't think this too hard.
It is also a function of resources (time/will/experience/etc.).
>
>>>>> For a quick solution, can we just set the LCD_EN at boot time (with the
>>>>> msleep), and not touch it after that?
>>>>
>>>> That would be sensible for now, so this series can be merged.
>>>> As a more appropriate (and long term) solution,
>>>> I plan on moving the panel reset pin handling to the spi backlight
>>>> driver itself.
>>
>>> Well, if you must. But I suggest moving the whole panel handling into a
>>> (omap specific) panel driver, as it's done for other panels. That way
>>> you'll have a proper panel driver for it, for omap, and when CDF comes,
>>> you'll get a platform independent panel driver for it.
>>
>> You can't just move generic architecture/platform independent stuff
>> into OMAP specific framework... Just think about this... It's insane.
>
> As I said, reliable vs unreliable. That's not insane.
>
> But again, if you can handle this particular panel reliably with the
> two-driver approach, I'm fine with it.
Again, it works reliably on other platforms,
why would OMAP be an exception?
>
>> In addition, AFAIR, the reset pin is the property of the toppoly panel
>> hardware, so that is why I think, we should let the toppoly driver
>> (currently spi backlight, later hopefully CDF) handle it correctly
>> along with the spi sequences.
>
> Yes, that sounds ok.
>
> Tomi
>
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHLGzAAoJEBDE8YO64EfaOJMP/AtR9IkN+eWwdbt0R1Vu9vKH
mFgSCENqErAjYi3zM0YScj+E2zSby4rfXCY14Goh46DBCBXjRWYms6P/nZgGSLYT
lIup5YljWxWJxM0nvrykok872Atx+TSJukx3nD5foWieu4tNRRvhqN7+ckBO7R4D
J1D5uy3wH8Ea3SZ/foPrzewTeajnOeZxzhprfodLdmKIuqxInVE0KrWqrcefspNI
TvWAjLCHtoM4LDCZRaiHs3mN03QMdcJc1BfWeJe1eVx6YXSBqNTTG6mSgUegQyOG
PnC1T3kzS5Vuhmk9NfUmL19LInAljPVDoQomUqG6N140M6jol4ru+A5yE/NZ/tSl
j/8vz5pE8JXp0ueQt1X1vkAGL+Lgzbyrf38xQTxnjSLggO3OFHOv6AzlY453Lfem
gz6Xpjq+2Kcqxghfndd4yXnOjdlyWDN6dvYBthBBixmt34c6nNtdoXmakAXyw8wW
qSyT3sO6WgE53ROZRh9W2FCiLXdJ1rHYMBRRY4nbKNhOhtC/vSF4UVsFBUuAaqul
a6QToMggpugY8n3lm/SZ6LFWJDaHjnkUAVXxq3/GiclJSFwBnHqsOT1bfjsF5OfC
YnaldNBbH0WvmFN89Ds/inW1MLcFc/yWirB0Utj7ysb5AL4vH4QLs1dokzjxnTyK
WJmOMyQi7Jk+ocUSBgu2
=G6lL
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 9:43 ` Igor Grinberg
@ 2013-02-14 10:59 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 10:59 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]
On 2013-02-14 11:43, Igor Grinberg wrote:
>> True, it's generic, but does it work reliably? The panel hardware is now
>> partly handled in the backlight driver, and partly in the omap's panel
>> driver (and wherever on other platforms).
>
> It works reliably on other platforms, but not on OMAP - because
> we need to cope with the OMAP specific framework...
How do you handle the gpios on other platform? Those are the ones
causing the issues here, right?
Or is there something else with OMAP DSS that you need to specifically
cope with?
>> Thinking about it, if you do move the gpio handling to the backlight
>> driver, the panel driver will only handle the DPI video stream. Then it
>> should not have any effect on the SPI side (presuming the panel doesn't
>> use the pixel clock as func clock), although there's probably still
>> possibility for display artifacts on enable and disable, if the order of
>> operations goes the wrong way.
>
> Yep, again, that is correct.
It's correct that there may be artifacts? How do you manage the ordering
of the operations on other platforms?
>>> And since the toppoly was and is used on other systems, why the hell
>>> should anyone duplicate the driver just to please the OMAP specific
>>> panel framework? The real problem is that this framework should not be
>
>> Not to please. To make it reliable.
>
> Well, there are multiple ways to make it reliable.
> And I don't think that the best would be: make it OMAP specific.
I'm not saying it's the best option. I'm saying it's a realistic option
to get it working.
>> Well, if duplicating the code gives us reliable drivers, versus
>> unreliable without duplicating, then... I don't see it as that bad.
>
> Hmmm... I don't think this fits the mainline (upstream) philosophy.
> This can be also extrapolated into: let's make our own Linux ARM fork
> so it will be more reliable...
> This is the way how vendor specific kernel releases work.
Well, we are talking about a smallish driver here. Not an arch fork. If
the options are a) platform specific driver that works, or b) generic
driver that's not reliable, or c) no driver at all, I can't really see
why a) would be such a horrible option for the time being.
But this discussion is getting a bit out of hand. It sounds to me that
for this panel in question we can manage with the current approach, so
this whole line of discussion doesn't matter for this specific problem.
>> If it was easy, somebody would've done it.
>
> In fact this is done all the time on multiple drivers and frameworks.
> Also, I don't say this is easy, but I also don't think this too hard.
> It is also a function of resources (time/will/experience/etc.).
I think the CDF discussions have already proven that it is quite hard.
But feel free to contribute.
And I've talked about a common display framework already years ago, and
I've tried to design OMAP DSS panels from start in such a way that they
try to depend on OMAP DSS features as little as possible, to make it
easier to generalize them. Just to prove I'm not indifferent about the
issue =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 10:59 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 10:59 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]
On 2013-02-14 11:43, Igor Grinberg wrote:
>> True, it's generic, but does it work reliably? The panel hardware is now
>> partly handled in the backlight driver, and partly in the omap's panel
>> driver (and wherever on other platforms).
>
> It works reliably on other platforms, but not on OMAP - because
> we need to cope with the OMAP specific framework...
How do you handle the gpios on other platform? Those are the ones
causing the issues here, right?
Or is there something else with OMAP DSS that you need to specifically
cope with?
>> Thinking about it, if you do move the gpio handling to the backlight
>> driver, the panel driver will only handle the DPI video stream. Then it
>> should not have any effect on the SPI side (presuming the panel doesn't
>> use the pixel clock as func clock), although there's probably still
>> possibility for display artifacts on enable and disable, if the order of
>> operations goes the wrong way.
>
> Yep, again, that is correct.
It's correct that there may be artifacts? How do you manage the ordering
of the operations on other platforms?
>>> And since the toppoly was and is used on other systems, why the hell
>>> should anyone duplicate the driver just to please the OMAP specific
>>> panel framework? The real problem is that this framework should not be
>
>> Not to please. To make it reliable.
>
> Well, there are multiple ways to make it reliable.
> And I don't think that the best would be: make it OMAP specific.
I'm not saying it's the best option. I'm saying it's a realistic option
to get it working.
>> Well, if duplicating the code gives us reliable drivers, versus
>> unreliable without duplicating, then... I don't see it as that bad.
>
> Hmmm... I don't think this fits the mainline (upstream) philosophy.
> This can be also extrapolated into: let's make our own Linux ARM fork
> so it will be more reliable...
> This is the way how vendor specific kernel releases work.
Well, we are talking about a smallish driver here. Not an arch fork. If
the options are a) platform specific driver that works, or b) generic
driver that's not reliable, or c) no driver at all, I can't really see
why a) would be such a horrible option for the time being.
But this discussion is getting a bit out of hand. It sounds to me that
for this panel in question we can manage with the current approach, so
this whole line of discussion doesn't matter for this specific problem.
>> If it was easy, somebody would've done it.
>
> In fact this is done all the time on multiple drivers and frameworks.
> Also, I don't say this is easy, but I also don't think this too hard.
> It is also a function of resources (time/will/experience/etc.).
I think the CDF discussions have already proven that it is quite hard.
But feel free to contribute.
And I've talked about a common display framework already years ago, and
I've tried to design OMAP DSS panels from start in such a way that they
try to depend on OMAP DSS features as little as possible, to make it
easier to generalize them. Just to prove I'm not indifferent about the
issue =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 10:59 ` Tomi Valkeinen
@ 2013-02-14 12:37 ` Igor Grinberg
-1 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 12:37 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 12:59, Tomi Valkeinen wrote:
> On 2013-02-14 11:43, Igor Grinberg wrote:
>
>>> True, it's generic, but does it work reliably? The panel hardware is now
>>> partly handled in the backlight driver, and partly in the omap's panel
>>> driver (and wherever on other platforms).
>>
>> It works reliably on other platforms, but not on OMAP - because
>> we need to cope with the OMAP specific framework...
>
> How do you handle the gpios on other platform? Those are the ones
> causing the issues here, right?
Well, I'm also talking about something that is a history already.
Remember, we had multiple panel drivers inside the
video/omap2/displays and then they were consolidated into the
"generic dpi/dsi/whatever".
And yes you are right, on the platforms I'm aware of, the GPIO is not
handled. Apparently its hardware default (pull resistor) is always on...
>
> Or is there something else with OMAP DSS that you need to specifically
> cope with?
The fact there is a need to create a OMAP specific driver.
I'm not talking about the generic driver which only needs to have the
controller specific data (e.g. porches, pixel clock, bus width).
The generic driver was one of the good ways to go.
>
>>> Thinking about it, if you do move the gpio handling to the backlight
>>> driver, the panel driver will only handle the DPI video stream. Then it
>>> should not have any effect on the SPI side (presuming the panel doesn't
>>> use the pixel clock as func clock), although there's probably still
>>> possibility for display artifacts on enable and disable, if the order of
>>> operations goes the wrong way.
>>
>> Yep, again, that is correct.
>
> It's correct that there may be artifacts? How do you manage the ordering
> of the operations on other platforms?
Yep, there might be artifacts if the ordering is incorrect.
The ordering is something that should be solved by the CDF.
>
>>>> And since the toppoly was and is used on other systems, why the hell
>>>> should anyone duplicate the driver just to please the OMAP specific
>>>> panel framework? The real problem is that this framework should not be
>>
>>> Not to please. To make it reliable.
>>
>> Well, there are multiple ways to make it reliable.
>> And I don't think that the best would be: make it OMAP specific.
>
> I'm not saying it's the best option. I'm saying it's a realistic option
> to get it working.
>
>>> Well, if duplicating the code gives us reliable drivers, versus
>>> unreliable without duplicating, then... I don't see it as that bad.
>>
>> Hmmm... I don't think this fits the mainline (upstream) philosophy.
>> This can be also extrapolated into: let's make our own Linux ARM fork
>> so it will be more reliable...
>> This is the way how vendor specific kernel releases work.
>
> Well, we are talking about a smallish driver here. Not an arch fork. If
> the options are a) platform specific driver that works, or b) generic
> driver that's not reliable, or c) no driver at all, I can't really see
> why a) would be such a horrible option for the time being.
I think there is b.5) where the driver is both generic and reliable,
but I haven't looked into this deep enough.
>
> But this discussion is getting a bit out of hand. It sounds to me that
> for this panel in question we can manage with the current approach, so
> this whole line of discussion doesn't matter for this specific problem.
>
>>> If it was easy, somebody would've done it.
>>
>> In fact this is done all the time on multiple drivers and frameworks.
>> Also, I don't say this is easy, but I also don't think this too hard.
>> It is also a function of resources (time/will/experience/etc.).
>
> I think the CDF discussions have already proven that it is quite hard.
> But feel free to contribute.
I will contribute as much as I can in terms of my paid work.
I always do...
>
> And I've talked about a common display framework already years ago, and
> I've tried to design OMAP DSS panels from start in such a way that they
> try to depend on OMAP DSS features as little as possible, to make it
> easier to generalize them. Just to prove I'm not indifferent about the
> issue =).
Yep, your work was fruitful and no one can take it from you!
That's why I said that I'm not trying to blame or accuse anyone.
That is more of a wish that the CDF will come as quickly as it can.
Because currently it is clear that there are cases where we don't
have a proper support...
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHNqRAAoJEBDE8YO64Efac08QAKBgU7xFkdBHU0ekAgRIafhO
kd0EgPXwPZDvuAaoj5pzdMI65alRSuoQxp5ohHyz0aFfGRk0Q66f6/zXzTsGXPLP
pRTkqGGTHD5Qtv2IvhHPvLMRGW+87QiuK0NU0BJqV/1JRPz1UyKMJrwc5U3Acf4J
B7bQnWLlIcPftIt2zHwuvZZMYZUL8f5/dXGWMhxmTF7rse7YcTjCwQO4eabTIX5r
/GUanF+qlwKJzk7nxQR1DFQdN+7Vv8vdumJi38sq9fouLgXlhmzOgXvxMgT7lq8T
l+7Bg7l+E9yrHaXmWf3zjZBAk6/wBnzzrmmK5V6Gjg2PiEh6Rs5ARWPrdc/FQCpt
4bXTKEktLonHj2rya8intrPLw7lP4AQN81QsQOLeRIPGoSCcDsi4RGAFrWdXR0Xt
Du9ea/liAD3+qiNIErQcTlR5zDKAIhMvWycG+ZFj0kVFUFb6p/F1TKcqVy0O7HAG
SLSsrCyO8jA/UxAKQifhiUU2Hoq9a3VhQi507lbXiN0NTsk686mp/W8YJPB/di+v
44wayaE5Kyw5iawLj9WUyTpw29sOysiewp+z7XuaF3fM5lWeMy2e0/mNbe4iCcCG
LYMl0NWcQn0S7okkQz5HHmCJp3L3/Se5sMfGKJRzpG0vK1DR+m8nJh0MGbEu/14C
B9+3VrImRZS8te/wnPqE
ºnK
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 12:37 ` Igor Grinberg
0 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 12:37 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 12:59, Tomi Valkeinen wrote:
> On 2013-02-14 11:43, Igor Grinberg wrote:
>
>>> True, it's generic, but does it work reliably? The panel hardware is now
>>> partly handled in the backlight driver, and partly in the omap's panel
>>> driver (and wherever on other platforms).
>>
>> It works reliably on other platforms, but not on OMAP - because
>> we need to cope with the OMAP specific framework...
>
> How do you handle the gpios on other platform? Those are the ones
> causing the issues here, right?
Well, I'm also talking about something that is a history already.
Remember, we had multiple panel drivers inside the
video/omap2/displays and then they were consolidated into the
"generic dpi/dsi/whatever".
And yes you are right, on the platforms I'm aware of, the GPIO is not
handled. Apparently its hardware default (pull resistor) is always on...
>
> Or is there something else with OMAP DSS that you need to specifically
> cope with?
The fact there is a need to create a OMAP specific driver.
I'm not talking about the generic driver which only needs to have the
controller specific data (e.g. porches, pixel clock, bus width).
The generic driver was one of the good ways to go.
>
>>> Thinking about it, if you do move the gpio handling to the backlight
>>> driver, the panel driver will only handle the DPI video stream. Then it
>>> should not have any effect on the SPI side (presuming the panel doesn't
>>> use the pixel clock as func clock), although there's probably still
>>> possibility for display artifacts on enable and disable, if the order of
>>> operations goes the wrong way.
>>
>> Yep, again, that is correct.
>
> It's correct that there may be artifacts? How do you manage the ordering
> of the operations on other platforms?
Yep, there might be artifacts if the ordering is incorrect.
The ordering is something that should be solved by the CDF.
>
>>>> And since the toppoly was and is used on other systems, why the hell
>>>> should anyone duplicate the driver just to please the OMAP specific
>>>> panel framework? The real problem is that this framework should not be
>>
>>> Not to please. To make it reliable.
>>
>> Well, there are multiple ways to make it reliable.
>> And I don't think that the best would be: make it OMAP specific.
>
> I'm not saying it's the best option. I'm saying it's a realistic option
> to get it working.
>
>>> Well, if duplicating the code gives us reliable drivers, versus
>>> unreliable without duplicating, then... I don't see it as that bad.
>>
>> Hmmm... I don't think this fits the mainline (upstream) philosophy.
>> This can be also extrapolated into: let's make our own Linux ARM fork
>> so it will be more reliable...
>> This is the way how vendor specific kernel releases work.
>
> Well, we are talking about a smallish driver here. Not an arch fork. If
> the options are a) platform specific driver that works, or b) generic
> driver that's not reliable, or c) no driver at all, I can't really see
> why a) would be such a horrible option for the time being.
I think there is b.5) where the driver is both generic and reliable,
but I haven't looked into this deep enough.
>
> But this discussion is getting a bit out of hand. It sounds to me that
> for this panel in question we can manage with the current approach, so
> this whole line of discussion doesn't matter for this specific problem.
>
>>> If it was easy, somebody would've done it.
>>
>> In fact this is done all the time on multiple drivers and frameworks.
>> Also, I don't say this is easy, but I also don't think this too hard.
>> It is also a function of resources (time/will/experience/etc.).
>
> I think the CDF discussions have already proven that it is quite hard.
> But feel free to contribute.
I will contribute as much as I can in terms of my paid work.
I always do...
>
> And I've talked about a common display framework already years ago, and
> I've tried to design OMAP DSS panels from start in such a way that they
> try to depend on OMAP DSS features as little as possible, to make it
> easier to generalize them. Just to prove I'm not indifferent about the
> issue =).
Yep, your work was fruitful and no one can take it from you!
That's why I said that I'm not trying to blame or accuse anyone.
That is more of a wish that the CDF will come as quickly as it can.
Because currently it is clear that there are cases where we don't
have a proper support...
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHNqRAAoJEBDE8YO64Efac08QAKBgU7xFkdBHU0ekAgRIafhO
kd0EgPXwPZDvuAaoj5pzdMI65alRSuoQxp5ohHyz0aFfGRk0Q66f6/zXzTsGXPLP
pRTkqGGTHD5Qtv2IvhHPvLMRGW+87QiuK0NU0BJqV/1JRPz1UyKMJrwc5U3Acf4J
B7bQnWLlIcPftIt2zHwuvZZMYZUL8f5/dXGWMhxmTF7rse7YcTjCwQO4eabTIX5r
/GUanF+qlwKJzk7nxQR1DFQdN+7Vv8vdumJi38sq9fouLgXlhmzOgXvxMgT7lq8T
l+7Bg7l+E9yrHaXmWf3zjZBAk6/wBnzzrmmK5V6Gjg2PiEh6Rs5ARWPrdc/FQCpt
4bXTKEktLonHj2rya8intrPLw7lP4AQN81QsQOLeRIPGoSCcDsi4RGAFrWdXR0Xt
Du9ea/liAD3+qiNIErQcTlR5zDKAIhMvWycG+ZFj0kVFUFb6p/F1TKcqVy0O7HAG
SLSsrCyO8jA/UxAKQifhiUU2Hoq9a3VhQi507lbXiN0NTsk686mp/W8YJPB/di+v
44wayaE5Kyw5iawLj9WUyTpw29sOysiewp+z7XuaF3fM5lWeMy2e0/mNbe4iCcCG
LYMl0NWcQn0S7okkQz5HHmCJp3L3/Se5sMfGKJRzpG0vK1DR+m8nJh0MGbEu/14C
B9+3VrImRZS8te/wnPqE
=BAnK
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
2013-02-14 6:46 ` Archit Taneja
@ 2013-02-14 12:45 ` Aaro Koskinen
-1 siblings, 0 replies; 134+ messages in thread
From: Aaro Koskinen @ 2013-02-14 12:45 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
On Thu, Feb 14, 2013 at 12:04:32PM +0530, Archit Taneja wrote:
> On Wednesday 13 February 2013 11:05 PM, Aaro Koskinen wrote:
> >On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
> >>@@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
> >> dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
> >> dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
> >>
> >>+ if (gpio_is_valid(bdata->panel_reset)) {
> >>+ r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
> >>+ GPIOF_OUT_INIT_LOW, "PANEL RESET");
> >>+ if (r)
> >>+ return r;
> >>+ }
> >>+
> >>+ if (gpio_is_valid(bdata->ctrl_pwrdown)) {
> >>+ r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
> >>+ GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
> >>+ if (r)
> >>+ return r;
> >>+ }
> >>+
> >
> >In the error case, the other GPIO is not freed. Also maybe you should
> >free them on module removal, because now the module owns the GPIOs.
>
> Wouldn't the usage of devm_* functions take care of this? If the
> device isn't registered successfully, then all allocations/requests
> done using devm_* functions will be free'd automatically.
Sorry, I didn't realized they are devm_* now. You are right.
A.
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
@ 2013-02-14 12:45 ` Aaro Koskinen
0 siblings, 0 replies; 134+ messages in thread
From: Aaro Koskinen @ 2013-02-14 12:45 UTC (permalink / raw)
To: Archit Taneja; +Cc: tomi.valkeinen, linux-omap, linux-fbdev
On Thu, Feb 14, 2013 at 12:04:32PM +0530, Archit Taneja wrote:
> On Wednesday 13 February 2013 11:05 PM, Aaro Koskinen wrote:
> >On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
> >>@@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
> >> dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
> >> dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
> >>
> >>+ if (gpio_is_valid(bdata->panel_reset)) {
> >>+ r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
> >>+ GPIOF_OUT_INIT_LOW, "PANEL RESET");
> >>+ if (r)
> >>+ return r;
> >>+ }
> >>+
> >>+ if (gpio_is_valid(bdata->ctrl_pwrdown)) {
> >>+ r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
> >>+ GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
> >>+ if (r)
> >>+ return r;
> >>+ }
> >>+
> >
> >In the error case, the other GPIO is not freed. Also maybe you should
> >free them on module removal, because now the module owns the GPIOs.
>
> Wouldn't the usage of devm_* functions take care of this? If the
> device isn't registered successfully, then all allocations/requests
> done using devm_* functions will be free'd automatically.
Sorry, I didn't realized they are devm_* now. You are right.
A.
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 12:37 ` Igor Grinberg
@ 2013-02-14 12:52 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 12:52 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]
On 2013-02-14 14:37, Igor Grinberg wrote:
> On 02/14/13 12:59, Tomi Valkeinen wrote:
>> On 2013-02-14 11:43, Igor Grinberg wrote:
>
>>>> True, it's generic, but does it work reliably? The panel hardware is now
>>>> partly handled in the backlight driver, and partly in the omap's panel
>>>> driver (and wherever on other platforms).
>>>
>>> It works reliably on other platforms, but not on OMAP - because
>>> we need to cope with the OMAP specific framework...
>
>> How do you handle the gpios on other platform? Those are the ones
>> causing the issues here, right?
>
> Well, I'm also talking about something that is a history already.
> Remember, we had multiple panel drivers inside the
> video/omap2/displays and then they were consolidated into the
> "generic dpi/dsi/whatever".
Sorry, I miss the point. Was that a bad thing? Didn't it simplify the
task for you with simple panels? It could've been taken even further,
though (see below).
> And yes you are right, on the platforms I'm aware of, the GPIO is not
> handled. Apparently its hardware default (pull resistor) is always on...
Ok, so the simple fix of setting the GPIOs only in the board file is
acceptable for now.
Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
backlight will supposedly be always on. Is it just a simple switch for
the BL power, which does not affect the SPI in any way?
>> Or is there something else with OMAP DSS that you need to specifically
>> cope with?
>
> The fact there is a need to create a OMAP specific driver.
> I'm not talking about the generic driver which only needs to have the
> controller specific data (e.g. porches, pixel clock, bus width).
> The generic driver was one of the good ways to go.
Well, we could also have an even more generic driver that takes the
video timings from the board file as platform data. Then all you would
need to do is to define the timings in the board file, as I think is
done for other platforms also.
I'm not very fond of that idea, as I think hardcoded device specific
data should not be given as parameters, but they should be handled by
the device driver internally, as it should know that device specific
data already.
But, in practice, making this kind of even more generic panel driver
will probably make life easier for everyone, so I think we'll have one
with CDF.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 12:52 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-14 12:52 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]
On 2013-02-14 14:37, Igor Grinberg wrote:
> On 02/14/13 12:59, Tomi Valkeinen wrote:
>> On 2013-02-14 11:43, Igor Grinberg wrote:
>
>>>> True, it's generic, but does it work reliably? The panel hardware is now
>>>> partly handled in the backlight driver, and partly in the omap's panel
>>>> driver (and wherever on other platforms).
>>>
>>> It works reliably on other platforms, but not on OMAP - because
>>> we need to cope with the OMAP specific framework...
>
>> How do you handle the gpios on other platform? Those are the ones
>> causing the issues here, right?
>
> Well, I'm also talking about something that is a history already.
> Remember, we had multiple panel drivers inside the
> video/omap2/displays and then they were consolidated into the
> "generic dpi/dsi/whatever".
Sorry, I miss the point. Was that a bad thing? Didn't it simplify the
task for you with simple panels? It could've been taken even further,
though (see below).
> And yes you are right, on the platforms I'm aware of, the GPIO is not
> handled. Apparently its hardware default (pull resistor) is always on...
Ok, so the simple fix of setting the GPIOs only in the board file is
acceptable for now.
Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
backlight will supposedly be always on. Is it just a simple switch for
the BL power, which does not affect the SPI in any way?
>> Or is there something else with OMAP DSS that you need to specifically
>> cope with?
>
> The fact there is a need to create a OMAP specific driver.
> I'm not talking about the generic driver which only needs to have the
> controller specific data (e.g. porches, pixel clock, bus width).
> The generic driver was one of the good ways to go.
Well, we could also have an even more generic driver that takes the
video timings from the board file as platform data. Then all you would
need to do is to define the timings in the board file, as I think is
done for other platforms also.
I'm not very fond of that idea, as I think hardcoded device specific
data should not be given as parameters, but they should be handled by
the device driver internally, as it should know that device specific
data already.
But, in practice, making this kind of even more generic panel driver
will probably make life easier for everyone, so I think we'll have one
with CDF.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 12:52 ` Tomi Valkeinen
@ 2013-02-14 13:51 ` Igor Grinberg
-1 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 13:51 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 14:52, Tomi Valkeinen wrote:
> On 2013-02-14 14:37, Igor Grinberg wrote:
>> On 02/14/13 12:59, Tomi Valkeinen wrote:
>>> On 2013-02-14 11:43, Igor Grinberg wrote:
>>
>>>>> True, it's generic, but does it work reliably? The panel hardware is now
>>>>> partly handled in the backlight driver, and partly in the omap's panel
>>>>> driver (and wherever on other platforms).
>>>>
>>>> It works reliably on other platforms, but not on OMAP - because
>>>> we need to cope with the OMAP specific framework...
>>
>>> How do you handle the gpios on other platform? Those are the ones
>>> causing the issues here, right?
>>
>> Well, I'm also talking about something that is a history already.
>> Remember, we had multiple panel drivers inside the
>> video/omap2/displays and then they were consolidated into the
>> "generic dpi/dsi/whatever".
>
> Sorry, I miss the point. Was that a bad thing? Didn't it simplify the
> task for you with simple panels? It could've been taken even further,
> though (see below).
Yes it was a good thing (I have already told this below).
>
>> And yes you are right, on the platforms I'm aware of, the GPIO is not
>> handled. Apparently its hardware default (pull resistor) is always on...
>
> Ok, so the simple fix of setting the GPIOs only in the board file is
> acceptable for now.
Yep. I also told this already in one of the previous emails.
>
> Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
> backlight will supposedly be always on. Is it just a simple switch for
> the BL power, which does not affect the SPI in any way?
Yes, it can for now.
Also, I think we should also take into account the backlight framework,
including PMW.
>
>>> Or is there something else with OMAP DSS that you need to specifically
>>> cope with?
>>
>> The fact there is a need to create a OMAP specific driver.
>> I'm not talking about the generic driver which only needs to have the
>> controller specific data (e.g. porches, pixel clock, bus width).
>> The generic driver was one of the good ways to go.
>
> Well, we could also have an even more generic driver that takes the
> video timings from the board file as platform data. Then all you would
> need to do is to define the timings in the board file, as I think is
> done for other platforms also.
Yep. That sounds reasonable also for cases where the bus width is the
hardware (board) property.
>
> I'm not very fond of that idea, as I think hardcoded device specific
> data should not be given as parameters, but they should be handled by
> the device driver internally, as it should know that device specific
> data already.
Yes, that is why I think the generic driver for "simple" panels
was a good idea. There was some flexibility missing though.
For example the resolution setting which in turn drags another set
of timings and pixel clock.
There are panels that support more than one resolution.
>
> But, in practice, making this kind of even more generic panel driver
> will probably make life easier for everyone, so I think we'll have one
> with CDF.
I'm looking forward to see it happening!
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHOvEAAoJEBDE8YO64EfaCZ0P/32SYC7MZRJMfUVrnzZtJZpn
9BKzrvO0h/GKZMbKoKKNFwmvlTxEocELLkljF35ipbc51C/dpD45ZmMBvu4s8owE
6bopGw6ssTahTKk0zY5PekTamZT7UlY86hI9ZcZBxSzY8xaj7UCSPnJ3qzY2ZGzA
4heJW01mlHr9i1qkOzxz0IHA2CdQmQltAsW12NFCWYBRpDfhrYtECwhlnvLXHEzy
nqXNpRHOnrL/hqvJwor1X+D/O1JlyxUiVr6+7sAZqXxvv/iMX8Nc1XeTObgGbse6
1bpipPD57etqISsN1g9ur1tU5f6KvoR4IA35RaCCkBFINIXMEBl7kr5X9Bcg3giE
3pz23k91KRloOcXJ0OvLHp7RnSrwswU/4C3Cse+95cY0wyChaVlwJtySEnfGALWV
aiuw89v6DXaC5WDQq55UtTc3qjc23Ehut8i184PAv5HKrDHLLjVg4HqgGjC9uGEn
JKOxOnfMTstqyKC2whW+Pep3g4npJAHsn/0QmpdSJQ/vEwm7CmXBZeR6DwcTSLAT
xR1SUWwHav2HqpYUz4y7TgIPuwsR+VNKn/mSOTbhbLB4s9bowPMxMiqz2AQn3ige
YyMTo7KnObivXZydrVrx0/e/DJC4ENGpE3macVQytr0BpjJhK1+XiNMHa17+Mymm
U45VDKrUgaYcYXW2L4JN
=xeSz
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-02-14 13:51 ` Igor Grinberg
0 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-02-14 13:51 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 14:52, Tomi Valkeinen wrote:
> On 2013-02-14 14:37, Igor Grinberg wrote:
>> On 02/14/13 12:59, Tomi Valkeinen wrote:
>>> On 2013-02-14 11:43, Igor Grinberg wrote:
>>
>>>>> True, it's generic, but does it work reliably? The panel hardware is now
>>>>> partly handled in the backlight driver, and partly in the omap's panel
>>>>> driver (and wherever on other platforms).
>>>>
>>>> It works reliably on other platforms, but not on OMAP - because
>>>> we need to cope with the OMAP specific framework...
>>
>>> How do you handle the gpios on other platform? Those are the ones
>>> causing the issues here, right?
>>
>> Well, I'm also talking about something that is a history already.
>> Remember, we had multiple panel drivers inside the
>> video/omap2/displays and then they were consolidated into the
>> "generic dpi/dsi/whatever".
>
> Sorry, I miss the point. Was that a bad thing? Didn't it simplify the
> task for you with simple panels? It could've been taken even further,
> though (see below).
Yes it was a good thing (I have already told this below).
>
>> And yes you are right, on the platforms I'm aware of, the GPIO is not
>> handled. Apparently its hardware default (pull resistor) is always on...
>
> Ok, so the simple fix of setting the GPIOs only in the board file is
> acceptable for now.
Yep. I also told this already in one of the previous emails.
>
> Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
> backlight will supposedly be always on. Is it just a simple switch for
> the BL power, which does not affect the SPI in any way?
Yes, it can for now.
Also, I think we should also take into account the backlight framework,
including PMW.
>
>>> Or is there something else with OMAP DSS that you need to specifically
>>> cope with?
>>
>> The fact there is a need to create a OMAP specific driver.
>> I'm not talking about the generic driver which only needs to have the
>> controller specific data (e.g. porches, pixel clock, bus width).
>> The generic driver was one of the good ways to go.
>
> Well, we could also have an even more generic driver that takes the
> video timings from the board file as platform data. Then all you would
> need to do is to define the timings in the board file, as I think is
> done for other platforms also.
Yep. That sounds reasonable also for cases where the bus width is the
hardware (board) property.
>
> I'm not very fond of that idea, as I think hardcoded device specific
> data should not be given as parameters, but they should be handled by
> the device driver internally, as it should know that device specific
> data already.
Yes, that is why I think the generic driver for "simple" panels
was a good idea. There was some flexibility missing though.
For example the resolution setting which in turn drags another set
of timings and pixel clock.
There are panels that support more than one resolution.
>
> But, in practice, making this kind of even more generic panel driver
> will probably make life easier for everyone, so I think we'll have one
> with CDF.
I'm looking forward to see it happening!
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHOvEAAoJEBDE8YO64EfaCZ0P/32SYC7MZRJMfUVrnzZtJZpn
9BKzrvO0h/GKZMbKoKKNFwmvlTxEocELLkljF35ipbc51C/dpD45ZmMBvu4s8owE
6bopGw6ssTahTKk0zY5PekTamZT7UlY86hI9ZcZBxSzY8xaj7UCSPnJ3qzY2ZGzA
4heJW01mlHr9i1qkOzxz0IHA2CdQmQltAsW12NFCWYBRpDfhrYtECwhlnvLXHEzy
nqXNpRHOnrL/hqvJwor1X+D/O1JlyxUiVr6+7sAZqXxvv/iMX8Nc1XeTObgGbse6
1bpipPD57etqISsN1g9ur1tU5f6KvoR4IA35RaCCkBFINIXMEBl7kr5X9Bcg3giE
3pz23k91KRloOcXJ0OvLHp7RnSrwswU/4C3Cse+95cY0wyChaVlwJtySEnfGALWV
aiuw89v6DXaC5WDQq55UtTc3qjc23Ehut8i184PAv5HKrDHLLjVg4HqgGjC9uGEn
JKOxOnfMTstqyKC2whW+Pep3g4npJAHsn/0QmpdSJQ/vEwm7CmXBZeR6DwcTSLAT
xR1SUWwHav2HqpYUz4y7TgIPuwsR+VNKn/mSOTbhbLB4s9bowPMxMiqz2AQn3ige
YyMTo7KnObivXZydrVrx0/e/DJC4ENGpE3macVQytr0BpjJhK1+XiNMHa17+Mymm
U45VDKrUgaYcYXW2L4JN
=xeSz
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
2013-02-14 6:58 ` Tomi Valkeinen
@ 2013-02-18 7:45 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-18 7:33 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
> On 2013-02-14 08:51, Archit Taneja wrote:
>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>> Hi,
>>>
>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>> omap_dss_device *dssdev)
>>>> +{
>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>> +}
>>>> +
>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>> {
>>>> int r;
>>>> struct acx565akm_device *md = &acx_dev;
>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>
>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>
>> the 'data' member of omap_dss_device has the type 'void *', we need to
>> cast it to access the panel_acx565akm_data struct pointer.
>
> You don't need an explicit cast to assign a void pointer to a pointer to
> something else (or vice versa, I think).
>
> I remember us having similar constructs in some other panel drivers
> also. I think they are unnecessary also.
I was considering keeping the get_panel_data() funcs in the panel
drivers though. This way, whenever the way of retrieving platform data
changes because of DT or CDF or something else, we would just need to
modify the get_panel_data func.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
@ 2013-02-18 7:45 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-18 7:45 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
> On 2013-02-14 08:51, Archit Taneja wrote:
>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>> Hi,
>>>
>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>> omap_dss_device *dssdev)
>>>> +{
>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>> +}
>>>> +
>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>> {
>>>> int r;
>>>> struct acx565akm_device *md = &acx_dev;
>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>
>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>
>> the 'data' member of omap_dss_device has the type 'void *', we need to
>> cast it to access the panel_acx565akm_data struct pointer.
>
> You don't need an explicit cast to assign a void pointer to a pointer to
> something else (or vice versa, I think).
>
> I remember us having similar constructs in some other panel drivers
> also. I think they are unnecessary also.
I was considering keeping the get_panel_data() funcs in the panel
drivers though. This way, whenever the way of retrieving platform data
changes because of DT or CDF or something else, we would just need to
modify the get_panel_data func.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
2013-02-18 7:45 ` Archit Taneja
@ 2013-02-18 8:11 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-18 8:11 UTC (permalink / raw)
To: Archit Taneja; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]
On 2013-02-18 09:33, Archit Taneja wrote:
> On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
>> On 2013-02-14 08:51, Archit Taneja wrote:
>>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>>> Hi,
>>>>
>>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>>> omap_dss_device *dssdev)
>>>>> +{
>>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>>> +}
>>>>> +
>>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>>> {
>>>>> int r;
>>>>> struct acx565akm_device *md = &acx_dev;
>>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>>
>>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>>
>>> the 'data' member of omap_dss_device has the type 'void *', we need to
>>> cast it to access the panel_acx565akm_data struct pointer.
>>
>> You don't need an explicit cast to assign a void pointer to a pointer to
>> something else (or vice versa, I think).
>>
>> I remember us having similar constructs in some other panel drivers
>> also. I think they are unnecessary also.
>
> I was considering keeping the get_panel_data() funcs in the panel
> drivers though. This way, whenever the way of retrieving platform data
> changes because of DT or CDF or something else, we would just need to
> modify the get_panel_data func.
I think it's simpler if we manage the fetching of the platform data in
probe one, and just store a struct panel_acx565akm_data or such to the
panel driver's data.
For DT we don't have platform data, but we can create the same platform
data struct from the DT properties.
So the above would become something like:
struct acx565akm_device *md = &acx_dev;
struct panel_acx565akm_data *panel_data = md->pdata;
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
@ 2013-02-18 8:11 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-02-18 8:11 UTC (permalink / raw)
To: Archit Taneja; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]
On 2013-02-18 09:33, Archit Taneja wrote:
> On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
>> On 2013-02-14 08:51, Archit Taneja wrote:
>>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>>> Hi,
>>>>
>>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>>> omap_dss_device *dssdev)
>>>>> +{
>>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>>> +}
>>>>> +
>>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>>> {
>>>>> int r;
>>>>> struct acx565akm_device *md = &acx_dev;
>>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>>
>>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>>
>>> the 'data' member of omap_dss_device has the type 'void *', we need to
>>> cast it to access the panel_acx565akm_data struct pointer.
>>
>> You don't need an explicit cast to assign a void pointer to a pointer to
>> something else (or vice versa, I think).
>>
>> I remember us having similar constructs in some other panel drivers
>> also. I think they are unnecessary also.
>
> I was considering keeping the get_panel_data() funcs in the panel
> drivers though. This way, whenever the way of retrieving platform data
> changes because of DT or CDF or something else, we would just need to
> modify the get_panel_data func.
I think it's simpler if we manage the fetching of the platform data in
probe one, and just store a struct panel_acx565akm_data or such to the
panel driver's data.
For DT we don't have platform data, but we can create the same platform
data struct from the DT properties.
So the above would become something like:
struct acx565akm_device *md = &acx_dev;
struct panel_acx565akm_data *panel_data = md->pdata;
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
2013-02-18 8:11 ` Tomi Valkeinen
@ 2013-02-18 8:35 ` Archit Taneja
-1 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-18 8:23 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
On Monday 18 February 2013 01:41 PM, Tomi Valkeinen wrote:
> On 2013-02-18 09:33, Archit Taneja wrote:
>> On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
>>> On 2013-02-14 08:51, Archit Taneja wrote:
>>>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>>>> omap_dss_device *dssdev)
>>>>>> +{
>>>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>>>> +}
>>>>>> +
>>>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>>>> {
>>>>>> int r;
>>>>>> struct acx565akm_device *md = &acx_dev;
>>>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>>>
>>>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>>>
>>>> the 'data' member of omap_dss_device has the type 'void *', we need to
>>>> cast it to access the panel_acx565akm_data struct pointer.
>>>
>>> You don't need an explicit cast to assign a void pointer to a pointer to
>>> something else (or vice versa, I think).
>>>
>>> I remember us having similar constructs in some other panel drivers
>>> also. I think they are unnecessary also.
>>
>> I was considering keeping the get_panel_data() funcs in the panel
>> drivers though. This way, whenever the way of retrieving platform data
>> changes because of DT or CDF or something else, we would just need to
>> modify the get_panel_data func.
>
> I think it's simpler if we manage the fetching of the platform data in
> probe one, and just store a struct panel_acx565akm_data or such to the
> panel driver's data.
>
> For DT we don't have platform data, but we can create the same platform
> data struct from the DT properties.
>
> So the above would become something like:
>
> struct acx565akm_device *md = &acx_dev;
> struct panel_acx565akm_data *panel_data = md->pdata;
okay, that seems to be a better way.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
@ 2013-02-18 8:35 ` Archit Taneja
0 siblings, 0 replies; 134+ messages in thread
From: Archit Taneja @ 2013-02-18 8:35 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
On Monday 18 February 2013 01:41 PM, Tomi Valkeinen wrote:
> On 2013-02-18 09:33, Archit Taneja wrote:
>> On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
>>> On 2013-02-14 08:51, Archit Taneja wrote:
>>>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>>>> omap_dss_device *dssdev)
>>>>>> +{
>>>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>>>> +}
>>>>>> +
>>>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>>>> {
>>>>>> int r;
>>>>>> struct acx565akm_device *md = &acx_dev;
>>>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>>>
>>>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>>>
>>>> the 'data' member of omap_dss_device has the type 'void *', we need to
>>>> cast it to access the panel_acx565akm_data struct pointer.
>>>
>>> You don't need an explicit cast to assign a void pointer to a pointer to
>>> something else (or vice versa, I think).
>>>
>>> I remember us having similar constructs in some other panel drivers
>>> also. I think they are unnecessary also.
>>
>> I was considering keeping the get_panel_data() funcs in the panel
>> drivers though. This way, whenever the way of retrieving platform data
>> changes because of DT or CDF or something else, we would just need to
>> modify the get_panel_data func.
>
> I think it's simpler if we manage the fetching of the platform data in
> probe one, and just store a struct panel_acx565akm_data or such to the
> panel driver's data.
>
> For DT we don't have platform data, but we can create the same platform
> data struct from the DT properties.
>
> So the above would become something like:
>
> struct acx565akm_device *md = &acx_dev;
> struct panel_acx565akm_data *panel_data = md->pdata;
okay, that seems to be a better way.
Archit
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-02-14 13:51 ` Igor Grinberg
@ 2013-04-03 12:02 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-03 12:02 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]
On 2013-02-14 15:51, Igor Grinberg wrote:
> On 02/14/13 14:52, Tomi Valkeinen wrote:
>> On 2013-02-14 14:37, Igor Grinberg wrote:
>>> On 02/14/13 12:59, Tomi Valkeinen wrote:
>>>> On 2013-02-14 11:43, Igor Grinberg wrote:
>>>
>>>>>> True, it's generic, but does it work reliably? The panel hardware is now
>>>>>> partly handled in the backlight driver, and partly in the omap's panel
>>>>>> driver (and wherever on other platforms).
>>>>>
>>>>> It works reliably on other platforms, but not on OMAP - because
>>>>> we need to cope with the OMAP specific framework...
>>>
>>>> How do you handle the gpios on other platform? Those are the ones
>>>> causing the issues here, right?
>>>
>>> Well, I'm also talking about something that is a history already.
>>> Remember, we had multiple panel drivers inside the
>>> video/omap2/displays and then they were consolidated into the
>>> "generic dpi/dsi/whatever".
>
>> Sorry, I miss the point. Was that a bad thing? Didn't it simplify the
>> task for you with simple panels? It could've been taken even further,
>> though (see below).
>
> Yes it was a good thing (I have already told this below).
>
>
>>> And yes you are right, on the platforms I'm aware of, the GPIO is not
>>> handled. Apparently its hardware default (pull resistor) is always on...
>
>> Ok, so the simple fix of setting the GPIOs only in the board file is
>> acceptable for now.
>
> Yep. I also told this already in one of the previous emails.
>
>
>> Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
>> backlight will supposedly be always on. Is it just a simple switch for
>> the BL power, which does not affect the SPI in any way?
>
> Yes, it can for now.
> Also, I think we should also take into account the backlight framework,
> including PMW.
I've updated this patch to set the LCD EN gpio once at boot time, and pass the
LCD BL gpio to the panel driver. Updated patch below.
---
commit a58a72363aa4359cdb75878de1517bd50faf9eb4
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon Dec 3 16:05:06 2012 +0530
arm: omap: board-cm-t35: use generic dpi panel's gpio handling
The cm-t35 board file currently requests gpios required to configure the tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: Only BL enable gpio is handled in the panel driver. The LCD enable
GPIO is handled in the board file at init time, as there's a 50 ms delay
required when using the GPIO, and the panel driver doesn't know about
that.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index bccd3e5..cccbfea 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -190,32 +190,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int lcd_enabled;
-static int dvi_enabled;
-
-static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
- gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
-
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- lcd_enabled = 0;
-
- gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
-}
-
static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@ -227,8 +201,10 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
- .platform_enable = cm_t35_panel_enable_lcd,
- .platform_disable = cm_t35_panel_disable_lcd,
+ .num_gpios = 1,
+ .gpios = {
+ CM_T35_LCD_BL_GPIO,
+ },
};
static struct omap_dss_device cm_t35_lcd_device = {
@@ -292,11 +268,6 @@ static struct spi_board_info cm_t35_lcd_spi_board_info[] __initdata = {
},
};
-static struct gpio cm_t35_dss_gpios[] __initdata = {
- { CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW, "lcd enable" },
- { CM_T35_LCD_BL_GPIO, GPIOF_OUT_INIT_LOW, "lcd bl enable" },
-};
-
static void __init cm_t35_init_display(void)
{
int err;
@@ -304,23 +275,21 @@ static void __init cm_t35_init_display(void)
spi_register_board_info(cm_t35_lcd_spi_board_info,
ARRAY_SIZE(cm_t35_lcd_spi_board_info));
- err = gpio_request_array(cm_t35_dss_gpios,
- ARRAY_SIZE(cm_t35_dss_gpios));
+
+ err = gpio_request_one(CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW,
+ "lcd bl enable");
if (err) {
- pr_err("CM-T35: failed to request DSS control GPIOs\n");
+ pr_err("CM-T35: failed to request LCD EN GPIO\n");
return;
}
- gpio_export(CM_T35_LCD_EN_GPIO, 0);
- gpio_export(CM_T35_LCD_BL_GPIO, 0);
-
msleep(50);
gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
err = omap_display_init(&cm_t35_dss_data);
if (err) {
pr_err("CM-T35: failed to register DSS device\n");
- gpio_free_array(cm_t35_dss_gpios, ARRAY_SIZE(cm_t35_dss_gpios));
+ gpio_free(CM_T35_LCD_EN_GPIO);
}
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply related [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-04-03 12:02 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-03 12:02 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]
On 2013-02-14 15:51, Igor Grinberg wrote:
> On 02/14/13 14:52, Tomi Valkeinen wrote:
>> On 2013-02-14 14:37, Igor Grinberg wrote:
>>> On 02/14/13 12:59, Tomi Valkeinen wrote:
>>>> On 2013-02-14 11:43, Igor Grinberg wrote:
>>>
>>>>>> True, it's generic, but does it work reliably? The panel hardware is now
>>>>>> partly handled in the backlight driver, and partly in the omap's panel
>>>>>> driver (and wherever on other platforms).
>>>>>
>>>>> It works reliably on other platforms, but not on OMAP - because
>>>>> we need to cope with the OMAP specific framework...
>>>
>>>> How do you handle the gpios on other platform? Those are the ones
>>>> causing the issues here, right?
>>>
>>> Well, I'm also talking about something that is a history already.
>>> Remember, we had multiple panel drivers inside the
>>> video/omap2/displays and then they were consolidated into the
>>> "generic dpi/dsi/whatever".
>
>> Sorry, I miss the point. Was that a bad thing? Didn't it simplify the
>> task for you with simple panels? It could've been taken even further,
>> though (see below).
>
> Yes it was a good thing (I have already told this below).
>
>
>>> And yes you are right, on the platforms I'm aware of, the GPIO is not
>>> handled. Apparently its hardware default (pull resistor) is always on...
>
>> Ok, so the simple fix of setting the GPIOs only in the board file is
>> acceptable for now.
>
> Yep. I also told this already in one of the previous emails.
>
>
>> Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
>> backlight will supposedly be always on. Is it just a simple switch for
>> the BL power, which does not affect the SPI in any way?
>
> Yes, it can for now.
> Also, I think we should also take into account the backlight framework,
> including PMW.
I've updated this patch to set the LCD EN gpio once at boot time, and pass the
LCD BL gpio to the panel driver. Updated patch below.
---
commit a58a72363aa4359cdb75878de1517bd50faf9eb4
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon Dec 3 16:05:06 2012 +0530
arm: omap: board-cm-t35: use generic dpi panel's gpio handling
The cm-t35 board file currently requests gpios required to configure the tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: Only BL enable gpio is handled in the panel driver. The LCD enable
GPIO is handled in the board file at init time, as there's a 50 ms delay
required when using the GPIO, and the panel driver doesn't know about
that.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index bccd3e5..cccbfea 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -190,32 +190,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int lcd_enabled;
-static int dvi_enabled;
-
-static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
- gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
-
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- lcd_enabled = 0;
-
- gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
-}
-
static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@ -227,8 +201,10 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
- .platform_enable = cm_t35_panel_enable_lcd,
- .platform_disable = cm_t35_panel_disable_lcd,
+ .num_gpios = 1,
+ .gpios = {
+ CM_T35_LCD_BL_GPIO,
+ },
};
static struct omap_dss_device cm_t35_lcd_device = {
@@ -292,11 +268,6 @@ static struct spi_board_info cm_t35_lcd_spi_board_info[] __initdata = {
},
};
-static struct gpio cm_t35_dss_gpios[] __initdata = {
- { CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW, "lcd enable" },
- { CM_T35_LCD_BL_GPIO, GPIOF_OUT_INIT_LOW, "lcd bl enable" },
-};
-
static void __init cm_t35_init_display(void)
{
int err;
@@ -304,23 +275,21 @@ static void __init cm_t35_init_display(void)
spi_register_board_info(cm_t35_lcd_spi_board_info,
ARRAY_SIZE(cm_t35_lcd_spi_board_info));
- err = gpio_request_array(cm_t35_dss_gpios,
- ARRAY_SIZE(cm_t35_dss_gpios));
+
+ err = gpio_request_one(CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW,
+ "lcd bl enable");
if (err) {
- pr_err("CM-T35: failed to request DSS control GPIOs\n");
+ pr_err("CM-T35: failed to request LCD EN GPIO\n");
return;
}
- gpio_export(CM_T35_LCD_EN_GPIO, 0);
- gpio_export(CM_T35_LCD_BL_GPIO, 0);
-
msleep(50);
gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
err = omap_display_init(&cm_t35_dss_data);
if (err) {
pr_err("CM-T35: failed to register DSS device\n");
- gpio_free_array(cm_t35_dss_gpios, ARRAY_SIZE(cm_t35_dss_gpios));
+ gpio_free(CM_T35_LCD_EN_GPIO);
}
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply related [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-02-13 16:46 ` Tony Lindgren
@ 2013-04-03 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-03 12:28 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Archit Taneja, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]
Hi Tony,
On 2013-02-13 18:46, Tony Lindgren wrote:
> * Archit Taneja <archit@ti.com> [130213 06:26]:
>> init functions in omap board files request panel specific gpios, and provide
>> functions which omapdss panel drivers call to enable or disable them.
>>
>> Instead of the board files requesting these gpios, they should just pass the
>> platform specific data(like the gpio numbers), the panel should retrieve the
>> platform data and request the gpios. Doing this prevents the need of the panel
>> driver calling platform functions in board files.
>>
>> Panel drivers have their own platform data struct, and the board files populate
>> these structs and pass the pointer to the 'data' field of omap_dss_device. This
>> work will make it easier for the panel drivers be more adaptable to the
>> DT model.
>>
>> There is also removal of passing panel reset_gpio numbers through
>> omap_dss_device struct directly, reset gpios are passed through platform data
>> only.
>
> To avoid merge conflicts and dependencies between drivers and core
> Soc code, please break thes kind of patches into following parts:
>
> 1. Any platform_data header changes needed so both I and Tomi
> can pull it in as needed.
>
> 2. Changes to DSS drivers. Please keep stubs around for the
> board specific callback functions so omap2plus_defconfig
> won't break with just #1 merged into arm soc tree.
>
> 3. All the arch/arm/*omap* changes based on #1 above to
> drop obsolete callback functions and add new pdata if still
> needed. This needs to build and boot on #1 so I can merge
> this in via arm soc tree.
>
> 4. Any .dts changes needed.
Tony, I've split these patches as follows:
Platform data header file changes:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
Board file changes (based on header changes):
git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
DSS panel changes (based on header changes):
git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup
Removing unused fields from header files (based on panel changes):
git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup
The 2-late-panel-cleanup breaks compilation if the arch changes are not
merged, so I'll leave that until they have been merged.
Do you mind if I add the board-cleanup branch temporarily to omapdss's
for-next, to simplify testing? When everything looks ok, I'll remove it
and pass the branch to you to be handled through l-o.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-04-03 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-03 12:28 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Archit Taneja, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]
Hi Tony,
On 2013-02-13 18:46, Tony Lindgren wrote:
> * Archit Taneja <archit@ti.com> [130213 06:26]:
>> init functions in omap board files request panel specific gpios, and provide
>> functions which omapdss panel drivers call to enable or disable them.
>>
>> Instead of the board files requesting these gpios, they should just pass the
>> platform specific data(like the gpio numbers), the panel should retrieve the
>> platform data and request the gpios. Doing this prevents the need of the panel
>> driver calling platform functions in board files.
>>
>> Panel drivers have their own platform data struct, and the board files populate
>> these structs and pass the pointer to the 'data' field of omap_dss_device. This
>> work will make it easier for the panel drivers be more adaptable to the
>> DT model.
>>
>> There is also removal of passing panel reset_gpio numbers through
>> omap_dss_device struct directly, reset gpios are passed through platform data
>> only.
>
> To avoid merge conflicts and dependencies between drivers and core
> Soc code, please break thes kind of patches into following parts:
>
> 1. Any platform_data header changes needed so both I and Tomi
> can pull it in as needed.
>
> 2. Changes to DSS drivers. Please keep stubs around for the
> board specific callback functions so omap2plus_defconfig
> won't break with just #1 merged into arm soc tree.
>
> 3. All the arch/arm/*omap* changes based on #1 above to
> drop obsolete callback functions and add new pdata if still
> needed. This needs to build and boot on #1 so I can merge
> this in via arm soc tree.
>
> 4. Any .dts changes needed.
Tony, I've split these patches as follows:
Platform data header file changes:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
Board file changes (based on header changes):
git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
DSS panel changes (based on header changes):
git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup
Removing unused fields from header files (based on panel changes):
git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup
The 2-late-panel-cleanup breaks compilation if the arch changes are not
merged, so I'll leave that until they have been merged.
Do you mind if I add the board-cleanup branch temporarily to omapdss's
for-next, to simplify testing? When everything looks ok, I'll remove it
and pass the branch to you to be handled through l-o.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-04-03 12:28 ` Tomi Valkeinen
@ 2013-04-03 15:46 ` Tony Lindgren
-1 siblings, 0 replies; 134+ messages in thread
From: Tony Lindgren @ 2013-04-03 15:46 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130403 05:32]:
> Hi Tony,
>
> On 2013-02-13 18:46, Tony Lindgren wrote:
> > * Archit Taneja <archit@ti.com> [130213 06:26]:
> >> init functions in omap board files request panel specific gpios, and provide
> >> functions which omapdss panel drivers call to enable or disable them.
> >>
> >> Instead of the board files requesting these gpios, they should just pass the
> >> platform specific data(like the gpio numbers), the panel should retrieve the
> >> platform data and request the gpios. Doing this prevents the need of the panel
> >> driver calling platform functions in board files.
> >>
> >> Panel drivers have their own platform data struct, and the board files populate
> >> these structs and pass the pointer to the 'data' field of omap_dss_device. This
> >> work will make it easier for the panel drivers be more adaptable to the
> >> DT model.
> >>
> >> There is also removal of passing panel reset_gpio numbers through
> >> omap_dss_device struct directly, reset gpios are passed through platform data
> >> only.
> >
> > To avoid merge conflicts and dependencies between drivers and core
> > Soc code, please break thes kind of patches into following parts:
> >
> > 1. Any platform_data header changes needed so both I and Tomi
> > can pull it in as needed.
> >
> > 2. Changes to DSS drivers. Please keep stubs around for the
> > board specific callback functions so omap2plus_defconfig
> > won't break with just #1 merged into arm soc tree.
> >
> > 3. All the arch/arm/*omap* changes based on #1 above to
> > drop obsolete callback functions and add new pdata if still
> > needed. This needs to build and boot on #1 so I can merge
> > this in via arm soc tree.
> >
> > 4. Any .dts changes needed.
>
> Tony, I've split these patches as follows:
>
> Platform data header file changes:
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>
> Board file changes (based on header changes):
> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
>
> DSS panel changes (based on header changes):
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup
>
> Removing unused fields from header files (based on panel changes):
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup
>
> The 2-late-panel-cleanup breaks compilation if the arch changes are not
> merged, so I'll leave that until they have been merged.
>
> Do you mind if I add the board-cleanup branch temporarily to omapdss's
> for-next, to simplify testing? When everything looks ok, I'll remove it
> and pass the branch to you to be handled through l-o.
Sure please go ahead. There are still some board-*.c related patches
that I have not merged, but we'll see those merge conflicts before
next as I usually do a merge with next before sending out pull reqs.
Regards,
Tony
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-04-03 15:46 ` Tony Lindgren
0 siblings, 0 replies; 134+ messages in thread
From: Tony Lindgren @ 2013-04-03 15:46 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130403 05:32]:
> Hi Tony,
>
> On 2013-02-13 18:46, Tony Lindgren wrote:
> > * Archit Taneja <archit@ti.com> [130213 06:26]:
> >> init functions in omap board files request panel specific gpios, and provide
> >> functions which omapdss panel drivers call to enable or disable them.
> >>
> >> Instead of the board files requesting these gpios, they should just pass the
> >> platform specific data(like the gpio numbers), the panel should retrieve the
> >> platform data and request the gpios. Doing this prevents the need of the panel
> >> driver calling platform functions in board files.
> >>
> >> Panel drivers have their own platform data struct, and the board files populate
> >> these structs and pass the pointer to the 'data' field of omap_dss_device. This
> >> work will make it easier for the panel drivers be more adaptable to the
> >> DT model.
> >>
> >> There is also removal of passing panel reset_gpio numbers through
> >> omap_dss_device struct directly, reset gpios are passed through platform data
> >> only.
> >
> > To avoid merge conflicts and dependencies between drivers and core
> > Soc code, please break thes kind of patches into following parts:
> >
> > 1. Any platform_data header changes needed so both I and Tomi
> > can pull it in as needed.
> >
> > 2. Changes to DSS drivers. Please keep stubs around for the
> > board specific callback functions so omap2plus_defconfig
> > won't break with just #1 merged into arm soc tree.
> >
> > 3. All the arch/arm/*omap* changes based on #1 above to
> > drop obsolete callback functions and add new pdata if still
> > needed. This needs to build and boot on #1 so I can merge
> > this in via arm soc tree.
> >
> > 4. Any .dts changes needed.
>
> Tony, I've split these patches as follows:
>
> Platform data header file changes:
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>
> Board file changes (based on header changes):
> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
>
> DSS panel changes (based on header changes):
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup
>
> Removing unused fields from header files (based on panel changes):
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup
>
> The 2-late-panel-cleanup breaks compilation if the arch changes are not
> merged, so I'll leave that until they have been merged.
>
> Do you mind if I add the board-cleanup branch temporarily to omapdss's
> for-next, to simplify testing? When everything looks ok, I'll remove it
> and pass the branch to you to be handled through l-o.
Sure please go ahead. There are still some board-*.c related patches
that I have not merged, but we'll see those merge conflicts before
next as I usually do a merge with next before sending out pull reqs.
Regards,
Tony
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
2013-04-03 12:02 ` Tomi Valkeinen
@ 2013-04-04 7:17 ` Igor Grinberg
-1 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-04-04 7:17 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[...]
>>> Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
>>> backlight will supposedly be always on. Is it just a simple switch for
>>> the BL power, which does not affect the SPI in any way?
>>
>> Yes, it can for now.
>> Also, I think we should also take into account the backlight framework,
>> including PMW.
>
> I've updated this patch to set the LCD EN gpio once at boot time, and pass the
> LCD BL gpio to the panel driver. Updated patch below.
>
> ---
>
> commit a58a72363aa4359cdb75878de1517bd50faf9eb4
> Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Mon Dec 3 16:05:06 2012 +0530
>
> arm: omap: board-cm-t35: use generic dpi panel's gpio handling
>
> The cm-t35 board file currently requests gpios required to configure the tdo35s
> panel, and provides platform_enable/disable callbacks to configure them.
>
> These tasks have been moved to the generic dpi panel driver itself and shouldn't
> be done in the board files.
>
> Remove the gpio requests and the platform callbacks from the board file.
> Add the gpio information to generic dpi panel's platform data so that it's
> passed to the panel driver.
>
> Note: Only BL enable gpio is handled in the panel driver. The LCD enable
> GPIO is handled in the board file at init time, as there's a 50 ms delay
> required when using the GPIO, and the panel driver doesn't know about
> that.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Looks good, thanks!
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
> index bccd3e5..cccbfea 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -190,32 +190,6 @@ static inline void cm_t35_init_nand(void) {}
> #define CM_T35_LCD_BL_GPIO 58
> #define CM_T35_DVI_EN_GPIO 54
>
> -static int lcd_enabled;
> -static int dvi_enabled;
> -
> -static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
> -{
> - if (dvi_enabled) {
> - printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> - return -EINVAL;
> - }
> -
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
> -
> - lcd_enabled = 1;
> -
> - return 0;
> -}
> -
> -static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
> -{
> - lcd_enabled = 0;
> -
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
> -}
> -
> static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
> {
> return 0;
> @@ -227,8 +201,10 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
>
> static struct panel_generic_dpi_data lcd_panel = {
> .name = "toppoly_tdo35s",
> - .platform_enable = cm_t35_panel_enable_lcd,
> - .platform_disable = cm_t35_panel_disable_lcd,
> + .num_gpios = 1,
> + .gpios = {
> + CM_T35_LCD_BL_GPIO,
> + },
> };
>
> static struct omap_dss_device cm_t35_lcd_device = {
> @@ -292,11 +268,6 @@ static struct spi_board_info cm_t35_lcd_spi_board_info[] __initdata = {
> },
> };
>
> -static struct gpio cm_t35_dss_gpios[] __initdata = {
> - { CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW, "lcd enable" },
> - { CM_T35_LCD_BL_GPIO, GPIOF_OUT_INIT_LOW, "lcd bl enable" },
> -};
> -
> static void __init cm_t35_init_display(void)
> {
> int err;
> @@ -304,23 +275,21 @@ static void __init cm_t35_init_display(void)
> spi_register_board_info(cm_t35_lcd_spi_board_info,
> ARRAY_SIZE(cm_t35_lcd_spi_board_info));
>
> - err = gpio_request_array(cm_t35_dss_gpios,
> - ARRAY_SIZE(cm_t35_dss_gpios));
> +
> + err = gpio_request_one(CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW,
> + "lcd bl enable");
> if (err) {
> - pr_err("CM-T35: failed to request DSS control GPIOs\n");
> + pr_err("CM-T35: failed to request LCD EN GPIO\n");
> return;
> }
>
> - gpio_export(CM_T35_LCD_EN_GPIO, 0);
> - gpio_export(CM_T35_LCD_BL_GPIO, 0);
> -
> msleep(50);
> gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
>
> err = omap_display_init(&cm_t35_dss_data);
> if (err) {
> pr_err("CM-T35: failed to register DSS device\n");
> - gpio_free_array(cm_t35_dss_gpios, ARRAY_SIZE(cm_t35_dss_gpios));
> + gpio_free(CM_T35_LCD_EN_GPIO);
> }
> }
>
>
>
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRXSjtAAoJEBDE8YO64EfakqEP/RxTWET2KP1KRIs5VW6o6JXG
w4Mil7k62AmpClojEWMJTF6UfOc08Zmg4m5ZPly1mT2NAgwtwStP1hkTRuPuL34w
NMfbwro5uUf4Wp49ZxZyuLLEnlzVh8VPWPmHKc+pRl9XQOqS9fau+EBxmIXKSAgC
qdAjeT6ONIXhvIqVsgY+7oexeD0DG4GQiYl9/VPo7VWh1/Whv4X53WVMz6gdgfIm
ax0h/XYPAt743EoAyh7QHas4XkXsULmesJH4Pn7RE2BCtyuHYV1QB6Sut1gAmKMd
WUILWCHIdpOhH7JxcdIgSLbQVbHph2sPmtKoesO75LzgzcwA4YeX2ZOOHhgF5BDp
JnNzMtf/cxzkmzQm2FagIgr7vZAA1/eECit//20xEnHeVl9icKTiDBltunbYkphR
WUIGxCxIKlUhKG1OwDeSWRPbAY3ZvPQXSPpcSSGmvdxae9H0+xkwN1+l4MlPGVe0
G1cEclDxLiefueskIOVSs0nmlpxF7fBcCVq1dEL7Su5P1P1gdSsgEe/V5AAFAymf
RbLhqt4l9+5y6ow/tSRIPTUCUvGqJoYGwDWFhiD+Cyy2b2g5vOHQGQCZ2wqsSrxY
V5m6h5pKxdH9ibDFeQemNbAqz86nuk6sfUSk0dOX7vYt1zMSRwbZ8cdaB1zgrT23
d5A216IHqnW5iLhaJxbx
=GpgV
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
@ 2013-04-04 7:17 ` Igor Grinberg
0 siblings, 0 replies; 134+ messages in thread
From: Igor Grinberg @ 2013-04-04 7:17 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev, Tony Lindgren
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[...]
>>> Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
>>> backlight will supposedly be always on. Is it just a simple switch for
>>> the BL power, which does not affect the SPI in any way?
>>
>> Yes, it can for now.
>> Also, I think we should also take into account the backlight framework,
>> including PMW.
>
> I've updated this patch to set the LCD EN gpio once at boot time, and pass the
> LCD BL gpio to the panel driver. Updated patch below.
>
> ---
>
> commit a58a72363aa4359cdb75878de1517bd50faf9eb4
> Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Mon Dec 3 16:05:06 2012 +0530
>
> arm: omap: board-cm-t35: use generic dpi panel's gpio handling
>
> The cm-t35 board file currently requests gpios required to configure the tdo35s
> panel, and provides platform_enable/disable callbacks to configure them.
>
> These tasks have been moved to the generic dpi panel driver itself and shouldn't
> be done in the board files.
>
> Remove the gpio requests and the platform callbacks from the board file.
> Add the gpio information to generic dpi panel's platform data so that it's
> passed to the panel driver.
>
> Note: Only BL enable gpio is handled in the panel driver. The LCD enable
> GPIO is handled in the board file at init time, as there's a 50 ms delay
> required when using the GPIO, and the panel driver doesn't know about
> that.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Looks good, thanks!
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
> index bccd3e5..cccbfea 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -190,32 +190,6 @@ static inline void cm_t35_init_nand(void) {}
> #define CM_T35_LCD_BL_GPIO 58
> #define CM_T35_DVI_EN_GPIO 54
>
> -static int lcd_enabled;
> -static int dvi_enabled;
> -
> -static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
> -{
> - if (dvi_enabled) {
> - printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> - return -EINVAL;
> - }
> -
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
> -
> - lcd_enabled = 1;
> -
> - return 0;
> -}
> -
> -static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
> -{
> - lcd_enabled = 0;
> -
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
> -}
> -
> static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
> {
> return 0;
> @@ -227,8 +201,10 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
>
> static struct panel_generic_dpi_data lcd_panel = {
> .name = "toppoly_tdo35s",
> - .platform_enable = cm_t35_panel_enable_lcd,
> - .platform_disable = cm_t35_panel_disable_lcd,
> + .num_gpios = 1,
> + .gpios = {
> + CM_T35_LCD_BL_GPIO,
> + },
> };
>
> static struct omap_dss_device cm_t35_lcd_device = {
> @@ -292,11 +268,6 @@ static struct spi_board_info cm_t35_lcd_spi_board_info[] __initdata = {
> },
> };
>
> -static struct gpio cm_t35_dss_gpios[] __initdata = {
> - { CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW, "lcd enable" },
> - { CM_T35_LCD_BL_GPIO, GPIOF_OUT_INIT_LOW, "lcd bl enable" },
> -};
> -
> static void __init cm_t35_init_display(void)
> {
> int err;
> @@ -304,23 +275,21 @@ static void __init cm_t35_init_display(void)
> spi_register_board_info(cm_t35_lcd_spi_board_info,
> ARRAY_SIZE(cm_t35_lcd_spi_board_info));
>
> - err = gpio_request_array(cm_t35_dss_gpios,
> - ARRAY_SIZE(cm_t35_dss_gpios));
> +
> + err = gpio_request_one(CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW,
> + "lcd bl enable");
> if (err) {
> - pr_err("CM-T35: failed to request DSS control GPIOs\n");
> + pr_err("CM-T35: failed to request LCD EN GPIO\n");
> return;
> }
>
> - gpio_export(CM_T35_LCD_EN_GPIO, 0);
> - gpio_export(CM_T35_LCD_BL_GPIO, 0);
> -
> msleep(50);
> gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
>
> err = omap_display_init(&cm_t35_dss_data);
> if (err) {
> pr_err("CM-T35: failed to register DSS device\n");
> - gpio_free_array(cm_t35_dss_gpios, ARRAY_SIZE(cm_t35_dss_gpios));
> + gpio_free(CM_T35_LCD_EN_GPIO);
> }
> }
>
>
>
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRXSjtAAoJEBDE8YO64EfakqEP/RxTWET2KP1KRIs5VW6o6JXG
w4Mil7k62AmpClojEWMJTF6UfOc08Zmg4m5ZPly1mT2NAgwtwStP1hkTRuPuL34w
NMfbwro5uUf4Wp49ZxZyuLLEnlzVh8VPWPmHKc+pRl9XQOqS9fau+EBxmIXKSAgC
qdAjeT6ONIXhvIqVsgY+7oexeD0DG4GQiYl9/VPo7VWh1/Whv4X53WVMz6gdgfIm
ax0h/XYPAt743EoAyh7QHas4XkXsULmesJH4Pn7RE2BCtyuHYV1QB6Sut1gAmKMd
WUILWCHIdpOhH7JxcdIgSLbQVbHph2sPmtKoesO75LzgzcwA4YeX2ZOOHhgF5BDp
JnNzMtf/cxzkmzQm2FagIgr7vZAA1/eECit//20xEnHeVl9icKTiDBltunbYkphR
WUIGxCxIKlUhKG1OwDeSWRPbAY3ZvPQXSPpcSSGmvdxae9H0+xkwN1+l4MlPGVe0
G1cEclDxLiefueskIOVSs0nmlpxF7fBcCVq1dEL7Su5P1P1gdSsgEe/V5AAFAymf
RbLhqt4l9+5y6ow/tSRIPTUCUvGqJoYGwDWFhiD+Cyy2b2g5vOHQGQCZ2wqsSrxY
V5m6h5pKxdH9ibDFeQemNbAqz86nuk6sfUSk0dOX7vYt1zMSRwbZ8cdaB1zgrT23
d5A216IHqnW5iLhaJxbx
=GpgV
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-04-03 15:46 ` Tony Lindgren
@ 2013-04-15 9:29 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-15 9:29 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Archit Taneja, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
Hi Tony,
On 2013-04-03 18:46, Tony Lindgren wrote:
>> Tony, I've split these patches as follows:
>>
>> Platform data header file changes:
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>>
>> Board file changes (based on header changes):
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
>>
>> DSS panel changes (based on header changes):
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup
>>
>> Removing unused fields from header files (based on panel changes):
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup
>>
>> The 2-late-panel-cleanup breaks compilation if the arch changes are not
>> merged, so I'll leave that until they have been merged.
>>
>> Do you mind if I add the board-cleanup branch temporarily to omapdss's
>> for-next, to simplify testing? When everything looks ok, I'll remove it
>> and pass the branch to you to be handled through l-o.
>
> Sure please go ahead. There are still some board-*.c related patches
> that I have not merged, but we'll see those merge conflicts before
> next as I usually do a merge with next before sending out pull reqs.
The code seems to work ok, so I think we can declare the branches
stable. I've pushed new for-next branch that does not contain the arch
files anymore. In fact, I removed all omapdss patches also, as omapdss
should be merged through the drm tree, and I don't want to have
conflicts with drm's for-next branch.
So, to recap, the common header changes are located in:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
And the branch for linux-omap is:
git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
After merging those, some displays won't start anymore until the omapdss
changes are in, but things should still compile.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-04-15 9:29 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-15 9:29 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Archit Taneja, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
Hi Tony,
On 2013-04-03 18:46, Tony Lindgren wrote:
>> Tony, I've split these patches as follows:
>>
>> Platform data header file changes:
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>>
>> Board file changes (based on header changes):
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
>>
>> DSS panel changes (based on header changes):
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup
>>
>> Removing unused fields from header files (based on panel changes):
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup
>>
>> The 2-late-panel-cleanup breaks compilation if the arch changes are not
>> merged, so I'll leave that until they have been merged.
>>
>> Do you mind if I add the board-cleanup branch temporarily to omapdss's
>> for-next, to simplify testing? When everything looks ok, I'll remove it
>> and pass the branch to you to be handled through l-o.
>
> Sure please go ahead. There are still some board-*.c related patches
> that I have not merged, but we'll see those merge conflicts before
> next as I usually do a merge with next before sending out pull reqs.
The code seems to work ok, so I think we can declare the branches
stable. I've pushed new for-next branch that does not contain the arch
files anymore. In fact, I removed all omapdss patches also, as omapdss
should be merged through the drm tree, and I don't want to have
conflicts with drm's for-next branch.
So, to recap, the common header changes are located in:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
And the branch for linux-omap is:
git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
After merging those, some displays won't start anymore until the omapdss
changes are in, but things should still compile.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-04-15 9:29 ` Tomi Valkeinen
@ 2013-04-15 21:20 ` Tony Lindgren
-1 siblings, 0 replies; 134+ messages in thread
From: Tony Lindgren @ 2013-04-15 21:20 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130415 02:34]:
> Hi Tony,
>
> On 2013-04-03 18:46, Tony Lindgren wrote:
>
> >> Tony, I've split these patches as follows:
> >>
> >> Platform data header file changes:
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
> >>
> >> Board file changes (based on header changes):
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
> >>
> >> DSS panel changes (based on header changes):
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup
> >>
> >> Removing unused fields from header files (based on panel changes):
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup
> >>
> >> The 2-late-panel-cleanup breaks compilation if the arch changes are not
> >> merged, so I'll leave that until they have been merged.
> >>
> >> Do you mind if I add the board-cleanup branch temporarily to omapdss's
> >> for-next, to simplify testing? When everything looks ok, I'll remove it
> >> and pass the branch to you to be handled through l-o.
> >
> > Sure please go ahead. There are still some board-*.c related patches
> > that I have not merged, but we'll see those merge conflicts before
> > next as I usually do a merge with next before sending out pull reqs.
>
> The code seems to work ok, so I think we can declare the branches
> stable. I've pushed new for-next branch that does not contain the arch
> files anymore. In fact, I removed all omapdss patches also, as omapdss
> should be merged through the drm tree, and I don't want to have
> conflicts with drm's for-next branch.
>
> So, to recap, the common header changes are located in:
>
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>
> And the branch for linux-omap is:
>
> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
>
> After merging those, some displays won't start anymore until the omapdss
> changes are in, but things should still compile.
Sounds like it's best that you merge those branches via your
tree as the conflicts have been already resolved in linux next.
Regards,
Tony
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-04-15 21:20 ` Tony Lindgren
0 siblings, 0 replies; 134+ messages in thread
From: Tony Lindgren @ 2013-04-15 21:20 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130415 02:34]:
> Hi Tony,
>
> On 2013-04-03 18:46, Tony Lindgren wrote:
>
> >> Tony, I've split these patches as follows:
> >>
> >> Platform data header file changes:
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
> >>
> >> Board file changes (based on header changes):
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
> >>
> >> DSS panel changes (based on header changes):
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup
> >>
> >> Removing unused fields from header files (based on panel changes):
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup
> >>
> >> The 2-late-panel-cleanup breaks compilation if the arch changes are not
> >> merged, so I'll leave that until they have been merged.
> >>
> >> Do you mind if I add the board-cleanup branch temporarily to omapdss's
> >> for-next, to simplify testing? When everything looks ok, I'll remove it
> >> and pass the branch to you to be handled through l-o.
> >
> > Sure please go ahead. There are still some board-*.c related patches
> > that I have not merged, but we'll see those merge conflicts before
> > next as I usually do a merge with next before sending out pull reqs.
>
> The code seems to work ok, so I think we can declare the branches
> stable. I've pushed new for-next branch that does not contain the arch
> files anymore. In fact, I removed all omapdss patches also, as omapdss
> should be merged through the drm tree, and I don't want to have
> conflicts with drm's for-next branch.
>
> So, to recap, the common header changes are located in:
>
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>
> And the branch for linux-omap is:
>
> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
>
> After merging those, some displays won't start anymore until the omapdss
> changes are in, but things should still compile.
Sounds like it's best that you merge those branches via your
tree as the conflicts have been already resolved in linux next.
Regards,
Tony
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-04-15 21:20 ` Tony Lindgren
@ 2013-04-16 4:20 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-16 4:20 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Archit Taneja, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
On 2013-04-16 00:20, Tony Lindgren wrote:
>> So, to recap, the common header changes are located in:
>>
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>>
>> And the branch for linux-omap is:
>>
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
>>
>> After merging those, some displays won't start anymore until the omapdss
>> changes are in, but things should still compile.
>
> Sounds like it's best that you merge those branches via your
> tree as the conflicts have been already resolved in linux next.
The dss changes are going through drm tree this time, as there are some
drm dependencies also, and I've already sent the pull request for those.
And when I asked Dave Airlie if he can merge the dss changes, I didn't
talk about a big chunk of arch file changes getting included.
Also, the whole division to two independent branches was done only to
make it possible for the arch changes to go through l-o tree.
There will probably be more these kind of changes in the future, so I
think we should agree how to handle those and stick to the plan.
Dividing the arch file changes to a separate branch is often quite
laborious, and I'd rather not do that for nothing.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-04-16 4:20 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-16 4:20 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Archit Taneja, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
On 2013-04-16 00:20, Tony Lindgren wrote:
>> So, to recap, the common header changes are located in:
>>
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>>
>> And the branch for linux-omap is:
>>
>> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
>>
>> After merging those, some displays won't start anymore until the omapdss
>> changes are in, but things should still compile.
>
> Sounds like it's best that you merge those branches via your
> tree as the conflicts have been already resolved in linux next.
The dss changes are going through drm tree this time, as there are some
drm dependencies also, and I've already sent the pull request for those.
And when I asked Dave Airlie if he can merge the dss changes, I didn't
talk about a big chunk of arch file changes getting included.
Also, the whole division to two independent branches was done only to
make it possible for the arch changes to go through l-o tree.
There will probably be more these kind of changes in the future, so I
think we should agree how to handle those and stick to the plan.
Dividing the arch file changes to a separate branch is often quite
laborious, and I'd rather not do that for nothing.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-04-16 4:20 ` Tomi Valkeinen
@ 2013-04-18 0:34 ` Tony Lindgren
-1 siblings, 0 replies; 134+ messages in thread
From: Tony Lindgren @ 2013-04-18 0:34 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130415 21:25]:
> On 2013-04-16 00:20, Tony Lindgren wrote:
>
> >> So, to recap, the common header changes are located in:
> >>
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
> >>
> >> And the branch for linux-omap is:
> >>
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
> >>
> >> After merging those, some displays won't start anymore until the omapdss
> >> changes are in, but things should still compile.
> >
> > Sounds like it's best that you merge those branches via your
> > tree as the conflicts have been already resolved in linux next.
>
> The dss changes are going through drm tree this time, as there are some
> drm dependencies also, and I've already sent the pull request for those.
> And when I asked Dave Airlie if he can merge the dss changes, I didn't
> talk about a big chunk of arch file changes getting included.
OK sorry I did not know that and was assuming you will be sending
a pull request to Linus.
> Also, the whole division to two independent branches was done only to
> make it possible for the arch changes to go through l-o tree.
Yup. That probably caused you to fix up few other things while doing
it though ;)
> There will probably be more these kind of changes in the future, so I
> think we should agree how to handle those and stick to the plan.
> Dividing the arch file changes to a separate branch is often quite
> laborious, and I'd rather not do that for nothing.
Thanks for doing all that. And yes, let's plan on always separating
driver changes from arch/arm changes to cut away the dependencies.
Just one request: Let's do branches like this early on before -rc6,
not what might be five days before the merge window potentially
opens..
I've pulled them into omap-for-v3.10/dss and will send a pull
request for Arnd and Olof.
Regards,
Tony
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-04-18 0:34 ` Tony Lindgren
0 siblings, 0 replies; 134+ messages in thread
From: Tony Lindgren @ 2013-04-18 0:34 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130415 21:25]:
> On 2013-04-16 00:20, Tony Lindgren wrote:
>
> >> So, to recap, the common header changes are located in:
> >>
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
> >>
> >> And the branch for linux-omap is:
> >>
> >> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
> >>
> >> After merging those, some displays won't start anymore until the omapdss
> >> changes are in, but things should still compile.
> >
> > Sounds like it's best that you merge those branches via your
> > tree as the conflicts have been already resolved in linux next.
>
> The dss changes are going through drm tree this time, as there are some
> drm dependencies also, and I've already sent the pull request for those.
> And when I asked Dave Airlie if he can merge the dss changes, I didn't
> talk about a big chunk of arch file changes getting included.
OK sorry I did not know that and was assuming you will be sending
a pull request to Linus.
> Also, the whole division to two independent branches was done only to
> make it possible for the arch changes to go through l-o tree.
Yup. That probably caused you to fix up few other things while doing
it though ;)
> There will probably be more these kind of changes in the future, so I
> think we should agree how to handle those and stick to the plan.
> Dividing the arch file changes to a separate branch is often quite
> laborious, and I'd rather not do that for nothing.
Thanks for doing all that. And yes, let's plan on always separating
driver changes from arch/arm changes to cut away the dependencies.
Just one request: Let's do branches like this early on before -rc6,
not what might be five days before the merge window potentially
opens..
I've pulled them into omap-for-v3.10/dss and will send a pull
request for Arnd and Olof.
Regards,
Tony
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
2013-04-18 0:34 ` Tony Lindgren
@ 2013-04-18 3:40 ` Tomi Valkeinen
-1 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-18 3:40 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Archit Taneja, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
On 2013-04-18 03:34, Tony Lindgren wrote:
> Just one request: Let's do branches like this early on before -rc6,
> not what might be five days before the merge window potentially
> opens..
Agreed, it got a bit late. But the branch itself has been stable and in
linux-next for some time.
Perhaps it would've been better to merge it to l-o earlier, instead of
me pushing it to linux-next via my tree. Any possible found problems
(there weren't any this time) could've been fixed with a new fixes branch.
> I've pulled them into omap-for-v3.10/dss and will send a pull
> request for Arnd and Olof.
Ok, thanks!
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
* Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
@ 2013-04-18 3:40 ` Tomi Valkeinen
0 siblings, 0 replies; 134+ messages in thread
From: Tomi Valkeinen @ 2013-04-18 3:40 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Archit Taneja, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
On 2013-04-18 03:34, Tony Lindgren wrote:
> Just one request: Let's do branches like this early on before -rc6,
> not what might be five days before the merge window potentially
> opens..
Agreed, it got a bit late. But the branch itself has been stable and in
linux-next for some time.
Perhaps it would've been better to merge it to l-o earlier, instead of
me pushing it to linux-next via my tree. Any possible found problems
(there weren't any this time) could've been fixed with a new fixes branch.
> I've pulled them into omap-for-v3.10/dss and will send a pull
> request for Arnd and Olof.
Ok, thanks!
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 134+ messages in thread
end of thread, other threads:[~2013-04-18 3:40 UTC | newest]
Thread overview: 134+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-13 14:21 [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 01/33] OMAPDSS: panels: keep platform data of all panels in a single header Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 02/33] OMAPDSS: generic dpi panel: handle gpios in panel driver Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 03/33] arm: omap: board-2430: use generic dpi panel's gpio handling Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 04/33] arm: omap: board-devkit8000: " Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 05/33] arm: omap: board-cm-t35: " Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 15:16 ` Igor Grinberg
2013-02-13 15:16 ` Igor Grinberg
2013-02-13 15:28 ` Tomi Valkeinen
2013-02-13 15:28 ` Tomi Valkeinen
2013-02-13 15:59 ` Tomi Valkeinen
2013-02-13 15:59 ` Tomi Valkeinen
2013-02-14 6:56 ` Igor Grinberg
2013-02-14 6:56 ` Igor Grinberg
2013-02-14 7:09 ` Tomi Valkeinen
2013-02-14 7:09 ` Tomi Valkeinen
2013-02-14 8:37 ` Igor Grinberg
2013-02-14 8:37 ` Igor Grinberg
2013-02-14 9:09 ` Tomi Valkeinen
2013-02-14 9:09 ` Tomi Valkeinen
2013-02-14 9:43 ` Igor Grinberg
2013-02-14 9:43 ` Igor Grinberg
2013-02-14 10:59 ` Tomi Valkeinen
2013-02-14 10:59 ` Tomi Valkeinen
2013-02-14 12:37 ` Igor Grinberg
2013-02-14 12:37 ` Igor Grinberg
2013-02-14 12:52 ` Tomi Valkeinen
2013-02-14 12:52 ` Tomi Valkeinen
2013-02-14 13:51 ` Igor Grinberg
2013-02-14 13:51 ` Igor Grinberg
2013-04-03 12:02 ` Tomi Valkeinen
2013-04-03 12:02 ` Tomi Valkeinen
2013-04-04 7:17 ` Igor Grinberg
2013-04-04 7:17 ` Igor Grinberg
2013-02-13 14:21 ` [PATCH 06/33] arm: omap: board-apollon: " Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 07/33] arm: omap: board-am3517: " Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 08/33] arm: omap: board-ldp: " Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 09/33] OMAPDSS: lb035q02: handle gpios in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 10/33] arm: omap: board-overo: use lb035q02 dpi panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 11/33] OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 12/33] OMAPDSS: generic dpi panel: remove platform_enable/disable ops from platform_data Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 13/33] arm: omap: board-omap3evm: use sharp panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 14/33] arm: omap: board-sdp3430: " Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 15/33] OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 17:29 ` Aaro Koskinen
2013-02-13 17:29 ` Aaro Koskinen
2013-02-14 6:51 ` Archit Taneja
2013-02-14 6:52 ` Archit Taneja
2013-02-14 6:58 ` Tomi Valkeinen
2013-02-14 6:58 ` Tomi Valkeinen
2013-02-14 7:08 ` Archit Taneja
2013-02-14 7:20 ` Archit Taneja
2013-02-18 7:33 ` Archit Taneja
2013-02-18 7:45 ` Archit Taneja
2013-02-18 8:11 ` Tomi Valkeinen
2013-02-18 8:11 ` Tomi Valkeinen
2013-02-18 8:23 ` Archit Taneja
2013-02-18 8:35 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 17/33] arm: omap: board-rx-51: use acx565akm panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 18/33] OMAPDSS: nec-nl8048 panel: handle gpios ins panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 19/33] arm: omap: board-zoom: use NEC panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 20/33] OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 21/33] OMAPDSS: tpo-td043 panel: handle gpios in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 22/33] arm: omap: board-omap3pandora: use tpo panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 23/33] OMAPDSS: tpo-td043: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 24/33] OMAPDSS: picodlp panel: handle gpio data in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 25/33] arm: omap: dss-common: use picodlp panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 26/33] OMAPDSS: picodlp panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 17:35 ` Aaro Koskinen
2013-02-13 17:35 ` Aaro Koskinen
2013-02-14 6:34 ` Archit Taneja
2013-02-14 6:46 ` Archit Taneja
2013-02-14 12:45 ` Aaro Koskinen
2013-02-14 12:45 ` Aaro Koskinen
2013-02-13 14:22 ` [PATCH 28/33] OMAPDSS: n8x0 panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 29/33] arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC devices Archit Taneja
2013-02-13 14:34 ` [PATCH 29/33] arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC device Archit Taneja
2013-02-13 14:22 ` [PATCH 30/33] OMAPDSS: VENC: remove platform_enable/disable calls Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 31/33] OMAPDSS: remove platform_enable/disable callbacks from omap_dss_device Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 32/33] arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 33/33] OMAPDSS: remove reset_gpio field from omap_dss_device Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 16:46 ` [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers Tony Lindgren
2013-02-13 16:46 ` Tony Lindgren
2013-02-14 7:17 ` Archit Taneja
2013-02-14 7:29 ` Archit Taneja
2013-04-03 12:28 ` Tomi Valkeinen
2013-04-03 12:28 ` Tomi Valkeinen
2013-04-03 15:46 ` Tony Lindgren
2013-04-03 15:46 ` Tony Lindgren
2013-04-15 9:29 ` Tomi Valkeinen
2013-04-15 9:29 ` Tomi Valkeinen
2013-04-15 21:20 ` Tony Lindgren
2013-04-15 21:20 ` Tony Lindgren
2013-04-16 4:20 ` Tomi Valkeinen
2013-04-16 4:20 ` Tomi Valkeinen
2013-04-18 0:34 ` Tony Lindgren
2013-04-18 0:34 ` Tony Lindgren
2013-04-18 3:40 ` Tomi Valkeinen
2013-04-18 3:40 ` Tomi Valkeinen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.