* [PATCH 3/7] OMAPDSS: HDMI: OMAP4: Complete register definitions for DPLL
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri, Archit Taneja
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add missing register definitions for spread spectrum clocking.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 469d436..d1a2315 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -168,6 +168,8 @@
#define PLLCTRL_CFG1 0xC
#define PLLCTRL_CFG2 0x10
#define PLLCTRL_CFG3 0x14
+#define PLLCTRL_SSC_CFG1 0x18
+#define PLLCTRL_SSC_CFG2 0x1C
#define PLLCTRL_CFG4 0x20
/* HDMI PHY */
--
1.8.1.2
^ permalink raw reply related
* [PATCH 4/7] OMAPDSS: HDMI: OMAP4: Complete dumping of DPLL registers
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri, Archit Taneja
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add the spread spectrum clock configuration registers to the DPLL dump.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index ecadd7a..46af726 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -886,6 +886,8 @@ void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
DUMPPLL(PLLCTRL_CFG1);
DUMPPLL(PLLCTRL_CFG2);
DUMPPLL(PLLCTRL_CFG3);
+ DUMPPLL(PLLCTRL_SSC_CFG1);
+ DUMPPLL(PLLCTRL_SSC_CFG2);
DUMPPLL(PLLCTRL_CFG4);
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 5/7] OMAPDSS: HDMI: OMAP4: Rename the HDMI_CORE_CTRL1 register
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri, Archit Taneja
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Rename the register to be aligned with the HDMI_CORE_SYS naming convention.
Also, update the naming of the #defines used for its fields.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 16 ++++++++--------
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 11 ++++++-----
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 46af726..ad5b820 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -527,7 +527,7 @@ static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
static void hdmi_core_powerdown_disable(struct hdmi_ip_data *ip_data)
{
pr_debug("Enter hdmi_core_powerdown_disable\n");
- REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1, 0x0, 0, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_SYS_CTRL1, 0x0, 0, 0);
}
static void hdmi_core_swreset_release(struct hdmi_ip_data *ip_data)
@@ -550,12 +550,12 @@ static void hdmi_core_video_config(struct hdmi_ip_data *ip_data,
void __iomem *core_sys_base = hdmi_core_sys_base(ip_data);
/* sys_ctrl1 default configuration not tunable */
- r = hdmi_read_reg(core_sys_base, HDMI_CORE_CTRL1);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC, 5, 5);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC, 4, 4);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_BSEL_24BITBUS, 2, 2);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_EDGE_RISINGEDGE, 1, 1);
- hdmi_write_reg(core_sys_base, HDMI_CORE_CTRL1, r);
+ r = hdmi_read_reg(core_sys_base, HDMI_CORE_SYS_SYS_CTRL1);
+ r = FLD_MOD(r, HDMI_CORE_SYS_SYS_CTRL1_VEN_FOLLOWVSYNC, 5, 5);
+ r = FLD_MOD(r, HDMI_CORE_SYS_SYS_CTRL1_HEN_FOLLOWHSYNC, 4, 4);
+ r = FLD_MOD(r, HDMI_CORE_SYS_SYS_CTRL1_BSEL_24BITBUS, 2, 2);
+ r = FLD_MOD(r, HDMI_CORE_SYS_SYS_CTRL1_EDGE_RISINGEDGE, 1, 1);
+ hdmi_write_reg(core_sys_base, HDMI_CORE_SYS_SYS_CTRL1, r);
REG_FLD_MOD(core_sys_base,
HDMI_CORE_SYS_VID_ACEN, cfg->ip_bus_width, 7, 6);
@@ -909,7 +909,7 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
DUMPCORE(HDMI_CORE_SYS_DEV_IDH);
DUMPCORE(HDMI_CORE_SYS_DEV_REV);
DUMPCORE(HDMI_CORE_SYS_SRST);
- DUMPCORE(HDMI_CORE_CTRL1);
+ DUMPCORE(HDMI_CORE_SYS_SYS_CTRL1);
DUMPCORE(HDMI_CORE_SYS_SYS_STAT);
DUMPCORE(HDMI_CORE_SYS_DE_DLY);
DUMPCORE(HDMI_CORE_SYS_DE_CTRL);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index d1a2315..149abd8 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -53,7 +53,7 @@
#define HDMI_CORE_SYS_DEV_IDH 0xC
#define HDMI_CORE_SYS_DEV_REV 0x10
#define HDMI_CORE_SYS_SRST 0x14
-#define HDMI_CORE_CTRL1 0x20
+#define HDMI_CORE_SYS_SYS_CTRL1 0x20
#define HDMI_CORE_SYS_SYS_STAT 0x24
#define HDMI_CORE_SYS_DE_DLY 0xC8
#define HDMI_CORE_SYS_DE_CTRL 0xCC
@@ -72,10 +72,11 @@
#define HDMI_CORE_SYS_UMASK1 0x1D4
#define HDMI_CORE_SYS_TMDS_CTRL 0x208
-#define HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC 0x1
-#define HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC 0x1
-#define HDMI_CORE_CTRL1_BSEL_24BITBUS 0x1
-#define HDMI_CORE_CTRL1_EDGE_RISINGEDGE 0x1
+/* value definitions for HDMI_CORE_SYS_SYS_CTRL1 fields */
+#define HDMI_CORE_SYS_SYS_CTRL1_VEN_FOLLOWVSYNC 0x1
+#define HDMI_CORE_SYS_SYS_CTRL1_HEN_FOLLOWHSYNC 0x1
+#define HDMI_CORE_SYS_SYS_CTRL1_BSEL_24BITBUS 0x1
+#define HDMI_CORE_SYS_SYS_CTRL1_EDGE_RISINGEDGE 0x1
/* HDMI DDC E-DID */
#define HDMI_CORE_DDC_ADDR 0x3B4
--
1.8.1.2
^ permalink raw reply related
* [PATCH 6/7] OMAPDSS: HDMI: OMAP4: Complete register definitions for core
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri, Archit Taneja
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add missing register definitions; mainly for colorspace conversion, video
timing and interrupt handling.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 48 ++++++++++++++++++++++++++++++-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 149abd8..b25269c 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -55,6 +55,8 @@
#define HDMI_CORE_SYS_SRST 0x14
#define HDMI_CORE_SYS_SYS_CTRL1 0x20
#define HDMI_CORE_SYS_SYS_STAT 0x24
+#define HDMI_CORE_SYS_SYS_CTRL3 0x28
+#define HDMI_CORE_SYS_DCTL 0x34
#define HDMI_CORE_SYS_DE_DLY 0xC8
#define HDMI_CORE_SYS_DE_CTRL 0xCC
#define HDMI_CORE_SYS_DE_TOP 0xD0
@@ -62,14 +64,58 @@
#define HDMI_CORE_SYS_DE_CNTH 0xDC
#define HDMI_CORE_SYS_DE_LINL 0xE0
#define HDMI_CORE_SYS_DE_LINH_1 0xE4
+#define HDMI_CORE_SYS_HRES_L 0xE8
+#define HDMI_CORE_SYS_HRES_H 0xEC
+#define HDMI_CORE_SYS_VRES_L 0xF0
+#define HDMI_CORE_SYS_VRES_H 0xF4
+#define HDMI_CORE_SYS_IADJUST 0xF8
+#define HDMI_CORE_SYS_POLDETECT 0xFC
+#define HDMI_CORE_SYS_HWIDTH1 0x110
+#define HDMI_CORE_SYS_HWIDTH2 0x114
+#define HDMI_CORE_SYS_VWIDTH 0x11C
+#define HDMI_CORE_SYS_VID_CTRL 0x120
#define HDMI_CORE_SYS_VID_ACEN 0x124
#define HDMI_CORE_SYS_VID_MODE 0x128
+#define HDMI_CORE_SYS_VID_BLANK1 0x12C
+#define HDMI_CORE_SYS_VID_BLANK2 0x130
+#define HDMI_CORE_SYS_VID_BLANK3 0x134
+#define HDMI_CORE_SYS_DC_HEADER 0x138
+#define HDMI_CORE_SYS_VID_DITHER 0x13C
+#define HDMI_CORE_SYS_RGB2XVYCC_CT 0x140
+#define HDMI_CORE_SYS_R2Y_COEFF_LOW 0x144
+#define HDMI_CORE_SYS_R2Y_COEFF_UP 0x148
+#define HDMI_CORE_SYS_G2Y_COEFF_LOW 0x14C
+#define HDMI_CORE_SYS_G2Y_COEFF_UP 0x150
+#define HDMI_CORE_SYS_B2Y_COEFF_LOW 0x154
+#define HDMI_CORE_SYS_B2Y_COEFF_UP 0x158
+#define HDMI_CORE_SYS_R2CB_COEFF_LOW 0x15C
+#define HDMI_CORE_SYS_R2CB_COEFF_UP 0x160
+#define HDMI_CORE_SYS_G2CB_COEFF_LOW 0x164
+#define HDMI_CORE_SYS_G2CB_COEFF_UP 0x168
+#define HDMI_CORE_SYS_B2CB_COEFF_LOW 0x16C
+#define HDMI_CORE_SYS_B2CB_COEFF_UP 0x170
+#define HDMI_CORE_SYS_R2CR_COEFF_LOW 0x174
+#define HDMI_CORE_SYS_R2CR_COEFF_UP 0x178
+#define HDMI_CORE_SYS_G2CR_COEFF_LOW 0x17C
+#define HDMI_CORE_SYS_G2CR_COEFF_UP 0x180
+#define HDMI_CORE_SYS_B2CR_COEFF_LOW 0x184
+#define HDMI_CORE_SYS_B2CR_COEFF_UP 0x188
+#define HDMI_CORE_SYS_RGB_OFFSET_LOW 0x18C
+#define HDMI_CORE_SYS_RGB_OFFSET_UP 0x190
+#define HDMI_CORE_SYS_Y_OFFSET_LOW 0x194
+#define HDMI_CORE_SYS_Y_OFFSET_UP 0x198
+#define HDMI_CORE_SYS_CBCR_OFFSET_LOW 0x19C
+#define HDMI_CORE_SYS_CBCR_OFFSET_UP 0x1A0
#define HDMI_CORE_SYS_INTR_STATE 0x1C0
#define HDMI_CORE_SYS_INTR1 0x1C4
#define HDMI_CORE_SYS_INTR2 0x1C8
#define HDMI_CORE_SYS_INTR3 0x1CC
#define HDMI_CORE_SYS_INTR4 0x1D0
-#define HDMI_CORE_SYS_UMASK1 0x1D4
+#define HDMI_CORE_SYS_INTR_UNMASK1 0x1D4
+#define HDMI_CORE_SYS_INTR_UNMASK2 0x1D8
+#define HDMI_CORE_SYS_INTR_UNMASK3 0x1DC
+#define HDMI_CORE_SYS_INTR_UNMASK4 0x1E0
+#define HDMI_CORE_SYS_INTR_CTRL 0x1E4
#define HDMI_CORE_SYS_TMDS_CTRL 0x208
/* value definitions for HDMI_CORE_SYS_SYS_CTRL1 fields */
--
1.8.1.2
^ permalink raw reply related
* [PATCH 7/7] OMAPDSS: HDMI: OMAP4: Complete dumping of core registers
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri, Archit Taneja
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add missing register entries when dumping the core.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 47 ++++++++++++++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index ad5b820..fd4172b 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -911,6 +911,7 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
DUMPCORE(HDMI_CORE_SYS_SRST);
DUMPCORE(HDMI_CORE_SYS_SYS_CTRL1);
DUMPCORE(HDMI_CORE_SYS_SYS_STAT);
+ DUMPCORE(HDMI_CORE_SYS_SYS_CTRL3);
DUMPCORE(HDMI_CORE_SYS_DE_DLY);
DUMPCORE(HDMI_CORE_SYS_DE_CTRL);
DUMPCORE(HDMI_CORE_SYS_DE_TOP);
@@ -918,14 +919,58 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
DUMPCORE(HDMI_CORE_SYS_DE_CNTH);
DUMPCORE(HDMI_CORE_SYS_DE_LINL);
DUMPCORE(HDMI_CORE_SYS_DE_LINH_1);
+ DUMPCORE(HDMI_CORE_SYS_HRES_L);
+ DUMPCORE(HDMI_CORE_SYS_HRES_H);
+ DUMPCORE(HDMI_CORE_SYS_VRES_L);
+ DUMPCORE(HDMI_CORE_SYS_VRES_H);
+ DUMPCORE(HDMI_CORE_SYS_IADJUST);
+ DUMPCORE(HDMI_CORE_SYS_POLDETECT);
+ DUMPCORE(HDMI_CORE_SYS_HWIDTH1);
+ DUMPCORE(HDMI_CORE_SYS_HWIDTH2);
+ DUMPCORE(HDMI_CORE_SYS_VWIDTH);
+ DUMPCORE(HDMI_CORE_SYS_VID_CTRL);
DUMPCORE(HDMI_CORE_SYS_VID_ACEN);
DUMPCORE(HDMI_CORE_SYS_VID_MODE);
+ DUMPCORE(HDMI_CORE_SYS_VID_BLANK1);
+ DUMPCORE(HDMI_CORE_SYS_VID_BLANK3);
+ DUMPCORE(HDMI_CORE_SYS_VID_BLANK1);
+ DUMPCORE(HDMI_CORE_SYS_DC_HEADER);
+ DUMPCORE(HDMI_CORE_SYS_VID_DITHER);
+ DUMPCORE(HDMI_CORE_SYS_RGB2XVYCC_CT);
+ DUMPCORE(HDMI_CORE_SYS_R2Y_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_R2Y_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_G2Y_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_G2Y_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_B2Y_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_B2Y_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_R2CB_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_R2CB_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_G2CB_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_G2CB_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_B2CB_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_B2CB_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_R2CR_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_R2CR_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_G2CR_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_G2CR_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_B2CR_COEFF_LOW);
+ DUMPCORE(HDMI_CORE_SYS_B2CR_COEFF_UP);
+ DUMPCORE(HDMI_CORE_SYS_RGB_OFFSET_LOW);
+ DUMPCORE(HDMI_CORE_SYS_RGB_OFFSET_UP);
+ DUMPCORE(HDMI_CORE_SYS_Y_OFFSET_LOW);
+ DUMPCORE(HDMI_CORE_SYS_Y_OFFSET_UP);
+ DUMPCORE(HDMI_CORE_SYS_CBCR_OFFSET_LOW);
+ DUMPCORE(HDMI_CORE_SYS_CBCR_OFFSET_UP);
DUMPCORE(HDMI_CORE_SYS_INTR_STATE);
DUMPCORE(HDMI_CORE_SYS_INTR1);
DUMPCORE(HDMI_CORE_SYS_INTR2);
DUMPCORE(HDMI_CORE_SYS_INTR3);
DUMPCORE(HDMI_CORE_SYS_INTR4);
- DUMPCORE(HDMI_CORE_SYS_UMASK1);
+ DUMPCORE(HDMI_CORE_SYS_INTR_UNMASK1);
+ DUMPCORE(HDMI_CORE_SYS_INTR_UNMASK2);
+ DUMPCORE(HDMI_CORE_SYS_INTR_UNMASK3);
+ DUMPCORE(HDMI_CORE_SYS_INTR_UNMASK4);
+ DUMPCORE(HDMI_CORE_SYS_INTR_CTRL);
DUMPCORE(HDMI_CORE_SYS_TMDS_CTRL);
DUMPCORE(HDMI_CORE_DDC_ADDR);
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2] video/matrox/matroxfb_maven: Use module_i2c_driver to register driver
From: Jean Delvare @ 2013-09-13 19:51 UTC (permalink / raw)
To: linux-fbdev
From: Peter Huewe <peterhuewe@gmx.de>
Removing some boilerplate by using module_i2c_driver instead of calling
register and unregister in the otherwise empty init/exit functions.
Also removed a useless comment as suggested by Jean Delvare.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
Looks like this patch got lost so I am resending it.
drivers/video/matrox/matroxfb_maven.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
--- linux-3.12-rc0.orig/drivers/video/matrox/matroxfb_maven.c 2013-09-13 21:48:12.585102831 +0200
+++ linux-3.12-rc0/drivers/video/matrox/matroxfb_maven.c 2013-09-13 21:48:28.843103072 +0200
@@ -1295,19 +1295,7 @@ static struct i2c_driver maven_driver={
.id_table = maven_id,
};
-static int __init matroxfb_maven_init(void)
-{
- return i2c_add_driver(&maven_driver);
-}
-
-static void __exit matroxfb_maven_exit(void)
-{
- i2c_del_driver(&maven_driver);
-}
-
+module_i2c_driver(maven_driver);
MODULE_AUTHOR("(c) 1999-2002 Petr Vandrovec <vandrove@vc.cvut.cz>");
MODULE_DESCRIPTION("Matrox G200/G400 Matrox MGA-TVO driver");
MODULE_LICENSE("GPL");
-module_init(matroxfb_maven_init);
-module_exit(matroxfb_maven_exit);
-/* we do not have __setup() yet */
--
Jean Delvare
^ permalink raw reply
* Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
From: Daniel Stone @ 2013-09-14 21:33 UTC (permalink / raw)
To: Tom Cooksey
Cc: 'Rob Clark', linux-fbdev, Pawel Moll, linux-kernel,
dri-devel, linaro-mm-sig, linux-arm-kernel, linux-media
In-Reply-To: <000101ce9298$8ce44ee0$a6aceca0$@cooksey@arm.com>
Hi,
On Tue, 2013-08-06 at 12:31 +0100, Tom Cooksey wrote:
> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey <tom.cooksey@arm.com>
> > >> wrote:
> > that was part of the reason to punt this problem to userspace ;-)
> >
> > In practice, the kernel drivers doesn't usually know too much about
> > the dimensions/format/etc.. that is really userspace level knowledge.
> > There are a few exceptions when the kernel needs to know how to setup
> > GTT/etc for tiled buffers, but normally this sort of information is up
> > at the next level up (userspace, and drm_framebuffer in case of
> > scanout). Userspace media frameworks like GStreamer already have a
> > concept of format/caps negotiation. For non-display<->gpu sharing, I
> > think this is probably where this sort of constraint negotiation
> > should be handled.
Egads. GStreamer's caps negotiation is already close to unbounded time;
seems like most of the optimisation work that goes into it these days is
all about _reducing_ the complexity of caps negotiation!
> I agree that user-space will know which devices will access the buffer
> and thus can figure out at least a common pixel format.
Hm, are you sure about that? The answer is yes for 'userspace' as a
broad handwave, but not necessarily for individual processes. Take, for
instance, media decode through GStreamer, being displayed by Wayland
using a KMS plane/overlay/sprite/cursor/etc. The media player knows
that the buffers are coming from the decode engine, and Wayland knows
that the buffers are going to a KMS plane, but neither of them knows the
full combination of the two.
Though this kinda feeds into an idea I've been kicking around for a
while, which is an 'optimal hint' mechanism in the Wayland protocol. So
for our hypothetical dmabuf-using protocol, we'd start off with buffers
which satisfied all the constraints of our media decode engine, but
perhaps just the GPU rather than display controller. At this point,
we'd note that we could place the video in a plane if only the buffers
were better-allocated, and send an event to the client letting it know
how to tweak its buffer allocation for more optimal display.
But ...
> Though I'm not
> so sure userspace can figure out more low-level details like alignment
> and placement in physical memory, etc.
>
> Anyway, assuming user-space can figure out how a buffer should be
> stored in memory, how does it indicate this to a kernel driver and
> actually allocate it? Which ioctl on which device does user-space
> call, with what parameters? Are you suggesting using something like
> ION which exposes the low-level details of how buffers are laid out in
> physical memory to userspace? If not, what?
... this is still rather unresolved. ;)
Cheers,
Daniel
>
> Cheers,
>
> Tom
>
>
>
>
>
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
^ permalink raw reply
* Re: [PATCH 0/7] omapdss: HDMI: Fix register definitions and reg dump functions
From: Tomi Valkeinen @ 2013-09-16 6:11 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
On 13/09/13 13:29, Archit Taneja wrote:
> These patches complete the OMAP4 HDMI register definitions for HDMI submodules
> and make sure all the corresponding regdump functions dump all the registers.
>
> Ricardo Neri (7):
> OMAPDSS: HDMI: OMAP4: Complete register definitions for wrapper
> OMAPDSS: HDMI: OMAP4: Complete dumping of wrapper registers
> OMAPDSS: HDMI: OMAP4: Complete register definitions for DPLL
> OMAPDSS: HDMI: OMAP4: Complete dumping of DPLL registers
> OMAPDSS: HDMI: OMAP4: Rename the HDMI_CORE_CTRL1 register
> OMAPDSS: HDMI: OMAP4: Complete register definitions for core
> OMAPDSS: HDMI: OMAP4: Complete dumping of core registers
>
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 70 ++++++++++++++++++++++++++-----
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 65 ++++++++++++++++++++++++----
> 2 files changed, 118 insertions(+), 17 deletions(-)
>
These look fine to me, queuing for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: au1100fb: Remove casting the return value which is a void pointer
From: Tomi Valkeinen @ 2013-09-16 9:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <005c01cead20$50fe87e0$f2fb97a0$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On 09/09/13 08:49, Jingoo Han wrote:
> Casting the return value which is a void pointer is redundant.
> The conversion from void pointer to any other pointer type is
> guaranteed by the C programming language.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/video/au1100fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/au1100fb.c b/drivers/video/au1100fb.c
> index a54ccdc..248abd5 100644
> --- a/drivers/video/au1100fb.c
> +++ b/drivers/video/au1100fb.c
> @@ -588,7 +588,7 @@ int au1100fb_drv_remove(struct platform_device *dev)
> if (!dev)
> return -ENODEV;
>
> - fbdev = (struct au1100fb_device *) platform_get_drvdata(dev);
> + fbdev = platform_get_drvdata(dev);
>
> #if !defined(CONFIG_FRAMEBUFFER_CONSOLE) && defined(CONFIG_LOGO)
> au1100fb_fb_blank(VESA_POWERDOWN, &fbdev->info);
>
Thanks, applied for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video/ps3fb: Fix section mismatch warning
From: Tomi Valkeinen @ 2013-09-16 9:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1369141302.3652.14.camel@clam>
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
On 21/05/13 16:01, Geoff Levand wrote:
> Remove the __initdata attribute from the ps3fb_fix variable. This is in
> follow up to the removal of the __devinit attribute on the ps3fb_probe()
> routine in commit 48c68c4f1b542444f175a9e136febcecf3e704d8 (Drivers:
> video: remove __dev* attributes).
>
> Fixes build warnings like these:
>
> WARNING: vmlinux.o Section mismatch in reference from the function .ps3fb_probe() to the variable .init.data:ps3fb_fix
> The function .ps3fb_probe() references the variable __initdata ps3fb_fix.
> This is often because .ps3fb_probe lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> drivers/video/ps3fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> index a397271d..4819cdf 100644
> --- a/drivers/video/ps3fb.c
> +++ b/drivers/video/ps3fb.c
> @@ -952,7 +952,7 @@ static struct fb_ops ps3fb_ops = {
> .fb_compat_ioctl = ps3fb_ioctl
> };
>
> -static struct fb_fix_screeninfo ps3fb_fix __initdata = {
> +static struct fb_fix_screeninfo ps3fb_fix = {
> .id = DEVICE_NAME,
> .type = FB_TYPE_PACKED_PIXELS,
> .visual = FB_VISUAL_TRUECOLOR,
>
Thanks, applied for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] aty128fb: Use pci_dev pm_cap
From: Tomi Valkeinen @ 2013-09-16 9:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1378935306-16814-1-git-send-email-jdmason@kudzu.us>
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On 12/09/13 00:35, Jon Mason wrote:
> Use the already existing pm_cap variable in struct pci_dev for
> determining the power management offset. This saves the driver from
> having to keep track of an extra variable.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/aty/aty128fb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Thanks. Applied this, and the second patch, for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video/ps3fb: Fix section mismatch warning
From: Geert Uytterhoeven @ 2013-09-16 9:28 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1369141302.3652.14.camel@clam>
On Mon, Sep 16, 2013 at 11:20 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 21/05/13 16:01, Geoff Levand wrote:
>> Remove the __initdata attribute from the ps3fb_fix variable. This is in
>> follow up to the removal of the __devinit attribute on the ps3fb_probe()
>> routine in commit 48c68c4f1b542444f175a9e136febcecf3e704d8 (Drivers:
>> video: remove __dev* attributes).
>>
>> Fixes build warnings like these:
>>
>> WARNING: vmlinux.o Section mismatch in reference from the function .ps3fb_probe() to the variable .init.data:ps3fb_fix
>> The function .ps3fb_probe() references the variable __initdata ps3fb_fix.
>> This is often because .ps3fb_probe lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
>>
>> Signed-off-by: Geoff Levand <geoff@infradead.org>
>
> Thanks, applied for 3.13.
Too late. It already got in last week through Cell and PS3 supporter BenH ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 00/21] video: remove unnecessary pci_set_drvdata()
From: Tomi Valkeinen @ 2013-09-16 9:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <001a01ceaf84$32c52d90$984f88b0$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]
On 12/09/13 09:49, Jingoo Han wrote:
> Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound),
> the driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> ---
> drivers/video/arkfb.c | 1 -
> drivers/video/carminefb.c | 1 -
> drivers/video/cirrusfb.c | 1 -
> drivers/video/cyber2000fb.c | 5 -----
> drivers/video/geode/gx1fb_core.c | 1 -
> drivers/video/geode/gxfb_core.c | 1 -
> drivers/video/geode/lxfb_core.c | 1 -
> drivers/video/i740fb.c | 1 -
> drivers/video/i810/i810_main.c | 1 -
> drivers/video/intelfb/intelfbdrv.c | 2 --
> drivers/video/kyro/fbdev.c | 1 -
> drivers/video/mb862xx/mb862xxfbdrv.c | 1 -
> drivers/video/neofb.c | 6 ------
> drivers/video/pm2fb.c | 1 -
> drivers/video/pm3fb.c | 1 -
> drivers/video/s3fb.c | 1 -
> drivers/video/savage/savagefb_driver.c | 6 ------
> drivers/video/sis/sis_main.c | 4 ----
> drivers/video/tdfxfb.c | 1 -
> drivers/video/tridentfb.c | 1 -
> drivers/video/vt8623fb.c | 1 -
> 21 files changed, 39 deletions(-)
>
Thanks, applying for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] video: xilinxfb: Simplify error path
From: Tomi Valkeinen @ 2013-09-16 9:51 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, monstr, Jean-Christophe Plagniol-Villard,
linux-fbdev
In-Reply-To: <940bbdfc5c67282ab461b9c82b55f18fc34c959d.1378965270.git.michal.simek@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 713 bytes --]
On 12/09/13 08:54, Michal Simek wrote:
> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
> /* Turn off the display */
> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>
> - /* Release the resources, as allocated based on interface */
> - if (drvdata->flags & BUS_ACCESS_FLAG)
> - devm_iounmap(dev, drvdata->regs);
> #ifdef CONFIG_PPC_DCR
> - else
> + /* Release the resources, as allocated based on interface */
> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
> #endif
I might be mistaken, and it's not strictly part of this series, but
shouldn't dcr_unmap be called somewhere else also, if the probe fails?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video/ps3fb: Fix section mismatch warning
From: Tomi Valkeinen @ 2013-09-16 9:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1369141302.3652.14.camel@clam>
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
On 16/09/13 12:28, Geert Uytterhoeven wrote:
> On Mon, Sep 16, 2013 at 11:20 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 21/05/13 16:01, Geoff Levand wrote:
>>> Remove the __initdata attribute from the ps3fb_fix variable. This is in
>>> follow up to the removal of the __devinit attribute on the ps3fb_probe()
>>> routine in commit 48c68c4f1b542444f175a9e136febcecf3e704d8 (Drivers:
>>> video: remove __dev* attributes).
>>>
>>> Fixes build warnings like these:
>>>
>>> WARNING: vmlinux.o Section mismatch in reference from the function .ps3fb_probe() to the variable .init.data:ps3fb_fix
>>> The function .ps3fb_probe() references the variable __initdata ps3fb_fix.
>>> This is often because .ps3fb_probe lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
>>>
>>> Signed-off-by: Geoff Levand <geoff@infradead.org>
>>
>> Thanks, applied for 3.13.
>
> Too late. It already got in last week through Cell and PS3 supporter BenH ;-)
Ok, thanks for informing. Maybe I'll be faster next time, shouldn't be
difficult to achieve ;).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] video: xilinxfb: Simplify error path
From: Michal Simek @ 2013-09-16 10:33 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Michal Simek, linux-kernel, Jean-Christophe Plagniol-Villard,
linux-fbdev
In-Reply-To: <5236D4BD.9050707@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]
On 09/16/2013 11:51 AM, Tomi Valkeinen wrote:
> On 12/09/13 08:54, Michal Simek wrote:
>
>> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
>> /* Turn off the display */
>> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>>
>> - /* Release the resources, as allocated based on interface */
>> - if (drvdata->flags & BUS_ACCESS_FLAG)
>> - devm_iounmap(dev, drvdata->regs);
>> #ifdef CONFIG_PPC_DCR
>> - else
>> + /* Release the resources, as allocated based on interface */
>> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
>> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
>> #endif
>
> I might be mistaken, and it's not strictly part of this series, but
> shouldn't dcr_unmap be called somewhere else also, if the probe fails?
yes. It should.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] video: xilinxfb: Simplify error path
From: Tomi Valkeinen @ 2013-09-16 10:34 UTC (permalink / raw)
To: monstr
Cc: Michal Simek, linux-kernel, Jean-Christophe Plagniol-Villard,
linux-fbdev
In-Reply-To: <5236DE60.3020901@monstr.eu>
[-- Attachment #1: Type: text/plain, Size: 985 bytes --]
On 16/09/13 13:33, Michal Simek wrote:
> On 09/16/2013 11:51 AM, Tomi Valkeinen wrote:
>> On 12/09/13 08:54, Michal Simek wrote:
>>
>>> @@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
>>> /* Turn off the display */
>>> xilinx_fb_out32(drvdata, REG_CTRL, 0);
>>>
>>> - /* Release the resources, as allocated based on interface */
>>> - if (drvdata->flags & BUS_ACCESS_FLAG)
>>> - devm_iounmap(dev, drvdata->regs);
>>> #ifdef CONFIG_PPC_DCR
>>> - else
>>> + /* Release the resources, as allocated based on interface */
>>> + if (!(drvdata->flags & BUS_ACCESS_FLAG))
>>> dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
>>> #endif
>>
>> I might be mistaken, and it's not strictly part of this series, but
>> shouldn't dcr_unmap be called somewhere else also, if the probe fails?
>
> yes. It should.
Do you want me to apply these patches as they are, or do you want to
improve the series to include the dcr_unmap fix?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] video/matrox/matroxfb_maven: Use module_i2c_driver to register driver
From: Tomi Valkeinen @ 2013-09-16 10:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20130913215150.16089f46@endymion.delvare>
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
On 13/09/13 22:51, Jean Delvare wrote:
> From: Peter Huewe <peterhuewe@gmx.de>
>
> Removing some boilerplate by using module_i2c_driver instead of calling
> register and unregister in the otherwise empty init/exit functions.
> Also removed a useless comment as suggested by Jean Delvare.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> Looks like this patch got lost so I am resending it.
>
Thanks, applying for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH v3 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-16 17:18 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic DT bindings for the PL11x CLCD controllers
and make their fbdev driver use them (initially only TFT panels
are supported).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
Changes since v2:
- replaced video-ram phandle with arm,pl11x,framebuffer-base
- replaced panel-* properties with arm,pl11x,panel-data-pads
- replaced max-framebuffer-size with max-memory-bandwidth
- modified clcdfb_of_init_tft_panel() to use the pads
data and take differences between PL110 and PL110 into
account
Changes since v1:
- minor code cleanups as suggested by Sylwester Nawrocki
.../devicetree/bindings/video/arm,pl11x.txt | 145 +++++++++++
drivers/video/Kconfig | 1 +
drivers/video/amba-clcd.c | 268 +++++++++++++++++++++
3 files changed, 414 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 0000000..418ee06
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,145 @@
+* ARM PrimeCell Color LCD Controller PL110/PL111
+
+See also Documentation/devicetree/bindings/arm/primecell.txt
+
+Required properties:
+
+- compatible: must be one of:
+ "arm,pl110", "arm,primecell"
+ "arm,pl111", "arm,primecell"
+- reg: base address and size of the control registers block
+- interrupts: either a single interrupt specifier representing the
+ combined interrupt output (CLCDINTR) or an array of
+ four interrupt specifiers for CLCDMBEINTR,
+ CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR; in the
+ latter case interrupt names must be specified
+ (see below)
+- interrupt-names: when four interrupts are specified, their names:
+ "mbe", "vcomp", "lnbu", "fuf"
+ must be specified in order respective to the
+ interrupt specifiers
+- clocks: contains phandle and clock specifier pairs for the entries
+ in the clock-names property. See
+ Documentation/devicetree/binding/clock/clock-bindings.txt
+- clocks names: should contain "clcdclk" and "apb_pclk"
+- arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
+ a function of one of the CLD pads,
+ starting from 0 up to 23; each pad can
+ be described by one of the following values:
+ - 0: reserved (not connected)
+ - 0x100-0x107: color upper STN panel data 0 to 7
+ - 0x110-0x117: color lower STN panel data 0 to 7
+ - 0x200-0x207: mono upper STN panel data 0 to 7
+ - 0x210-0x217: mono lower STN panel data 0 to 7
+ - 0x300-0x307: red component bit 0 to 7 of TFT panel data
+ - 0x310-0x317: green component bit 0 to 7 of TFT panel data
+ - 0x320-0x327: blue component bit 0 to 7 of TFT panel data
+ - 0x330: intensity bit of TFT panel data
+ Example sets of values for standard
+ panel interfaces:
+ - PL110 single colour STN panel:
+ <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual colour STN panel:
+ <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
+ <0x117 0x116 0x115 0x114 0x113 0x112 0x111 0x110>,
+ <0 0 0 0 0 0 0 0>;
+ - PL110 single mono 4-bit STN panel:
+ <0x203 0x202 0x201 0x200>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual mono 4-bit STN panel:
+ <0x203 0x202 0x201 0x200>, <0 0 0 0>,
+ <0x213 0x212 0x211 0x210>,
+ <0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 single mono 8-bit STN panel:
+ <0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual mono 8-bit STN panel:
+ <0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
+ <0x217 0x216 0x215 0x214 0x213 0x212 0x211 0x210>,
+ <0 0 0 0 0 0 0 0>;
+ - PL110 TFT (1:)5:5:5 panel:
+ <0x330 0x300 0x301 0x302 0x303 0x304>,
+ <0x330 0x310 0x311 0x312 0x313 0x314>,
+ <0x330 0x320 0x321 0x322 0x323 0x324>,
+ <0 0 0 0 0 0>
+ - PL110 and PL111 TFT RGB 888 panel:
+ <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ - PL111 single colour STN panel:
+ <0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual colour STN panel:
+ <0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
+ <0x110 0x111 0x112 0x113 0x114 0x115 0x116 0x117>,
+ <0 0 0 0 0 0 0 0>;
+ - PL111 single mono 4-bit STN panel:
+ <0x200 0x201 0x202 0x203>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual mono 4-bit STN panel:
+ <0x200 0x201 0x202 0x203>, <0 0 0 0>,
+ <0x210 0x211 0x212 0x213>,
+ <0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 single mono 8-bit STN panel:
+ <0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual mono 8-bit STN panel:
+ <0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
+ <0x210 0x211 0x212 0x213 0x214 0x215 0x216 0x217>,
+ <0 0 0 0 0 0 0 0>;
+ - PL111 TFT 4:4:4 panel:
+ <0 0 0 0>, <0x300 0x301 0x302 0x303>,
+ <0 0 0 0>, <0x310 0x311 0x312 0x313>,
+ <0 0 0 0>, <0x320 0x321 0x322 0x323>;
+ - PL111 TFT 5:6:5 panel:
+ <0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
+ <0 0>, <0x310 0x311 0x312 0x313 0x314 0x315>,
+ <0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
+ - PL111 TFT (1):5:5:5 panel:
+ <0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
+ <0 0>, <0x330 0x310 0x311 0x312 0x313 0x314>,
+ <0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
+
+Optional properties:
+
+- arm,pl11x,framebuffer-base: a pair of two values, address and size,
+ defining the framebuffer to be used;
+ to be used only if it is *not*
+ part of normal memory, as described
+ in /memory node
+- max-memory-bandwidth: maximum bandwidth in bytes per second that the
+ cell's memory interface can handle
+- display-timings: standard display timings sub-node, defining possible
+ video modes of a connected panel; for details see
+ Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+ clcd@1f0000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x1f0000 0x1000>;
+ interrupts = <14>;
+ clocks = <&v2m_oscclk1>, <&smbclk>;
+ clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* bps, 640x480@60 16bpp */
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4cf1e1d..375bf63 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -316,6 +316,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS if OF
help
This framebuffer device driver is for the ARM PrimeCell PL110
Colour LCD controller. ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..03420d1 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
#include <linux/amba/clcd.h>
#include <linux/clk.h>
#include <linux/hardirq.h>
+#include <linux/dma-mapping.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
#include <asm/sizes.h>
@@ -542,6 +547,266 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#ifdef CONFIG_OF
+
+#define CLCD_PADS_NUM 24
+
+#define CLCD_PAD_BIT(pad) ((pad) & 0xf)
+#define CLCD_PAD_TYPE(pad) (((pad) >> 8) & 0xf)
+
+#define CLCD_PAD_IS_TFT(pad) (CLCD_PAD_TYPE(pad) == 0x3)
+
+#define CLCD_PAD_RGB(pad) (((pad) >> 4) & 0xf)
+#define CLCD_PAD_R 0x0
+#define CLCD_PAD_G 0x1
+#define CLCD_PAD_B 0x2
+
+static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 *pads)
+{
+ static struct {
+ unsigned int part;
+ int r0, g0, b0;
+ u32 caps;
+ } panels[] = {
+ { 0x110, 1, 7, 13, CLCD_CAP_5551 },
+ { 0x110, 0, 8, 16, CLCD_CAP_888 },
+ { 0x111, 4, 14, 20, CLCD_CAP_444 },
+ { 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
+ { 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
+ CLCD_CAP_565 },
+ { 0x111, 0, 8, 16, CLCD_CAP_444 | CLCD_CAP_5551 |
+ CLCD_CAP_565 | CLCD_CAP_888 },
+ };
+ int r = 0, g = 0, b = 0;
+ int r0 = -1, g0 = -1, b0 = -1;
+ int i;
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+ /* TFT display, vert. comp. interrupt at the start of the back porch */
+ fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+
+ fb->panel->caps = 0;
+
+ /*
+ * Find indices of the first component bits and make sure they
+ * are in correct order
+ */
+ for (i = 0; i < CLCD_PADS_NUM; i++) {
+ int bit;
+
+ if (!pads[i])
+ continue;
+ switch (CLCD_PAD_RGB(pads[i])) {
+ case CLCD_PAD_R:
+ r0 = r ? r0 : i;
+ bit = r++;
+ break;
+ case CLCD_PAD_G:
+ g0 = g ? g0 : i;
+ bit = g++;
+ break;
+ case CLCD_PAD_B:
+ b0 = b ? b0 : i;
+ bit = b++;
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (bit != CLCD_PAD_BIT(pads[i]) || !CLCD_PAD_IS_TFT(pads[i]))
+ return -EINVAL;
+ }
+
+ /* Match the setup with known variants */
+ for (i = 0; i < ARRAY_SIZE(panels) && !fb->panel->caps; i++) {
+ if (amba_part(fb->dev) != panels[i].part)
+ continue;
+ if (g0 != panels[i].g0)
+ continue;
+ if (r0 == panels[i].r0 && b0 == panels[i].b0)
+ fb->panel->caps = panels[i].caps & CLCD_CAP_RGB;
+ if (r0 == panels[i].b0 && b0 == panels[i].r0)
+ fb->panel->caps = panels[i].caps & CLCD_CAP_BGR;
+ }
+
+ return fb->panel->caps ? 0 : -EINVAL;
+}
+
+static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
+{
+ return snprintf(buf, size, "%ux%u@%u", mode->xres, mode->yres,
+ mode->refresh);
+}
+
+static int clcdfb_of_init_display(struct clcd_fb *fb)
+{
+ struct device_node *node = fb->dev->dev.of_node;
+ int err, len;
+ char *mode_name;
+ u32 max_bandwidth;
+ u32 pads[CLCD_PADS_NUM];
+ int i;
+
+ fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
+ if (!fb->panel)
+ return -ENOMEM;
+
+ err = of_get_fb_videomode(node, &fb->panel->mode, OF_USE_NATIVE_MODE);
+ if (err)
+ return err;
+
+ len = clcdfb_snprintf_mode(NULL, 0, &fb->panel->mode);
+ mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
+ clcdfb_snprintf_mode(mode_name, len + 1, &fb->panel->mode);
+ fb->panel->mode.name = mode_name;
+
+ err = of_property_read_u32(node, "max-memory-bandwidth",
+ &max_bandwidth);
+ if (!err)
+ fb->panel->bpp = 8 * max_bandwidth / (fb->panel->mode.xres *
+ fb->panel->mode.yres * fb->panel->mode.refresh);
+ else
+ fb->panel->bpp = 32;
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ fb->panel->cntl |= CNTL_BEBO;
+#endif
+ fb->panel->width = -1;
+ fb->panel->height = -1;
+
+ err = of_property_read_u32_array(node, "arm,pl11x,panel-data-pads",
+ pads, ARRAY_SIZE(pads));
+ if (err)
+ return err;
+
+ /* Find first connected pad - its type determines the panel */
+ for (i = 0; i < CLCD_PADS_NUM; i++)
+ if (pads[i] && CLCD_PAD_IS_TFT(pads[i]))
+ return clcdfb_of_init_tft_panel(fb, pads);
+
+ return -EINVAL;
+}
+
+static int clcdfb_of_vram_setup(struct clcd_fb *fb)
+{
+ int err;
+ u32 values[2];
+ phys_addr_t phys_base;
+ size_t size;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ err = of_property_read_u32_array(fb->dev->dev.of_node,
+ "arm,pl11x,framebuffer-base",
+ values, ARRAY_SIZE(values));
+ if (err)
+ return err;
+
+ phys_base = values[0];
+ size = values[1];
+
+ fb->fb.screen_base = ioremap(phys_base, size);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = phys_base;
+ fb->fb.fix.smem_len = size;
+
+ return 0;
+}
+
+static int clcdfb_of_vram_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ unsigned long off, user_size, kernel_size;
+
+ off = vma->vm_pgoff << PAGE_SHIFT;
+ user_size = vma->vm_end - vma->vm_start;
+ kernel_size = fb->fb.fix.smem_len;
+
+ if (off >= kernel_size || user_size > (kernel_size - off))
+ return -ENXIO;
+
+ return remap_pfn_range(vma, vma->vm_start,
+ __phys_to_pfn(fb->fb.fix.smem_start) + vma->vm_pgoff,
+ user_size,
+ pgprot_writecombine(vma->vm_page_prot));
+}
+
+static void clcdfb_of_vram_remove(struct clcd_fb *fb)
+{
+ iounmap(fb->fb.screen_base);
+}
+
+static int clcdfb_of_dma_setup(struct clcd_fb *fb)
+{
+ unsigned long framesize;
+ dma_addr_t dma;
+ int err;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ framesize = fb->panel->mode.xres * fb->panel->mode.yres *
+ fb->panel->bpp / 8;
+ fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev, framesize,
+ &dma, GFP_KERNEL);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = dma;
+ fb->fb.fix.smem_len = framesize;
+
+ return 0;
+}
+
+static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ return dma_mmap_writecombine(&fb->dev->dev, vma, fb->fb.screen_base,
+ fb->fb.fix.smem_start, fb->fb.fix.smem_len);
+}
+
+static void clcdfb_of_dma_remove(struct clcd_fb *fb)
+{
+ dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+ fb->fb.screen_base, fb->fb.fix.smem_start);
+}
+
+static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
+{
+ struct clcd_board *board = devm_kzalloc(&dev->dev, sizeof(*board),
+ GFP_KERNEL);
+ struct device_node *node = dev->dev.of_node;
+
+ if (!board)
+ return NULL;
+
+ board->name = of_node_full_name(node);
+ board->caps = CLCD_CAP_ALL;
+ board->check = clcdfb_check;
+ board->decode = clcdfb_decode;
+ if (of_find_property(node, "arm,pl11x,framebuffer-base", NULL)) {
+ board->setup = clcdfb_of_vram_setup;
+ board->mmap = clcdfb_of_vram_mmap;
+ board->remove = clcdfb_of_vram_remove;
+ } else {
+ board->setup = clcdfb_of_dma_setup;
+ board->mmap = clcdfb_of_dma_mmap;
+ board->remove = clcdfb_of_dma_remove;
+ }
+
+ return board;
+}
+#else
+static struct clcd_board *clcdfb_of_get_board(struct amba_dev *dev)
+{
+ return NULL;
+}
+#endif
+
static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
{
struct clcd_board *board = dev->dev.platform_data;
@@ -549,6 +814,9 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
int ret;
if (!board)
+ board = clcdfb_of_get_board(dev);
+
+ if (!board)
return -EINVAL;
ret = amba_request_regions(dev, NULL);
--
1.8.1.2
^ permalink raw reply related
* [PATCH v3 2/2] ARM: vexpress: Add CLCD Device Tree properties
From: Pawel Moll @ 2013-09-16 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379351934-25415-1-git-send-email-pawel.moll@arm.com>
... for V2M-P1 motherboard CLCD (limited to 640x480 16bpp and using
dedicated video RAM bank) and for V2P-CA9 (up to 1024x768 16bpp).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 22 +++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2m.dtsi | 22 +++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 19 +++++++++++++++++++
3 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..8226149 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -233,6 +233,26 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -282,7 +302,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
index f142036..4befe1c 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -232,6 +232,26 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ arm,pl11x,framebuffer-base = <0x4c000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -281,7 +301,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
index 62d9b22..5eb68b8 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -73,6 +73,25 @@
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
+ display-timings {
+ native-mode = <&clcd_timing0>;
+ clcd_timing0: xga {
+ clock-frequency = <63500127>;
+ hactive = <1024>;
+ hback-porch = <152>;
+ hfront-porch = <48>;
+ hsync-len = <104>;
+ vactive = <768>;
+ vback-porch = <23>;
+ vfront-porch = <3>;
+ vsync-len = <4>;
+ };
+ };
};
memory-controller@100e0000 {
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v3 1/2] video: ARM CLCD: Add DT support
From: Stephen Warren @ 2013-09-16 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379351934-25415-1-git-send-email-pawel.moll@arm.com>
On 09/16/2013 11:18 AM, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD controllers
> and make their fbdev driver use them (initially only TFT panels
> are supported).
> diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> +- interrupts: either a single interrupt specifier representing the
> + combined interrupt output (CLCDINTR) or an array of
> + four interrupt specifiers for CLCDMBEINTR,
> + CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR; in the
> + latter case interrupt names must be specified
> + (see below)
> +- interrupt-names: when four interrupts are specified, their names:
> + "mbe", "vcomp", "lnbu", "fuf"
> + must be specified in order respective to the
> + interrupt specifiers
I think the binding should either always use names as the key, or use
indices in interrupts as the key. Hence, I'd word that more like:
- interrupt-names: either the single entry "combined" representing a
combined interrupt output (CLCDINTR), or the
four entries "mbe", "vcomp", "lnbu", "fuf"
representing the individual CLCDMBEINTR,
CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR
interrupts.
- interrupts: contains an interrupt specifier for each entry in
interrupt-names.
> +- arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
> + a function of one of the CLD pads,
> + starting from 0 up to 23; each pad can
> + be described by one of the following values:
> + - 0: reserved (not connected)
> + - 0x100-0x107: color upper STN panel data 0 to 7
...
I assume those are the raw values that go into the HW?
> + Example sets of values for standard
> + panel interfaces:
> + - PL110 single colour STN panel:
> + <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
> + <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
The indentation of the introductory text seems a little odd. Do we
really need so many examples?
> +Optional properties:
> +
> +- arm,pl11x,framebuffer-base: a pair of two values, address and size,
> + defining the framebuffer to be used;
> + to be used only if it is *not*
> + part of normal memory, as described
> + in /memory node
If the framebuffer is part of /memory, what happens then? Is the address
not fixed (so the HW isn't yet set up) and hence a driver should
allocate it?
^ permalink raw reply
* [PATCH 00/19] video: use dev_get_platdata()
From: Jingoo Han @ 2013-09-17 4:53 UTC (permalink / raw)
To: linux-fbdev
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
---
drivers/video/amba-clcd.c | 2 +-
drivers/video/atmel_lcdfb.c | 4 ++--
drivers/video/da8xx-fb.c | 4 ++--
drivers/video/ep93xx-fb.c | 2 +-
drivers/video/imxfb.c | 6 +++---
drivers/video/mbx/mbxfb.c | 2 +-
drivers/video/mx3fb.c | 4 ++--
drivers/video/nuc900fb.c | 6 +++---
drivers/video/omap/hwa742.c | 2 +-
drivers/video/omap/omapfb_main.c | 4 ++--
drivers/video/pxa168fb.c | 6 +++---
drivers/video/pxafb.c | 16 ++++++++--------
drivers/video/s1d13xxxfb.c | 12 ++++++------
drivers/video/s3c-fb.c | 2 +-
drivers/video/s3c2410fb.c | 6 +++---
drivers/video/sa1100fb.c | 4 ++--
drivers/video/sh_mobile_hdmi.c | 6 +++---
drivers/video/simplefb.c | 4 ++--
drivers/video/tmiofb.c | 10 +++++-----
drivers/video/w100fb.c | 2 +-
20 files changed, 52 insertions(+), 52 deletions(-)
^ permalink raw reply
* [PATCH 02/19] video: mx3fb: use dev_get_platdata()
From: Jingoo Han @ 2013-09-17 4:57 UTC (permalink / raw)
To: linux-fbdev
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/mx3fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index cfdb380..804f874 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -1354,7 +1354,7 @@ static struct fb_info *mx3fb_init_fbinfo(struct device *dev, struct fb_ops *ops)
static int init_fb_chan(struct mx3fb_data *mx3fb, struct idmac_channel *ichan)
{
struct device *dev = mx3fb->dev;
- struct mx3fb_platform_data *mx3fb_pdata = dev->platform_data;
+ struct mx3fb_platform_data *mx3fb_pdata = dev_get_platdata(dev);
const char *name = mx3fb_pdata->name;
unsigned int irq;
struct fb_info *fbi;
@@ -1462,7 +1462,7 @@ static bool chan_filter(struct dma_chan *chan, void *arg)
return false;
dev = rq->mx3fb->dev;
- mx3fb_pdata = dev->platform_data;
+ mx3fb_pdata = dev_get_platdata(dev);
return rq->id = chan->chan_id &&
mx3fb_pdata->dma_dev = chan->device->dev;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/19] video: nuc900fb: use dev_get_platdata()
From: Jingoo Han @ 2013-09-17 4:58 UTC (permalink / raw)
To: linux-fbdev
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/nuc900fb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index 796e511..ec32f67 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -91,7 +91,7 @@ static int nuc900fb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct nuc900fb_info *fbi = info->par;
- struct nuc900fb_mach_info *mach_info = fbi->dev->platform_data;
+ struct nuc900fb_mach_info *mach_info = dev_get_platdata(fbi->dev);
struct nuc900fb_display *display = NULL;
struct nuc900fb_display *default_display = mach_info->displays +
mach_info->default_display;
@@ -358,7 +358,7 @@ static inline void modify_gpio(void __iomem *reg,
static int nuc900fb_init_registers(struct fb_info *info)
{
struct nuc900fb_info *fbi = info->par;
- struct nuc900fb_mach_info *mach_info = fbi->dev->platform_data;
+ struct nuc900fb_mach_info *mach_info = dev_get_platdata(fbi->dev);
void __iomem *regs = fbi->io;
/*reset the display engine*/
@@ -512,7 +512,7 @@ static int nuc900fb_probe(struct platform_device *pdev)
int size;
dev_dbg(&pdev->dev, "devinit\n");
- mach_info = pdev->dev.platform_data;
+ mach_info = dev_get_platdata(&pdev->dev);
if (mach_info = NULL) {
dev_err(&pdev->dev,
"no platform data for lcd, cannot attach\n");
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/19] video: omapfb: use dev_get_platdata()
From: Jingoo Han @ 2013-09-17 4:58 UTC (permalink / raw)
To: linux-fbdev
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/omap/hwa742.c | 2 +-
drivers/video/omap/omapfb_main.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c
index f349ee6..a4ee65b 100644
--- a/drivers/video/omap/hwa742.c
+++ b/drivers/video/omap/hwa742.c
@@ -947,7 +947,7 @@ static int hwa742_init(struct omapfb_device *fbdev, int ext_mode,
hwa742.extif = fbdev->ext_if;
hwa742.int_ctrl = fbdev->int_ctrl;
- omapfb_conf = fbdev->dev->platform_data;
+ omapfb_conf = dev_get_platdata(fbdev->dev);
hwa742.sys_ck = clk_get(NULL, "hwa_sys_ck");
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index d40612c..e4fc6d9 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -1602,7 +1602,7 @@ static int omapfb_find_ctrl(struct omapfb_device *fbdev)
char name[17];
int i;
- conf = fbdev->dev->platform_data;
+ conf = dev_get_platdata(fbdev->dev);
fbdev->ctrl = NULL;
@@ -1674,7 +1674,7 @@ static int omapfb_do_probe(struct platform_device *pdev,
goto cleanup;
}
- if (pdev->dev.platform_data = NULL) {
+ if (dev_get_platdata(&pdev->dev) = NULL) {
dev_err(&pdev->dev, "missing platform data\n");
r = -ENOENT;
goto cleanup;
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox