Skip to contentSkip to conversation

OMAP2,3: hwmod DSS Adaptation

PATCH New Sumit Semwal 9 participants 44 messages Jan 24, 2011 – Mar 1, 2011

Subsystems (6)
lore
Share & tools
lore
#0 lore raw

v10 cover OMAP2,3: hwmod DSS Adaptation

v10 of the patch series corrects return-error handling from platform_request_irq() based on comments from Sergei Shtylyov and Russell King.
[https://patchwork.kernel.org/patch/497911/]

v9 of this patch series adds reviewed-by and acked-by from Kevin Hilman.

v8 of the DSS hwmod patch series fixes some issues based on findings of Kevin Hilman on beagle.

The VENC platform driver was not getting registered due to missed device name update for vdda_dac regulator in some board files. This was moved from 'omap_display' device to 'omap_venc' device in patch 14/18.

Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs two instances - one for dpi, and one for dsi.

This version corrects the above two for all board files where 'vdda_dac' and 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18]

Post this change, boot w/ visible framebuffer and tux was successfully validated on beagle, 3430SDP and zoom3.

A patch mentioned in
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42384.html was needed to get OMAP3 to boot up on top of linux-next of 20110115.

OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design.

-------------------------------------------------
[original patch introduction]

This patch series decouples the "Clocks for DSS in hwmod adaptation" changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3.

Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling.

Summary of the hwmod DSS design:
================================
DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database.

Each of these platform drivers' init / deinit are handled from core.c's omap_dss_probe() in the exact sequence as required.

No Hardcoding of silicon data:
hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series.

Continue to have custom bus for display panels:
"omap_display" driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver)
For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o).

Clocks:
Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately.
For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK.

Current dss driver:
-------------------
1. Omapdss platform driver
- initialises necessary Ips dss, dispc.
- also initialises Ips like sdi, dsi, venc, rfbi
- creates a custom bus and registers the display devices/drivers connected on the board to the custom bus.

2. Suspend/resume of omapdss
- in turn sends suspend/resume calls for each of the display devices registered to it.

Modified change:
---------------
Platform driver for each DSS HW IP in addition to the software "omap_display" driver.

Omapdss platform driver
- initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, venc, rfbi] and software libraries like dpi, sdi.
- continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus.
- continues to handle suspend/resume of the display devices registered to the custom bus.

DSS platform driver
- initialises DSS IP alone
- Handles the clocks related to the DSS and other DSSHW IPs like RFBI, DSI, VENC, DISPC. Previously this was a part of "omapdss" driver in core.c
- Continues to handle the DSS IRQs.
- No suspend/resume hooks.

DISPC platform driver
- initialises DISPC IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.

DSI platform driver
- initialises DSI IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DSI library functions.

RFBI, VENC platform drivers
- initialises DSI,VENC IPs
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide RFBI and VENC library functions.

Testing:
---------
The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp.
For the rest of the mentioned platforms, kernel is built with "OMAP2_DSS" and bootup is tested so that base address and clk_get calls are successful.

DSS was built successfully as module, though not tested yet.

Changes since v6:
-----------------
* board-zoom-peripherals.c: Added missing change of device name from omapdss to omap_display. Found during testing on OMAP3630 on top of
Changes since v5:
----------------
1) Following review comments incorporated:
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42031.html
Make sure display.c is built when DSS is enabled built-in or as a module.
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42083.html
hwmod and omap_device headers moved to patch 8 when they're needed the first time.
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42094.html
- latency set to AUTO_ADJUST
- extra whitespaces removed.
- pdata memset to 0 before use.
- if omap_device_build fails, return error.
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42095.html
renamed *_deinit_* to *_uninit_*

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42171.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42172.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42173.html
- added L3 and L4 firewall related data,
- corrected handling of .idlest_idle_bit v/w .idlest_stdby_bit
- no .idlest_*_bit setting for dependent hwmods
- corrected .user to add SDMA
- renamed dss_dss to dss_core
- hwmod for 3430es1 and later 3xxx are separated out, with some reuse of data.
* Removed forced-disable of dss clocks from omap_dss_remove.

Changes since v4:
----------------
1) Following review comments incorporated:
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41970.html
Corrected the clocks to be enabled in omap_dss_probe.
Changes since v3:
----------------
1.) Following review comments incorporated:
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41705.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41683.html
Created a new display.c file for dss driver registration related code.

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41573.html
Changed the oh_name/dev_name handling in hwmod usage.

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41753.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41718.html
removed device_initcall_sync(); init / deinit of each DSS h/w IP platform drivers are done from omap_dss_probe() in sequence.

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41754.html
clock patches were cleaned up as per review comments.

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41756.html
printk() => dev_dbg change was separated out.

Changes since v2:
-------------------
1.) Following review comments incorporated:
Split the device/driver name change and registration patches logically.
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41205.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41204.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41203.html

Changes since v1:
------------------
1.) Dynamically register for OMAP2,3 specific DSS HW IPs in devices.c 2.) Following review comments incorporated:
Updation of all the board files on l-o dss2 branch as per
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36915.html Comments incorporated in devices.c and display.h as per
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36919.html Comments incorporated in dispc.c, dss.c, dsi.c, venc.c, rfbi.c so that platform_device is just above platform_driver registrations as per
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36963.html
3.) Squashed some of the patches to one patch.

Changes since RFC:
-------------------
1) All the platform driver registration except DSS, were within the file core.c. Registeration of these driver got seperated to its own file.
2) Usage of regulators by different drivers are implemented.
For Eg: Regulator used by VENC is moved to venc driver. But vdda_dac would be needed by DPI and DSI as well.
4) OMAP2420 and OMAP2430 hwmod database are generated in this v1.
5) Module support for omapdss driver can continue as the DSS HW IP specific platform drivers are decoupled from omapdss driver.
6) Following review comments incorporated:
Changed the hwmod device name from "dss" to "dss_dss"
Changed name of core driver from "omapdss" to "omap_display" as it deals with panels. Fixed comments on return values from platform_get_resource/irq functions.

Patch Base:
===========
Patch-set rebased and tested w/ Zoom3 (OMAP3630) on top of:
url = git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch "master"
commit e8883f8057c0f7c9950fa9f20568f37bfa62f34a
Description: Add linux-next specific files for 20110115
+
Patch mentioned in http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42384.html [PATCH] OMAP: counter_32k: init clocksource as part of machine timer init

(This patch is required for OMAP bootup w/ 20110115 linux-next)

----------------------------------------------------------------------------

Senthilvadivu Guruswamy (15):
OMAP2420: hwmod data: add DSS DISPC RFBI VENC
OMAP2430: hwmod data: add DSS DISPC RFBI VENC
OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC
OMAP2,3 DSS2 Change driver name to omap_display
OMAP2,3 DSS2 Use Regulator init with driver name
OMAP2,3: DSS2: board files: replace platform_device_register with
omap_display_init()
OMAP2,3: DSS2: Build omap_device for each DSS HWIP OMAP2,3: DSS2: DSS: create platform_driver, move init,exit to driver OMAP2,3: DSS2: Move clocks from core driver to dss driver OMAP2,3: DSS2: RFBI: create platform_driver, move init,exit to driver OMAP2,3: DSS2: DISPC: create platform_driver, move init,exit to
driver
OMAP2,3: DSS2: VENC: create platform_driver, move init,exit to driver OMAP2,3: DSS2: DSI: create platform_driver, move init,exit to driver OMAP2,3: DSS2: Use platform device to get baseaddr OMAP2,3: DSS2: Get DSS IRQ from platform device

Sumit Semwal (3):
OMAP2,3: DSS2: remove forced clk-disable from omap_dss_remove OMAP2,3: DSS2: Create new file display.c for central dss driver
registration.
OMAP2,3: DSS2: replace printk with dev_dbg in init

 arch/arm/mach-omap2/Makefile                 |    3 +
 arch/arm/mach-omap2/board-3430sdp.c          |   26 +--
 arch/arm/mach-omap2/board-am3517evm.c        |   16 +-
 arch/arm/mach-omap2/board-cm-t35.c           |   22 +-
 arch/arm/mach-omap2/board-devkit8000.c       |   22 +-
 arch/arm/mach-omap2/board-igep0020.c         |   20 +-
 arch/arm/mach-omap2/board-omap3beagle.c      |   22 +-
 arch/arm/mach-omap2/board-omap3evm.c         |   30 +--
 arch/arm/mach-omap2/board-omap3pandora.c     |   17 +-
 arch/arm/mach-omap2/board-omap3stalker.c     |   26 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c |    4 +-
 arch/arm/mach-omap2/board-rx51-video.c       |   15 +-
 arch/arm/mach-omap2/board-zoom-display.c     |   15 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |   12 +-
 arch/arm/mach-omap2/clock2420_data.c         |    8 +-
 arch/arm/mach-omap2/clock2430_data.c         |    8 +-
 arch/arm/mach-omap2/clock3xxx_data.c         |   14 +-
 arch/arm/mach-omap2/display.c                |   96 ++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c   |  311 ++++++++++++++++++-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c   |  284 ++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c   |  433 +++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/display.h    |   16 +
 arch/arm/plat-omap/include/plat/l3_2xxx.h    |   20 ++
 arch/arm/plat-omap/include/plat/l3_3xxx.h    |   20 ++
 arch/arm/plat-omap/include/plat/l4_2xxx.h    |   24 ++
 arch/arm/plat-omap/include/plat/l4_3xxx.h    |   10 +
 drivers/video/omap2/dss/core.c               |  448 ++------------------------
 drivers/video/omap2/dss/dispc.c              |  114 ++++---
 drivers/video/omap2/dss/dsi.c                |   78 ++++-
 drivers/video/omap2/dss/dss.c                |  419 +++++++++++++++++++++++-
 drivers/video/omap2/dss/dss.h                |   46 ++--
 drivers/video/omap2/dss/rfbi.c               |  118 ++++---
 drivers/video/omap2/dss/venc.c               |  125 +++++---
 33 files changed, 2055 insertions(+), 787 deletions(-)
 create mode 100644 arch/arm/mach-omap2/display.c
 create mode 100644 arch/arm/plat-omap/include/plat/l3_2xxx.h
 create mode 100644 arch/arm/plat-omap/include/plat/l3_3xxx.h
 create mode 100644 arch/arm/plat-omap/include/plat/l4_2xxx.h
#1 lore raw

PATCH v10 1/18 OMAP2, 3: DSS2: remove forced clk-disable from omap_dss_remove

As part of omap hwmod changes, DSS will not be the only controller of its clocks. hwmod initialization also enables the interface clocks, and manages them.
So, when DSS is built as a module, omap_dss_remove doesn't try to disable all clocks that have a higher usecount.

---
 drivers/video/omap2/dss/core.c |   46 ++++++---------------------------------
 1 files changed, 7 insertions(+), 39 deletions(-)
drivers/video/omap2/dss/core.c +7 -39
index 8e89f60..ee56859 100644
@@ -623,7 +623,6 @@ static int omap_dss_remove(struct platform_device *pdev)
 {
 	struct omap_dss_board_info *pdata = pdev->dev.platform_data;
 	int i;
-	int c;
 
 	dss_uninitialize_debugfs();
 
@@ -638,44 +637,13 @@ static int omap_dss_remove(struct platform_device *pdev)
 
 	dss_exit();
 
-	/* these should be removed at some point */
-	c = core.dss_ick->usecount;
-	if (c > 0) {
-		DSSERR("warning: dss_ick usecount %d, disabling\n", c);
-		while (c-- > 0)
-			clk_disable(core.dss_ick);
-	}
-
-	c = core.dss1_fck->usecount;
-	if (c > 0) {
-		DSSERR("warning: dss1_fck usecount %d, disabling\n", c);
-		while (c-- > 0)
-			clk_disable(core.dss1_fck);
-	}
-
-	c = core.dss2_fck->usecount;
-	if (c > 0) {
-		DSSERR("warning: dss2_fck usecount %d, disabling\n", c);
-		while (c-- > 0)
-			clk_disable(core.dss2_fck);
-	}
-
-	c = core.dss_54m_fck->usecount;
-	if (c > 0) {
-		DSSERR("warning: dss_54m_fck usecount %d, disabling\n", c);
-		while (c-- > 0)
-			clk_disable(core.dss_54m_fck);
-	}
-
-	if (core.dss_96m_fck) {
-		c = core.dss_96m_fck->usecount;
-		if (c > 0) {
-			DSSERR("warning: dss_96m_fck usecount %d, disabling\n",
-					c);
-			while (c-- > 0)
-				clk_disable(core.dss_96m_fck);
-		}
-	}
+	/*
+	 * As part of hwmod changes, DSS is not the only controller of dss
+	 * clocks; hwmod framework itself will also enable clocks during hwmod
+	 * init for dss, and autoidle is set in h/w for DSS. Hence, there's no
+	 * need to disable clocks if their usecounts > 1.
+	 */
+	WARN_ON(core.num_clks_enabled > 0);
 
 	dss_put_clocks();
 
Signature · 1 line
1.7.1
#2 lore raw

PATCH v10 2/18 OMAP2420: hwmod data: add DSS DISPC RFBI VENC

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Hwmod needs database of all IPs in a system. This patch generates the hwmod database for OMAP2420 Display Sub System,. Since DSS is also considered as an IP as DISPC, RFBI, name it as dss_core.

---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  311 +++++++++++++++++++++++++++-
 arch/arm/plat-omap/include/plat/l3_2xxx.h  |   20 ++
 arch/arm/plat-omap/include/plat/l4_2xxx.h  |   24 +++
 3 files changed, 354 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/l3_2xxx.h
 create mode 100644 arch/arm/plat-omap/include/plat/l4_2xxx.h
arch/arm/mach-omap2/omap_hwmod_2420_data.c +310 -1
index b85c630..21014de 100644
@@ -18,7 +18,8 @@
 #include <plat/serial.h>
 #include <plat/i2c.h>
 #include <plat/gpio.h>
-
+#include <plat/l3_2xxx.h>
+#include <plat/l4_2xxx.h>
 #include "omap_hwmod_common_data.h"
 
 #include "cm-regbits-24xx.h"
@@ -38,6 +39,10 @@ static struct omap_hwmod omap2420_mpu_hwmod;
 static struct omap_hwmod omap2420_iva_hwmod;
 static struct omap_hwmod omap2420_l3_main_hwmod;
 static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_dss_core_hwmod;
+static struct omap_hwmod omap2420_dss_dispc_hwmod;
+static struct omap_hwmod omap2420_dss_rfbi_hwmod;
+static struct omap_hwmod omap2420_dss_venc_hwmod;
 static struct omap_hwmod omap2420_wd_timer2_hwmod;
 static struct omap_hwmod omap2420_gpio1_hwmod;
 static struct omap_hwmod omap2420_gpio2_hwmod;
@@ -64,6 +69,19 @@ static struct omap_hwmod_ocp_if *omap2420_l3_main_slaves[] = {
 	&omap2420_mpu__l3_main,
 };
 
+/* DSS -> l3 */
+static struct omap_hwmod_ocp_if omap2420_dss__l3 = {
+	.master		= &omap2420_dss_core_hwmod,
+	.slave		= &omap2420_l3_main_hwmod,
+	.fw = {
+		.omap2 = {
+			.l3_perm_bit  = OMAP2_L3_CORE_FW_CONNID_DSS,
+			.flags	= OMAP_FIREWALL_L3,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* Master interfaces on the L3 interconnect */
 static struct omap_hwmod_ocp_if *omap2420_l3_main_masters[] = {
 	&omap2420_l3_main__l4_core,
@@ -470,6 +488,291 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
 };
 
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dss_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dss_hwmod_class = {
+	.name = "dss",
+	.sysc = &omap2420_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2420_dss_irqs[] = {
+	{ .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap2420_dss_sdma_chs[] = {
+	{ .name = "dispc", .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_masters[] = {
+	&omap2420_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2420_dss_addrs[] = {
+	{
+		.pa_start	= 0x48050000,
+		.pa_end		= 0x480503FF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dss = {
+	.master		= &omap2420_l4_core_hwmod,
+	.slave		= &omap2420_dss_core_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap2420_dss_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2420_dss_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP2420_L4_CORE_FW_DSS_CORE_REGION,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_slaves[] = {
+	&omap2420_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+	{ .role = "tv_clk", .clk = "dss_54m_fck" },
+	{ .role = "sys_clk", .clk = "dss2_fck" },
+};
+
+static struct omap_hwmod omap2420_dss_core_hwmod = {
+	.name		= "dss_core",
+	.class		= &omap2420_dss_hwmod_class,
+	.main_clk	= "dss1_fck", /* instead of dss_fck */
+	.mpu_irqs	= omap2420_dss_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(omap2420_dss_irqs),
+	.sdma_reqs	= omap2420_dss_sdma_chs,
+	.sdma_reqs_cnt	= ARRAY_SIZE(omap2420_dss_sdma_chs),
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP24XX_EN_DSS1_SHIFT,
+			.module_offs = CORE_MOD,
+			.idlest_reg_id = 1,
+			.idlest_stdby_bit = OMAP24XX_ST_DSS_SHIFT,
+		},
+	},
+	.opt_clks	= dss_opt_clks,
+	.opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+	.slaves		= omap2420_dss_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2420_dss_slaves),
+	.masters	= omap2420_dss_masters,
+	.masters_cnt	= ARRAY_SIZE(omap2420_dss_masters),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dispc_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dispc_hwmod_class = {
+	.name = "dispc",
+	.sysc = &omap2420_dispc_sysc,
+};
+
+static struct omap_hwmod_addr_space omap2420_dss_dispc_addrs[] = {
+	{
+		.pa_start	= 0x48050400,
+		.pa_end		= 0x480507FF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_dispc */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dss_dispc = {
+	.master		= &omap2420_l4_core_hwmod,
+	.slave		= &omap2420_dss_dispc_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap2420_dss_dispc_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2420_dss_dispc_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP2420_L4_CORE_FW_DSS_DISPC_REGION,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_dispc slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_dispc_slaves[] = {
+	&omap2420_l4_core__dss_dispc,
+};
+
+static struct omap_hwmod omap2420_dss_dispc_hwmod = {
+	.name		= "dss_dispc",
+	.class		= &omap2420_dispc_hwmod_class,
+	.main_clk	= "dss1_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP24XX_EN_DSS1_SHIFT,
+			.module_offs = CORE_MOD,
+			.idlest_reg_id = 1,
+			.idlest_stdby_bit = OMAP24XX_ST_DSS_SHIFT,
+		},
+	},
+	.slaves		= omap2420_dss_dispc_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2420_dss_dispc_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'rfbi' class
+ * remote frame buffer interface
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_rfbi_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_rfbi_hwmod_class = {
+	.name = "rfbi",
+	.sysc = &omap2420_rfbi_sysc,
+};
+
+static struct omap_hwmod_addr_space omap2420_dss_rfbi_addrs[] = {
+	{
+		.pa_start	= 0x48050800,
+		.pa_end		= 0x48050BFF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_rfbi */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dss_rfbi = {
+	.master		= &omap2420_l4_core_hwmod,
+	.slave		= &omap2420_dss_rfbi_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap2420_dss_rfbi_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2420_dss_rfbi_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP2420_L4_CORE_FW_DSS_CORE_REGION,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_rfbi slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_rfbi_slaves[] = {
+	&omap2420_l4_core__dss_rfbi,
+};
+
+static struct omap_hwmod omap2420_dss_rfbi_hwmod = {
+	.name		= "dss_rfbi",
+	.class		= &omap2420_rfbi_hwmod_class,
+	.main_clk	= "dss1_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP24XX_EN_DSS1_SHIFT,
+			.module_offs = CORE_MOD,
+		},
+	},
+	.slaves		= omap2420_dss_rfbi_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2420_dss_rfbi_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'venc' class
+ * video encoder
+ */
+
+static struct omap_hwmod_class omap2420_venc_hwmod_class = {
+	.name = "venc",
+};
+
+/* dss_venc */
+static struct omap_hwmod_addr_space omap2420_dss_venc_addrs[] = {
+	{
+		.pa_start	= 0x48050C00,
+		.pa_end		= 0x48050FFF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_venc */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dss_venc = {
+	.master		= &omap2420_l4_core_hwmod,
+	.slave		= &omap2420_dss_venc_hwmod,
+	.clk		= "dss_54m_fck",
+	.addr		= omap2420_dss_venc_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2420_dss_venc_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP2420_L4_CORE_FW_DSS_VENC_REGION,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_venc slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_venc_slaves[] = {
+	&omap2420_l4_core__dss_venc,
+};
+
+static struct omap_hwmod omap2420_dss_venc_hwmod = {
+	.name		= "dss_venc",
+	.class		= &omap2420_venc_hwmod_class,
+	.main_clk	= "dss1_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP24XX_EN_DSS1_SHIFT,
+			.module_offs = CORE_MOD,
+		},
+	},
+	.slaves		= omap2420_dss_venc_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2420_dss_venc_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
 /* I2C common */
 static struct omap_hwmod_class_sysconfig i2c_sysc = {
 	.rev_offs	= 0x00,
@@ -874,6 +1177,12 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
 	&omap2420_uart1_hwmod,
 	&omap2420_uart2_hwmod,
 	&omap2420_uart3_hwmod,
+	/* dss class */
+	&omap2420_dss_core_hwmod,
+	&omap2420_dss_dispc_hwmod,
+	&omap2420_dss_rfbi_hwmod,
+	&omap2420_dss_venc_hwmod,
+	/* i2c class */
 	&omap2420_i2c1_hwmod,
 	&omap2420_i2c2_hwmod,
 
arch/arm/plat-omap/include/plat/l3_2xxx.h new file +20 -0
new file mode 100644
index 0000000..b8b5641
@@ -0,0 +1,20 @@
+/*
+ * arch/arm/plat-omap/include/plat/l3_2xxx.h - L3 firewall definitions
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *	Sumit Semwal
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_L3_2XXX_H
+#define __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_L3_2XXX_H
+
+/* L3 CONNIDs */
+/* Display Sub system (DSS) */
+#define OMAP2_L3_CORE_FW_CONNID_DSS			8
+
+#endif
arch/arm/plat-omap/include/plat/l4_2xxx.h new file +24 -0
new file mode 100644
index 0000000..3f39cf8
@@ -0,0 +1,24 @@
+/*
+ * arch/arm/plat-omap/include/plat/l4_2xxx.h - L4 firewall definitions
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *	Sumit Semwal
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_L4_2XXX_H
+#define __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_L4_2XXX_H
+
+/* L4 CORE */
+/* Display Sub system (DSS) */
+#define OMAP2420_L4_CORE_FW_DSS_CORE_REGION			28
+#define OMAP2420_L4_CORE_FW_DSS_DISPC_REGION			29
+#define OMAP2420_L4_CORE_FW_DSS_RFBI_REGION			30
+#define OMAP2420_L4_CORE_FW_DSS_VENC_REGION			31
+#define OMAP2420_L4_CORE_FW_DSS_TA_REGION			32
+
+#endif
Signature · 1 line
1.7.1
#3 lore raw

PATCH v10 3/18 OMAP2430: hwmod data: add DSS DISPC RFBI VENC

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Hwmod needs database of all IPs in a system. This patch generates the hwmod database for OMAP2430 Display Sub System. Since DSS is also considered as an IP as DISPC, RFBI, name it as dss_core.

---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  284 ++++++++++++++++++++++++++++
 1 files changed, 284 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_hwmod_2430_data.c +284 -0
index 8ecfbcd..1ef3f3f 100644
@@ -18,6 +18,7 @@
 #include <plat/serial.h>
 #include <plat/i2c.h>
 #include <plat/gpio.h>
+#include <plat/l3_2xxx.h>
 
 #include "omap_hwmod_common_data.h"
 
@@ -38,6 +39,10 @@ static struct omap_hwmod omap2430_mpu_hwmod;
 static struct omap_hwmod omap2430_iva_hwmod;
 static struct omap_hwmod omap2430_l3_main_hwmod;
 static struct omap_hwmod omap2430_l4_core_hwmod;
+static struct omap_hwmod omap2430_dss_core_hwmod;
+static struct omap_hwmod omap2430_dss_dispc_hwmod;
+static struct omap_hwmod omap2430_dss_rfbi_hwmod;
+static struct omap_hwmod omap2430_dss_venc_hwmod;
 static struct omap_hwmod omap2430_wd_timer2_hwmod;
 static struct omap_hwmod omap2430_gpio1_hwmod;
 static struct omap_hwmod omap2430_gpio2_hwmod;
@@ -65,6 +70,19 @@ static struct omap_hwmod_ocp_if *omap2430_l3_main_slaves[] = {
 	&omap2430_mpu__l3_main,
 };
 
+/* DSS -> l3 */
+static struct omap_hwmod_ocp_if omap2430_dss__l3 = {
+	.master		= &omap2430_dss_core_hwmod,
+	.slave		= &omap2430_l3_main_hwmod,
+	.fw = {
+		.omap2 = {
+			.l3_perm_bit  = OMAP2_L3_CORE_FW_CONNID_DSS,
+			.flags	= OMAP_FIREWALL_L3,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* Master interfaces on the L3 interconnect */
 static struct omap_hwmod_ocp_if *omap2430_l3_main_masters[] = {
 	&omap2430_l3_main__l4_core,
@@ -469,6 +487,266 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
 };
 
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dss_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dss_hwmod_class = {
+	.name = "dss",
+	.sysc = &omap2430_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2430_dss_irqs[] = {
+	{ .irq = 25 },
+};
+static struct omap_hwmod_dma_info omap2430_dss_sdma_chs[] = {
+	{ .name = "dispc", .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_masters[] = {
+	&omap2430_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2430_dss_addrs[] = {
+	{
+		.pa_start	= 0x48050000,
+		.pa_end		= 0x480503FF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dss = {
+	.master		= &omap2430_l4_core_hwmod,
+	.slave		= &omap2430_dss_core_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap2430_dss_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2430_dss_addrs),
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_slaves[] = {
+	&omap2430_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+	{ .role = "tv_clk", .clk = "dss_54m_fck" },
+	{ .role = "sys_clk", .clk = "dss2_fck" },
+};
+
+static struct omap_hwmod omap2430_dss_core_hwmod = {
+	.name		= "dss_core",
+	.class		= &omap2430_dss_hwmod_class,
+	.main_clk	= "dss1_fck", /* instead of dss_fck */
+	.mpu_irqs	= omap2430_dss_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(omap2430_dss_irqs),
+	.sdma_reqs	= omap2430_dss_sdma_chs,
+	.sdma_reqs_cnt	= ARRAY_SIZE(omap2430_dss_sdma_chs),
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP24XX_EN_DSS1_SHIFT,
+			.module_offs = CORE_MOD,
+			.idlest_reg_id = 1,
+			.idlest_stdby_bit = OMAP24XX_ST_DSS_SHIFT,
+		},
+	},
+	.opt_clks	= dss_opt_clks,
+	.opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+	.slaves		= omap2430_dss_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2430_dss_slaves),
+	.masters	= omap2430_dss_masters,
+	.masters_cnt	= ARRAY_SIZE(omap2430_dss_masters),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dispc_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dispc_hwmod_class = {
+	.name = "dispc",
+	.sysc = &omap2430_dispc_sysc,
+};
+
+static struct omap_hwmod_addr_space omap2430_dss_dispc_addrs[] = {
+	{
+		.pa_start	= 0x48050400,
+		.pa_end		= 0x480507FF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_dispc */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dss_dispc = {
+	.master		= &omap2430_l4_core_hwmod,
+	.slave		= &omap2430_dss_dispc_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap2430_dss_dispc_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2430_dss_dispc_addrs),
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_dispc slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_dispc_slaves[] = {
+	&omap2430_l4_core__dss_dispc,
+};
+
+static struct omap_hwmod omap2430_dss_dispc_hwmod = {
+	.name		= "dss_dispc",
+	.class		= &omap2430_dispc_hwmod_class,
+	.main_clk	= "dss1_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP24XX_EN_DSS1_SHIFT,
+			.module_offs = CORE_MOD,
+			.idlest_reg_id = 1,
+			.idlest_stdby_bit = OMAP24XX_ST_DSS_SHIFT,
+		},
+	},
+	.slaves		= omap2430_dss_dispc_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2430_dss_dispc_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'rfbi' class
+ * remote frame buffer interface
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_rfbi_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_rfbi_hwmod_class = {
+	.name = "rfbi",
+	.sysc = &omap2430_rfbi_sysc,
+};
+
+static struct omap_hwmod_addr_space omap2430_dss_rfbi_addrs[] = {
+	{
+		.pa_start	= 0x48050800,
+		.pa_end		= 0x48050BFF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_rfbi */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dss_rfbi = {
+	.master		= &omap2430_l4_core_hwmod,
+	.slave		= &omap2430_dss_rfbi_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap2430_dss_rfbi_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2430_dss_rfbi_addrs),
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_rfbi slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_rfbi_slaves[] = {
+	&omap2430_l4_core__dss_rfbi,
+};
+
+static struct omap_hwmod omap2430_dss_rfbi_hwmod = {
+	.name		= "dss_rfbi",
+	.class		= &omap2430_rfbi_hwmod_class,
+	.main_clk	= "dss1_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP24XX_EN_DSS1_SHIFT,
+			.module_offs = CORE_MOD,
+		},
+	},
+	.slaves		= omap2430_dss_rfbi_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2430_dss_rfbi_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'venc' class
+ * video encoder
+ */
+
+static struct omap_hwmod_class omap2430_venc_hwmod_class = {
+	.name = "venc",
+};
+
+/* dss_venc */
+static struct omap_hwmod_addr_space omap2430_dss_venc_addrs[] = {
+	{
+		.pa_start	= 0x48050C00,
+		.pa_end		= 0x48050FFF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_venc */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dss_venc = {
+	.master		= &omap2430_l4_core_hwmod,
+	.slave		= &omap2430_dss_venc_hwmod,
+	.clk		= "dss_54m_fck",
+	.addr		= omap2430_dss_venc_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2430_dss_venc_addrs),
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_venc slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_venc_slaves[] = {
+	&omap2430_l4_core__dss_venc,
+};
+
+static struct omap_hwmod omap2430_dss_venc_hwmod = {
+	.name		= "dss_venc",
+	.class		= &omap2430_venc_hwmod_class,
+	.main_clk	= "dss1_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP24XX_EN_DSS1_SHIFT,
+			.module_offs = CORE_MOD,
+		},
+	},
+	.slaves		= omap2430_dss_venc_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2430_dss_venc_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
 /* I2C common */
 static struct omap_hwmod_class_sysconfig i2c_sysc = {
 	.rev_offs	= 0x00,
@@ -929,6 +1207,12 @@ static __initdata struct omap_hwmod *omap2430_hwmods[] = {
 	&omap2430_uart1_hwmod,
 	&omap2430_uart2_hwmod,
 	&omap2430_uart3_hwmod,
+	/* dss class */
+	&omap2430_dss_core_hwmod,
+	&omap2430_dss_dispc_hwmod,
+	&omap2430_dss_rfbi_hwmod,
+	&omap2430_dss_venc_hwmod,
+	/* i2c class */
 	&omap2430_i2c1_hwmod,
 	&omap2430_i2c2_hwmod,
 
Signature · 1 line
1.7.1
#4 lore raw

PATCH v10 4/18 OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Hwmod needs database of all IPs in a system. This patch generates the hwmod database for Display Sub System applicable for OMAP3430 and OMAP36xx. DSS is also considered as an IP as DISPC, RFBI and named as dss_core. For all the IP modules in DSS, same clock is needed for enabling. Hwmod sees DSS IPs as independent IPs, so same clock has to be repeated for .main_clk in each IP.

This patch defines separate hwmod databases for OMAP3430ES1 and (OMAP3430ES2 and OMAP36xx) as OMAP3430ES1 does not have IDLEST bit to poll on for dss IP, and also the firewall regions are different between 3430es1 and later.

---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  433 ++++++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/l3_3xxx.h  |   20 ++
 arch/arm/plat-omap/include/plat/l4_3xxx.h  |   10 +
 3 files changed, 463 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/l3_3xxx.h
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +433 -0
index 8d81813..713165d 100644
@@ -18,6 +18,7 @@
 #include <plat/cpu.h>
 #include <plat/dma.h>
 #include <plat/serial.h>
+#include <plat/l3_3xxx.h>
 #include <plat/l4_3xxx.h>
 #include <plat/i2c.h>
 #include <plat/gpio.h>
@@ -44,6 +45,12 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod;
 static struct omap_hwmod omap3xxx_l4_core_hwmod;
 static struct omap_hwmod omap3xxx_l4_per_hwmod;
 static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
+static struct omap_hwmod omap3430es1_dss_core_hwmod;
+static struct omap_hwmod omap3xxx_dss_core_hwmod;
+static struct omap_hwmod omap3xxx_dss_dispc_hwmod;
+static struct omap_hwmod omap3xxx_dss_dsi1_hwmod;
+static struct omap_hwmod omap3xxx_dss_rfbi_hwmod;
+static struct omap_hwmod omap3xxx_dss_venc_hwmod;
 static struct omap_hwmod omap3xxx_i2c1_hwmod;
 static struct omap_hwmod omap3xxx_i2c2_hwmod;
 static struct omap_hwmod omap3xxx_i2c3_hwmod;
@@ -84,6 +91,19 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_main_slaves[] = {
 	&omap3xxx_mpu__l3_main,
 };
 
+/* DSS -> l3 */
+static struct omap_hwmod_ocp_if omap3xxx_dss__l3 = {
+	.master		= &omap3xxx_dss_core_hwmod,
+	.slave		= &omap3xxx_l3_main_hwmod,
+	.fw = {
+		.omap2 = {
+			.l3_perm_bit  = OMAP3_L3_CORE_FW_INIT_ID_DSS,
+			.flags	= OMAP_FIREWALL_L3,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* Master interfaces on the L3 interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l3_main_masters[] = {
 	&omap3xxx_l3_main__l4_core,
@@ -664,6 +684,410 @@ static struct omap_hwmod_class i2c_class = {
 	.sysc = &i2c_sysc,
 };
 
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dss_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dss_hwmod_class = {
+	.name = "dss",
+	.sysc = &omap3xxx_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap3xxx_dss_irqs[] = {
+	{ .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
+	{ .name = "dispc", .dma_req = 5 },
+	{ .name = "dsi1", .dma_req = 74 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_masters[] = {
+	&omap3xxx_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dss_addrs[] = {
+	{
+		.pa_start	= 0x48050000,
+		.pa_end		= 0x480503FF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss */
+static struct omap_hwmod_ocp_if omap3430es1_l4_core__dss = {
+	.master		= &omap3xxx_l4_core_hwmod,
+	.slave		= &omap3430es1_dss_core_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap3xxx_dss_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap3xxx_dss_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP3ES1_L4_CORE_FW_DSS_CORE_REGION,
+			.l4_prot_group = OMAP3_L4_CORE_FW_DSS_PROT_GROUP,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss = {
+	.master		= &omap3xxx_l4_core_hwmod,
+	.slave		= &omap3xxx_dss_core_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap3xxx_dss_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap3xxx_dss_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP3_L4_CORE_FW_DSS_CORE_REGION,
+			.l4_prot_group = OMAP3_L4_CORE_FW_DSS_PROT_GROUP,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap3430es1_dss_slaves[] = {
+	&omap3430es1_l4_core__dss,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_dss_slaves[] = {
+	&omap3xxx_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+	{ .role = "tv_clk", .clk = "dss_tv_fck" },
+	{ .role = "dssclk", .clk = "dss_96m_fck" },
+	{ .role = "sys_clk", .clk = "dss2_alwon_fck" },
+};
+
+static struct omap_hwmod omap3430es1_dss_core_hwmod = {
+	.name		= "dss_core",
+	.class		= &omap3xxx_dss_hwmod_class,
+	.main_clk	= "dss1_alwon_fck", /* instead of dss_fck */
+	.mpu_irqs	= omap3xxx_dss_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(omap3xxx_dss_irqs),
+	.sdma_reqs	= omap3xxx_dss_sdma_chs,
+	.sdma_reqs_cnt	= ARRAY_SIZE(omap3xxx_dss_sdma_chs),
+
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP3430_EN_DSS1_SHIFT,
+			.module_offs = OMAP3430_DSS_MOD,
+			.idlest_reg_id = 1,
+			.idlest_stdby_bit = OMAP3430ES1_ST_DSS_SHIFT,
+		},
+	},
+	.opt_clks	= dss_opt_clks,
+	.opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+	.slaves		= omap3430es1_dss_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3430es1_dss_slaves),
+	.masters	= omap3xxx_dss_masters,
+	.masters_cnt	= ARRAY_SIZE(omap3xxx_dss_masters),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+static struct omap_hwmod omap3xxx_dss_core_hwmod = {
+	.name		= "dss_core",
+	.class		= &omap3xxx_dss_hwmod_class,
+	.main_clk	= "dss1_alwon_fck", /* instead of dss_fck */
+	.mpu_irqs	= omap3xxx_dss_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(omap3xxx_dss_irqs),
+	.sdma_reqs	= omap3xxx_dss_sdma_chs,
+	.sdma_reqs_cnt	= ARRAY_SIZE(omap3xxx_dss_sdma_chs),
+
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP3430_EN_DSS1_SHIFT,
+			.module_offs = OMAP3430_DSS_MOD,
+			.idlest_reg_id = 1,
+			.idlest_idle_bit = OMAP3430ES2_ST_DSS_IDLE_SHIFT,
+			.idlest_stdby_bit = OMAP3430ES2_ST_DSS_STDBY_SHIFT,
+		},
+	},
+	.opt_clks	= dss_opt_clks,
+	.opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+	.slaves		= omap3xxx_dss_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3xxx_dss_slaves),
+	.masters	= omap3xxx_dss_masters,
+	.masters_cnt	= ARRAY_SIZE(omap3xxx_dss_masters),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2 |
+				CHIP_IS_OMAP3630ES1 | CHIP_GE_OMAP3630ES1_1),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dispc_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_MIDLEMODE | SYSC_HAS_ENAWAKEUP |
+			   SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dispc_hwmod_class = {
+	.name = "dispc",
+	.sysc = &omap3xxx_dispc_sysc,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dss_dispc_addrs[] = {
+	{
+		.pa_start	= 0x48050400,
+		.pa_end		= 0x480507FF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_dispc */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss_dispc = {
+	.master		= &omap3xxx_l4_core_hwmod,
+	.slave		= &omap3xxx_dss_dispc_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap3xxx_dss_dispc_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap3xxx_dss_dispc_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP3_L4_CORE_FW_DSS_DISPC_REGION,
+			.l4_prot_group = OMAP3_L4_CORE_FW_DSS_PROT_GROUP,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_dispc slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_dispc_slaves[] = {
+	&omap3xxx_l4_core__dss_dispc,
+};
+
+static struct omap_hwmod omap3xxx_dss_dispc_hwmod = {
+	.name		= "dss_dispc",
+	.class		= &omap3xxx_dispc_hwmod_class,
+	.main_clk	= "dss1_alwon_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP3430_EN_DSS1_SHIFT,
+			.module_offs = OMAP3430_DSS_MOD,
+		},
+	},
+	.slaves		= omap3xxx_dss_dispc_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3xxx_dss_dispc_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
+				CHIP_GE_OMAP3430ES2 | CHIP_IS_OMAP3630ES1 |
+				CHIP_GE_OMAP3630ES1_1),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'dsi' class
+ * display serial interface controller
+ */
+
+static struct omap_hwmod_class omap3xxx_dsi_hwmod_class = {
+	.name = "dsi",
+};
+
+/* dss_dsi1 */
+static struct omap_hwmod_addr_space omap3xxx_dss_dsi1_addrs[] = {
+	{
+		.pa_start	= 0x4804FC00,
+		.pa_end		= 0x4804FFFF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_dsi1 */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss_dsi1 = {
+	.master		= &omap3xxx_l4_core_hwmod,
+	.slave		= &omap3xxx_dss_dsi1_hwmod,
+	.addr		= omap3xxx_dss_dsi1_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap3xxx_dss_dsi1_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP3_L4_CORE_FW_DSS_DSI_REGION,
+			.l4_prot_group = OMAP3_L4_CORE_FW_DSS_PROT_GROUP,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_dsi1 slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_dsi1_slaves[] = {
+	&omap3xxx_l4_core__dss_dsi1,
+};
+
+static struct omap_hwmod omap3xxx_dss_dsi1_hwmod = {
+	.name		= "dss_dsi1",
+	.class		= &omap3xxx_dsi_hwmod_class,
+	.main_clk	= "dss1_alwon_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP3430_EN_DSS1_SHIFT,
+			.module_offs = OMAP3430_DSS_MOD,
+		},
+	},
+	.slaves		= omap3xxx_dss_dsi1_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3xxx_dss_dsi1_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
+				CHIP_GE_OMAP3430ES2 | CHIP_IS_OMAP3630ES1 |
+				CHIP_GE_OMAP3630ES1_1),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'rfbi' class
+ * remote frame buffer interface
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_rfbi_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_rfbi_hwmod_class = {
+	.name = "rfbi",
+	.sysc = &omap3xxx_rfbi_sysc,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dss_rfbi_addrs[] = {
+	{
+		.pa_start	= 0x48050800,
+		.pa_end		= 0x48050BFF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_rfbi */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss_rfbi = {
+	.master		= &omap3xxx_l4_core_hwmod,
+	.slave		= &omap3xxx_dss_rfbi_hwmod,
+	.clk		= "dss_ick",
+	.addr		= omap3xxx_dss_rfbi_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap3xxx_dss_rfbi_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP3_L4_CORE_FW_DSS_RFBI_REGION,
+			.l4_prot_group = OMAP3_L4_CORE_FW_DSS_PROT_GROUP ,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_rfbi slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_rfbi_slaves[] = {
+	&omap3xxx_l4_core__dss_rfbi,
+};
+
+static struct omap_hwmod omap3xxx_dss_rfbi_hwmod = {
+	.name		= "dss_rfbi",
+	.class		= &omap3xxx_rfbi_hwmod_class,
+	.main_clk	= "dss1_alwon_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP3430_EN_DSS1_SHIFT,
+			.module_offs = OMAP3430_DSS_MOD,
+		},
+	},
+	.slaves		= omap3xxx_dss_rfbi_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3xxx_dss_rfbi_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
+				CHIP_GE_OMAP3430ES2 | CHIP_IS_OMAP3630ES1 |
+				CHIP_GE_OMAP3630ES1_1),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'venc' class
+ * video encoder
+ */
+
+static struct omap_hwmod_class omap3xxx_venc_hwmod_class = {
+	.name = "venc",
+};
+
+/* dss_venc */
+static struct omap_hwmod_addr_space omap3xxx_dss_venc_addrs[] = {
+	{
+		.pa_start	= 0x48050C00,
+		.pa_end		= 0x48050FFF,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> dss_venc */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss_venc = {
+	.master		= &omap3xxx_l4_core_hwmod,
+	.slave		= &omap3xxx_dss_venc_hwmod,
+	.clk		= "dss_tv_fck",
+	.addr		= omap3xxx_dss_venc_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap3xxx_dss_venc_addrs),
+	.fw = {
+		.omap2 = {
+			.l4_fw_region  = OMAP3_L4_CORE_FW_DSS_VENC_REGION,
+			.l4_prot_group = OMAP3_L4_CORE_FW_DSS_PROT_GROUP,
+			.flags	= OMAP_FIREWALL_L4,
+		}
+	},
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss_venc slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_venc_slaves[] = {
+	&omap3xxx_l4_core__dss_venc,
+};
+
+static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
+	.name		= "dss_venc",
+	.class		= &omap3xxx_venc_hwmod_class,
+	.main_clk	= "dss1_alwon_fck",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP3430_EN_DSS1_SHIFT,
+			.module_offs = OMAP3430_DSS_MOD,
+		},
+	},
+	.slaves		= omap3xxx_dss_venc_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3xxx_dss_venc_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
+				CHIP_GE_OMAP3430ES2 | CHIP_IS_OMAP3630ES1 |
+				CHIP_GE_OMAP3630ES1_1),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
 /* I2C1 */
 
 static struct omap_i2c_dev_attr i2c1_dev_attr = {
@@ -1368,6 +1792,15 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 	&omap3xxx_uart2_hwmod,
 	&omap3xxx_uart3_hwmod,
 	&omap3xxx_uart4_hwmod,
+	/* dss class */
+	&omap3430es1_dss_core_hwmod,
+	&omap3xxx_dss_core_hwmod,
+	&omap3xxx_dss_dispc_hwmod,
+	&omap3xxx_dss_dsi1_hwmod,
+	&omap3xxx_dss_rfbi_hwmod,
+	&omap3xxx_dss_venc_hwmod,
+
+	/* i2c class */
 	&omap3xxx_i2c1_hwmod,
 	&omap3xxx_i2c2_hwmod,
 	&omap3xxx_i2c3_hwmod,
arch/arm/plat-omap/include/plat/l3_3xxx.h new file +20 -0
new file mode 100644
index 0000000..cde1938
@@ -0,0 +1,20 @@
+/*
+ * arch/arm/plat-omap/include/plat/l3_3xxx.h - L3 firewall definitions
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *	Sumit Semwal
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_L3_3XXX_H
+#define __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_L3_3XXX_H
+
+/* L3 Initiator IDs */
+/* Display Sub system (DSS) */
+#define OMAP3_L3_CORE_FW_INIT_ID_DSS			29
+
+#endif
arch/arm/plat-omap/include/plat/l4_3xxx.h +10 -0
index 5e19493..881a858 100644
@@ -21,4 +21,14 @@
 #define OMAP3_L4_CORE_FW_I2C3_REGION				73
 #define OMAP3_L4_CORE_FW_I2C3_TA_REGION				74
 
+/* Display Sub system (DSS) */
+#define OMAP3_L4_CORE_FW_DSS_PROT_GROUP				2
+
+#define OMAP3_L4_CORE_FW_DSS_DSI_REGION				104
+#define OMAP3ES1_L4_CORE_FW_DSS_CORE_REGION			3
+#define OMAP3_L4_CORE_FW_DSS_CORE_REGION			4
+#define OMAP3_L4_CORE_FW_DSS_DISPC_REGION			4
+#define OMAP3_L4_CORE_FW_DSS_RFBI_REGION			5
+#define OMAP3_L4_CORE_FW_DSS_VENC_REGION			6
+#define OMAP3_L4_CORE_FW_DSS_TA_REGION				7
 #endif
Signature · 1 line
1.7.1
#5 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

for: The clkdev changes in clock2420_data.c, clock2430_data.c, clock3xxx_data.c

---
 arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
 arch/arm/mach-omap2/board-am3517evm.c        |    2 +-
 arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
 arch/arm/mach-omap2/board-devkit8000.c       |    6 +++---
 arch/arm/mach-omap2/board-igep0020.c         |    2 +-
 arch/arm/mach-omap2/board-omap3beagle.c      |    6 +++---
 arch/arm/mach-omap2/board-omap3evm.c         |    4 ++--
 arch/arm/mach-omap2/board-omap3pandora.c     |    8 ++++----
 arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c |    4 ++--
 arch/arm/mach-omap2/board-rx51-video.c       |    2 +-
 arch/arm/mach-omap2/board-zoom-display.c     |    2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |    4 ++--
 arch/arm/mach-omap2/clock2420_data.c         |    8 ++++----
 arch/arm/mach-omap2/clock2430_data.c         |    8 ++++----
 arch/arm/mach-omap2/clock3xxx_data.c         |   14 +++++++-------
 drivers/video/omap2/dss/core.c               |    2 +-
 17 files changed, 39 insertions(+), 39 deletions(-)
arch/arm/mach-omap2/board-3430sdp.c +1 -1
index d4e41ef..6f4e7cf 100644
@@ -308,7 +308,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
 };
 
 static struct platform_device sdp3430_dss_device = {
-	.name		= "omapdss",
+	.name		= "omap_display",
 	.id		= -1,
 	.dev		= {
 		.platform_data = &sdp3430_dss_data,
arch/arm/mach-omap2/board-am3517evm.c +1 -1
index 10d60b7..6bb5f53 100644
@@ -379,7 +379,7 @@ static struct omap_dss_board_info am3517_evm_dss_data = {
 };
 
 static struct platform_device am3517_evm_dss_device = {
-	.name		= "omapdss",
+	.name		= "omap_display",
 	.id		= -1,
 	.dev		= {
 		.platform_data	= &am3517_evm_dss_data,
arch/arm/mach-omap2/board-cm-t35.c +1 -1
index dac1416..79f87ec 100644
@@ -402,7 +402,7 @@ static struct omap_dss_board_info cm_t35_dss_data = {
 };
 
 static struct platform_device cm_t35_dss_device = {
-	.name		= "omapdss",
+	.name		= "omap_display",
 	.id		= -1,
 	.dev		= {
 		.platform_data = &cm_t35_dss_data,
arch/arm/mach-omap2/board-devkit8000.c +3 -3
index 00bb1fc..ca8e1b1 100644
@@ -199,7 +199,7 @@ static struct omap_dss_board_info devkit8000_dss_data = {
 };
 
 static struct platform_device devkit8000_dss_device = {
-	.name		= "omapdss",
+	.name		= "omap_display",
 	.id		= -1,
 	.dev		= {
 		.platform_data = &devkit8000_dss_data,
@@ -207,7 +207,7 @@ static struct platform_device devkit8000_dss_device = {
 };
 
 static struct regulator_consumer_supply devkit8000_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omapdss");
+	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
 static uint32_t board_keymap[] = {
 	KEY(0, 0, KEY_1),
@@ -282,7 +282,7 @@ static struct twl4030_gpio_platform_data devkit8000_gpio_data = {
 };
 
 static struct regulator_consumer_supply devkit8000_vpll1_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss");
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
 
 /* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
 static struct regulator_init_data devkit8000_vmmc1 = {
arch/arm/mach-omap2/board-igep0020.c +1 -1
index 3be85a1..23abfa3 100644
@@ -486,7 +486,7 @@ static struct omap_dss_board_info igep2_dss_data = {
 };
 
 static struct platform_device igep2_dss_device = {
-	.name	= "omapdss",
+	.name	= "omap_display",
 	.id	= -1,
 	.dev	= {
 		.platform_data = &igep2_dss_data,
arch/arm/mach-omap2/board-omap3beagle.c +3 -3
index 46d814a..fd6b4b8 100644
@@ -229,7 +229,7 @@ static struct omap_dss_board_info beagle_dss_data = {
 };
 
 static struct platform_device beagle_dss_device = {
-	.name          = "omapdss",
+	.name          = "omap_display",
 	.id            = -1,
 	.dev            = {
 		.platform_data = &beagle_dss_data,
@@ -237,10 +237,10 @@ static struct platform_device beagle_dss_device = {
 };
 
 static struct regulator_consumer_supply beagle_vdac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omapdss");
+	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
 static struct regulator_consumer_supply beagle_vdvi_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss");
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
 
 static void __init beagle_display_init(void)
 {
arch/arm/mach-omap2/board-omap3evm.c +2 -2
index 323c380..4ad3c4d 100644
@@ -329,7 +329,7 @@ static struct omap_dss_board_info omap3_evm_dss_data = {
 };
 
 static struct platform_device omap3_evm_dss_device = {
-	.name		= "omapdss",
+	.name		= "omap_display",
 	.id		= -1,
 	.dev		= {
 		.platform_data = &omap3_evm_dss_data,
@@ -522,7 +522,7 @@ static struct regulator_init_data omap3_evm_vdac = {
 
 /* VPLL2 for digital video outputs */
 static struct regulator_consumer_supply omap3_evm_vpll2_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss");
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
 
 static struct regulator_init_data omap3_evm_vpll2 = {
 	.constraints = {
arch/arm/mach-omap2/board-omap3pandora.c +4 -4
index 0b34bed..9e8faf2 100644
@@ -254,7 +254,7 @@ static struct omap_dss_board_info pandora_dss_data = {
 };
 
 static struct platform_device pandora_dss_device = {
-	.name		= "omapdss",
+	.name		= "omap_display",
 	.id		= -1,
 	.dev		= {
 		.platform_data = &pandora_dss_data,
@@ -350,11 +350,11 @@ static struct regulator_consumer_supply pandora_vmmc3_supply =
 	REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.2");
 
 static struct regulator_consumer_supply pandora_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omapdss");
+	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
 static struct regulator_consumer_supply pandora_vdds_supplies[] = {
-	REGULATOR_SUPPLY("vdds_sdi", "omapdss"),
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
+	REGULATOR_SUPPLY("vdds_sdi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
 };
 
 static struct regulator_consumer_supply pandora_vcc_lcd_supply =
arch/arm/mach-omap2/board-omap3stalker.c +1 -1
index 2a2dad4..51c010c 100644
@@ -241,7 +241,7 @@ static struct omap_dss_board_info omap3_stalker_dss_data = {
 };
 
 static struct platform_device omap3_stalker_dss_device = {
-	.name	= "omapdss",
+	.name	= "omap_display",
 	.id	= -1,
 	.dev	= {
 		.platform_data	= &omap3_stalker_dss_data,
arch/arm/mach-omap2/board-rx51-peripherals.c +2 -2
index e75e240..7aedafd 100644
@@ -360,11 +360,11 @@ static struct regulator_consumer_supply rx51_vio_supplies[] = {
 };
 
 static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
-	REGULATOR_SUPPLY("vdds_sdi", "omapdss"),
+	REGULATOR_SUPPLY("vdds_sdi", "omap_display"),
 };
 
 static struct regulator_consumer_supply rx51_vdac_supply[] = {
-	REGULATOR_SUPPLY("vdda_dac", "omapdss"),
+	REGULATOR_SUPPLY("vdda_dac", "omap_display"),
 };
 
 static struct regulator_init_data rx51_vaux1 = {
arch/arm/mach-omap2/board-rx51-video.c +1 -1
index acd6700..8140d05 100644
@@ -67,7 +67,7 @@ static struct omap_dss_board_info rx51_dss_board_info = {
 };
 
 struct platform_device rx51_display_device = {
-	.name	= "omapdss",
+	.name	= "omap_display",
 	.id	= -1,
 	.dev	= {
 		.platform_data = &rx51_dss_board_info,
arch/arm/mach-omap2/board-zoom-display.c +1 -1
index 6bcd436..d6b949d 100644
@@ -131,7 +131,7 @@ static struct omap_dss_board_info zoom_dss_data = {
 };
 
 static struct platform_device zoom_dss_device = {
-	.name				= "omapdss",
+	.name				= "omap_display",
 	.id				= -1,
 	.dev				= {
 		.platform_data		= &zoom_dss_data,
arch/arm/mach-omap2/board-zoom-peripherals.c +2 -2
index e0e040f..d52fc7b 100644
@@ -227,10 +227,10 @@ static struct omap2_hsmmc_info mmc[] = {
 };
 
 static struct regulator_consumer_supply zoom_vpll2_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss");
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
 
 static struct regulator_consumer_supply zoom_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omapdss");
+	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
 static struct regulator_init_data zoom_vpll2 = {
 	.constraints = {
arch/arm/mach-omap2/clock2420_data.c +4 -4
index 0a992bc..b412958 100644
@@ -1786,10 +1786,10 @@ static struct omap_clk omap2420_clks[] = {
 	CLK(NULL,	"gfx_2d_fck",	&gfx_2d_fck,	CK_242X),
 	CLK(NULL,	"gfx_ick",	&gfx_ick,	CK_242X),
 	/* DSS domain clocks */
-	CLK("omapdss",	"ick",		&dss_ick,	CK_242X),
-	CLK("omapdss",	"dss1_fck",	&dss1_fck,	CK_242X),
-	CLK("omapdss",	"dss2_fck",	&dss2_fck,	CK_242X),
-	CLK("omapdss",	"tv_fck",	&dss_54m_fck,	CK_242X),
+	CLK("omap_display",	"ick",		&dss_ick,	CK_242X),
+	CLK("omap_display",	"dss1_fck",	&dss1_fck,	CK_242X),
+	CLK("omap_display",	"dss2_fck",	&dss2_fck,	CK_242X),
+	CLK("omap_display",	"tv_fck",	&dss_54m_fck,	CK_242X),
 	/* L3 domain clocks */
 	CLK(NULL,	"core_l3_ck",	&core_l3_ck,	CK_242X),
 	CLK(NULL,	"ssi_fck",	&ssi_ssr_sst_fck, CK_242X),
arch/arm/mach-omap2/clock2430_data.c +4 -4
index c047dcd..039155e 100644
@@ -1890,10 +1890,10 @@ static struct omap_clk omap2430_clks[] = {
 	CLK(NULL,	"mdm_ick",	&mdm_ick,	CK_243X),
 	CLK(NULL,	"mdm_osc_ck",	&mdm_osc_ck,	CK_243X),
 	/* DSS domain clocks */
-	CLK("omapdss",	"ick",		&dss_ick,	CK_243X),
-	CLK("omapdss",	"dss1_fck",	&dss1_fck,	CK_243X),
-	CLK("omapdss",	"dss2_fck",	&dss2_fck,	CK_243X),
-	CLK("omapdss",	"tv_fck",	&dss_54m_fck,	CK_243X),
+	CLK("omap_display",	"ick",		&dss_ick,	CK_243X),
+	CLK("omap_display",	"dss1_fck",	&dss1_fck,	CK_243X),
+	CLK("omap_display",	"dss2_fck",	&dss2_fck,	CK_243X),
+	CLK("omap_display",	"tv_fck",	&dss_54m_fck,	CK_243X),
 	/* L3 domain clocks */
 	CLK(NULL,	"core_l3_ck",	&core_l3_ck,	CK_243X),
 	CLK(NULL,	"ssi_fck",	&ssi_ssr_sst_fck, CK_243X),
arch/arm/mach-omap2/clock3xxx_data.c +7 -7
index 403a4a1..8618262 100644
@@ -3357,13 +3357,13 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK("omap_rng",	"ick",		&rng_ick,	CK_34XX | CK_36XX),
 	CLK(NULL,	"sha11_ick",	&sha11_ick,	CK_34XX | CK_36XX),
 	CLK(NULL,	"des1_ick",	&des1_ick,	CK_34XX | CK_36XX),
-	CLK("omapdss",	"dss1_fck",	&dss1_alwon_fck_3430es1, CK_3430ES1),
-	CLK("omapdss",	"dss1_fck",	&dss1_alwon_fck_3430es2, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
-	CLK("omapdss",	"tv_fck",	&dss_tv_fck,	CK_3XXX),
-	CLK("omapdss",	"video_fck",	&dss_96m_fck,	CK_3XXX),
-	CLK("omapdss",	"dss2_fck",	&dss2_alwon_fck, CK_3XXX),
-	CLK("omapdss",	"ick",		&dss_ick_3430es1,	CK_3430ES1),
-	CLK("omapdss",	"ick",		&dss_ick_3430es2,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+	CLK("omap_display",	"dss1_fck",	&dss1_alwon_fck_3430es1, CK_3430ES1),
+	CLK("omap_display",	"dss1_fck",	&dss1_alwon_fck_3430es2, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+	CLK("omap_display",	"tv_fck",	&dss_tv_fck,	CK_3XXX),
+	CLK("omap_display",	"video_fck",	&dss_96m_fck,	CK_3XXX),
+	CLK("omap_display",	"dss2_fck",	&dss2_alwon_fck, CK_3XXX),
+	CLK("omap_display",	"ick",		&dss_ick_3430es1,	CK_3430ES1),
+	CLK("omap_display",	"ick",		&dss_ick_3430es2,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 	CLK(NULL,	"cam_mclk",	&cam_mclk,	CK_34XX | CK_36XX),
 	CLK(NULL,	"cam_ick",	&cam_ick,	CK_34XX | CK_36XX),
 	CLK(NULL,	"csi2_96m_fck",	&csi2_96m_fck,	CK_34XX | CK_36XX),
drivers/video/omap2/dss/core.c +1 -1
index ee56859..1bbc004 100644
@@ -683,7 +683,7 @@ static struct platform_driver omap_dss_driver = {
 	.suspend	= omap_dss_suspend,
 	.resume		= omap_dss_resume,
 	.driver         = {
-		.name   = "omapdss",
+		.name   = "omap_display",
 		.owner  = THIS_MODULE,
 	},
 };
Signature · 1 line
1.7.1
#6 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Tomi

#7 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

Quoted 15 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

How does this sound:

Quoted 7 lines

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Any comments on this?

Tomi

#8 lore raw

PATCH v10 5/18 OMAP2, 3 DSS2 Change driver name to omap_display

Hi,

Quoted 19 lines · Tomi
Quoted 18 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

Quoted 6 lines
Quoted 4 lines

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Any comments on this?

I also think we need to stick to the older name, "omapdss_dss" sounds a bit confusing, and I think one of the previous versions had something like "dss_dss" in it and it wasn't approved. Does something like "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?

Archit

#9 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

Quoted 27 lines · Archit

Hi,

Quoted 24 lines · Tomi
Quoted 22 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Quoted 6 lines
Quoted 1 line

Any comments on this?

I also think we need to stick to the older name, "omapdss_dss" sounds a bit confusing, and I think one of the previous versions had something like "dss_dss" in it and it wasn't approved. Does something like "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?

It is confusing, but so is the hardware naming =). There is a DSS module inside the omap display subsystem. That's why I would like to name it "dss", not "core", so it's clear it refers to this DSS module.

"dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly better in the sense that it doesn't repeat the same "dss", and there is an "omapdss" device, which acts like "manager" for these module devices. But yes, I wouldn't call it perfect either.

"omapdss_dss_core" is one option. But then again, TRM doesn't speak of "core".

Also, these HW module devices are not used by the userspace, nor any other component inside the kernel than dss. They are quite hidden, and so the naming is not that critical. We can easily change these names later, if needed.

Tomi

#10 lore raw

PATCH v10 5/18 OMAP2, 3 DSS2 Change driver name to omap_display

Hi,

Quoted 39 lines · Tomi
Quoted 27 lines · Archit

Hi,

Quoted 24 lines · Tomi
Quoted 22 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Quoted 6 lines
Quoted 1 line

Any comments on this?

I also think we need to stick to the older name, "omapdss_dss" sounds a bit confusing, and I think one of the previous versions had something like "dss_dss" in it and it wasn't approved. Does something like "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?

It is confusing, but so is the hardware naming =). There is a DSS module inside the omap display subsystem. That's why I would like to name it "dss", not "core", so it's clear it refers to this DSS module.

Quoted 7 lines

"dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly better in the sense that it doesn't repeat the same "dss", and there is an "omapdss" device, which acts like "manager" for these module devices. But yes, I wouldn't call it perfect either.

"omapdss_dss_core" is one option. But then again, TRM doesn't speak of "core".

Yes, it might get misleading if someone looking at the code tries to find "core" in the TRM, I guess we should stick to "omapdss_dss", this also ensures a uniform matching of the platform driver names and the beginning of register names for each HW module.

Archit

#11 lore raw

PATCH v10 5/18 OMAP2, 3 DSS2 Change driver name to omap_display

Hi,

Quoted 10 lines · archit taneja

Hi,

Quoted 7 lines · Tomi
Quoted 5 lines · Archit

Hi,

Quoted 1 line · Tomi

<snip>

Quoted 32 lines
Quoted 32 lines
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines

I just realized that changing the driver name will break all scripts and
applications using omapdss sysfs files.

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS,
and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Quoted 7 lines
Quoted 1 line

Any comments on this?

I also think we need to stick to the older name, "omapdss_dss" sounds a bit confusing, and I think one of the previous versions had something like "dss_dss" in it and it wasn't approved. Does something like "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?

It is confusing, but so is the hardware naming =). There is a DSS module inside the omap display subsystem. That's why I would like to name it "dss", not "core", so it's clear it refers to this DSS module.

"dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly better in the sense that it doesn't repeat the same "dss", and there is an "omapdss" device, which acts like "manager" for these module devices. But yes, I wouldn't call it perfect either.

Quoted 7 lines
Quoted 2 lines

"omapdss_dss_core" is one option. But then again, TRM doesn't speak of "core".

Yes, it might get misleading if someone looking at the code tries to find "core" in the TRM, I guess we should stick to "omapdss_dss", this also ensures a uniform matching of the platform driver names and the beginning of register names for each HW module.

Hmmm... I guess omapdss_dss seems a better name in this view; I'm ok with this way of naming - do you want me to send a patch for it, or would you update this patch itself?
~Sumit.

Quoted 3 lines

Archit

#12 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

Quoted 3 lines · Sumit

Hi,

On Mon, Feb 28, 2011 at 12:57 PM, archit taneja <[email protected]> wrote:

<snip>

Quoted 8 lines
Quoted 4 lines

Yes, it might get misleading if someone looking at the code tries to find "core" in the TRM, I guess we should stick to "omapdss_dss", this also ensures a uniform matching of the platform driver names and the beginning of register names for each HW module.

Hmmm... I guess omapdss_dss seems a better name in this view; I'm ok with this way of naming - do you want me to send a patch for it, or would you update this patch itself?

I've made the change. I changed the commits in my tree according to this new naming. Quite a bit of changes, so I removed tested-bys from the patches. I'll do some more testing, and push the changes to my master branch.

Tomi

#13 lore raw

PATCH v10 5/18 OMAP2, 3 DSS2 Change driver name to omap_display

In reply to Tomi Valkeinen

Hi Tomi,

Quoted 15 lines · Tomi
Quoted 14 lines · Archit

Hi,

Quoted 11 lines · Tomi
Quoted 10 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

This is the case for all the drivers migrated to omap_device anyway due to the change in the top level hierarchy. Everything is below platform/omap now.
That's why we are using that opportunity to clean and provide a consistent naming for all devices.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Cannot you use a device hierarchy then to do that?
omap_dss/core
omap_dss/dsi
omap_dss/venc

This is moreover the way the HW is done.

Quoted 11 lines
Quoted 6 lines
Quoted 1 line

Any comments on this?

I also think we need to stick to the older name, "omapdss_dss" sounds a bit confusing, and I think one of the previous versions had something like "dss_dss" in it and it wasn't approved. Does something like "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?

It is confusing, but so is the hardware naming =). There is a DSS module inside the omap display subsystem. That's why I would like to name it "dss", not "core", so it's clear it refers to this DSS module.

Quoted 7 lines

"dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly better in the sense that it doesn't repeat the same "dss", and there is an "omapdss" device, which acts like "manager" for these module devices. But yes, I wouldn't call it perfect either.

"omapdss_dss_core" is one option. But then again, TRM doesn't speak of "core".

We should not maintain silly names just because they are in the TRM, we should just fix the TRM. This is exactly what we are going to do for most HW names we introduced in OMAP4.

So if we all agree that this name will avoid confusion and is much better than the current one, we can change it right now with a comment to explain the change and give the pointer to the current TRM naming.

Regards,
Benoit

#14 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

Quoted 21 lines · Benoit

Hi Tomi,

Quoted 18 lines · Tomi
Quoted 17 lines · Archit

Hi,

Quoted 14 lines · Tomi
Quoted 13 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

This is the case for all the drivers migrated to omap_device anyway due to the change in the top level hierarchy. Everything is below platform/omap now.

The HW module drivers are under platform/omap/, but omapdss is in platform/. Do you mean that omapdss should also be under platform/omap/?

The reason I'm unwilling to change omapdss name, or location, is that omapdss directory contains lots of DSS configuration files, used by scripts and programs.

Quoted 8 lines

That's why we are using that opportunity to clean and provide a consistent naming for all devices.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Quoted 6 lines

Cannot you use a device hierarchy then to do that?
omap_dss/core
omap_dss/dsi
omap_dss/venc

This is moreover the way the HW is done.

Hmm, how would that work? The devices are platform devices, and they have a unique global name, which is used to match the driver for the device.

Quoted 20 lines
Quoted 12 lines
Quoted 7 lines
Quoted 2 lines

Any comments on this?

I also think we need to stick to the older name, "omapdss_dss" sounds a bit confusing, and I think one of the previous versions had something like "dss_dss" in it and it wasn't approved. Does something like "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?

It is confusing, but so is the hardware naming =). There is a DSS module inside the omap display subsystem. That's why I would like to name it "dss", not "core", so it's clear it refers to this DSS module.

Quoted 7 lines

"dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly better in the sense that it doesn't repeat the same "dss", and there is an "omapdss" device, which acts like "manager" for these module devices. But yes, I wouldn't call it perfect either.

"omapdss_dss_core" is one option. But then again, TRM doesn't speak of "core".

Quoted 7 lines

We should not maintain silly names just because they are in the TRM, we should just fix the TRM. This is exactly what we are going to do for most HW names we introduced in OMAP4.

So if we all agree that this name will avoid confusion and is much better than the current one, we can change it right now with a comment to explain the change and give the pointer to the current TRM naming.

True. But I don't think there's a huge difference with omapdss_dss or omapdss_core.

The name is used in only a few places inside the kernel, and never from userspace, so we can change that also later.

The main issue I had was changing the omapdss device name, which would break the userspace.

Tomi

#15 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

Quoted 11 lines · Tomi Valkeinen
Quoted 6 lines · Benoit

Cannot you use a device hierarchy then to do that?
omap_dss/core
omap_dss/dsi
omap_dss/venc

This is moreover the way the HW is done.

Hmm, how would that work? The devices are platform devices, and they have a unique global name, which is used to match the driver for the device.

And not forgetting that '/' is not permitted in device or driver names.

#16 lore raw

PATCH v10 5/18 OMAP2, 3 DSS2 Change driver name to omap_display

Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Tomi Valkeinen
Quoted 5 lines · Benoit

Cannot you use a device hierarchy then to do that?
omap_dss/core
omap_dss/dsi
omap_dss/venc

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

This is moreover the way the HW is done.

Hmm, how would that work? The devices are platform devices, and they have a unique global name, which is used to match the driver for the device.

And not forgetting that '/' is not permitted in device or driver names.

I was not really considering naming the device with a '/'. The idea is that the devices will not longer be flat platform devices but something like dss devices that will have have a omap_dss parent.

I do not know if that makes sense to store some kind of hierarchy in the device model, but encoding the hierarchy in the name like it is proposed looks like a hack to me. The point is that the dsi instances might potentially be in another part of the SoC. Having the device name based on the hierarchy will not allow the driver to bind the device properly.

Please note, that I'm not really sure it is doable with the current device model, hence the original question.

Benoit

#17 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

Quoted 16 lines · Benoit
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Tomi Valkeinen
Quoted 5 lines · Benoit

Cannot you use a device hierarchy then to do that?
omap_dss/core
omap_dss/dsi
omap_dss/venc

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

This is moreover the way the HW is done.

Hmm, how would that work? The devices are platform devices, and they have a unique global name, which is used to match the driver for the device.

And not forgetting that '/' is not permitted in device or driver names.

Quoted 7 lines

I was not really considering naming the device with a '/'. The idea is that the devices will not longer be flat platform devices but something like dss devices that will have have a omap_dss parent.

I do not know if that makes sense to store some kind of hierarchy in the device model, but encoding the hierarchy in the name like it is proposed looks like a hack to me.

Try:

tree -d /sys/devices/pci0000\:00

on your PC, taking special note of how pci-to-pci bridges are handled.

#18 lore raw

PATCH v10 5/18 OMAP2, 3 DSS2 Change driver name to omap_display

Quoted 25 lines · Russell King - ARM Linux
Quoted 16 lines · Benoit
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Tomi Valkeinen
Quoted 5 lines · Benoit

Cannot you use a device hierarchy then to do that?
omap_dss/core
omap_dss/dsi
omap_dss/venc

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

This is moreover the way the HW is done.

Hmm, how would that work? The devices are platform devices, and they have a unique global name, which is used to match the driver for the device.

And not forgetting that '/' is not permitted in device or driver names.

Quoted 7 lines

I was not really considering naming the device with a '/'. The idea is that the devices will not longer be flat platform devices but something like dss devices that will have have a omap_dss parent.

I do not know if that makes sense to store some kind of hierarchy in the device model, but encoding the hierarchy in the name like it is proposed looks like a hack to me.

Quoted 5 lines

Try:

tree -d /sys/devices/pci0000\:00

on your PC, taking special note of how pci-to-pci bridges are handled.

Here it is, but I'm not sure to understand how it is really done :-(

/sys/devices/pci0000:00
??? 0000:00:00.0

?   ??? firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:00
?   ??? power
?   ??? subsystem -> ../../../bus/pci
??? 0000:00:02.0
?   ??? 0000:00:02.0:pcie01
?   ?   ??? power
?   ?   ??? subsystem -> ../../../../bus/pci_express
?   ??? 0000:00:02.0:pcie02
?   ?   ??? driver -> ../../../../bus/pci_express/drivers/aer
?   ?   ??? power
?   ?   ??? subsystem -> ../../../../bus/pci_express
?   ??? 0000:06:00.0
?   ?   ??? 0000:06:00.0:pcie12
?   ?   ?   ??? power
?   ?   ?   ??? subsystem -> ../../../../../bus/pci_express
?   ?   ??? 0000:07:00.0
?   ?   ?   ??? 0000:07:00.0:pcie22
?   ?   ?   ?   ??? power
?   ?   ?   ?   ??? subsystem -> ../../../../../../bus/pci_express
?   ?   ?   ??? 0000:08:00.0
?   ?   ?   ?   ??? 0000:09:00.0
?   ?   ?   ?   ?   ??? driver -> ../../../../../../../bus/pci/drivers/bnx2
?   ?   ?   ?   ?   ??? net
?   ?   ?   ?   ?   ?   ??? eth1
?   ?   ?   ?   ?   ?       ??? device -> ../../../0000:09:00.0
?   ?   ?   ?   ?   ?       ??? power
?   ?   ?   ?   ?   ?       ??? statistics
?   ?   ?   ?   ?   ?       ??? subsystem -> ../../../../../../../../../class/net
?   ?   ?   ?   ?   ??? power
?   ?   ?   ?   ?   ??? subsystem -> ../../../../../../../bus/pci
?   ?   ?   ?   ??? pci_bus
?   ?   ?   ?   ?   ??? 0000:09
?   ?   ?   ?   ?       ??? device -> ../../../0000:08:00.0
?   ?   ?   ?   ?       ??? power
?   ?   ?   ?   ?       ??? subsystem -> ../../../../../../../../class/pci_bus
?   ?   ?   ?   ??? power
?   ?   ?   ?   ??? subsystem -> ../../../../../../bus/pci
?   ?   ?   ??? driver -> ../../../../../bus/pci/drivers/pcieport
?   ?   ?   ??? pci_bus
?   ?   ?   ?   ??? 0000:08
?   ?   ?   ?       ??? device -> ../../../0000:07:00.0
?   ?   ?   ?       ??? power
?   ?   ?   ?       ??? subsystem -> ../../../../../../../class/pci_bus
?   ?   ?   ??? power
?   ?   ?   ??? subsystem -> ../../../../../bus/pci

...

#19 lore raw

PATCH v10 5/18 OMAP2, 3 DSS2 Change driver name to omap_display

In reply to Tomi Valkeinen
Quoted 27 lines · Tomi
Quoted 26 lines · Benoit

Hi Tomi,

Quoted 22 lines · Tomi
Quoted 21 lines · Archit

Hi,

Quoted 18 lines · Tomi
Quoted 17 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

Quoted 6 lines
Quoted 3 lines

This is the case for all the drivers migrated to omap_device anyway due to the change in the top level hierarchy. Everything is below platform/omap now.

The HW module drivers are under platform/omap/, but omapdss is in platform/. Do you mean that omapdss should also be under platform/omap/?

This is because you are probably not using omap_device yet. is should happen when you will change your platform_device to be omap_device.

Quoted 3 lines

The reason I'm unwilling to change omapdss name, or location, is that omapdss directory contains lots of DSS configuration files, used by scripts and programs.

Is that used for debug only?

Quoted 13 lines
Quoted 13 lines

That's why we are using that opportunity to clean and provide a consistent naming for all devices.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, "dsi" block in some other HW component.

Cannot you use a device hierarchy then to do that?
omap_dss/core
omap_dss/dsi
omap_dss/venc

Quoted 5 lines
Quoted 1 line

This is moreover the way the HW is done.

Hmm, how would that work? The devices are platform devices, and they have a unique global name, which is used to match the driver for the device.

Practically, I don't really know :-) Please see the reply to Russell.

Quoted 23 lines
Quoted 23 lines
Quoted 11 lines
Quoted 6 lines
Quoted 1 line

Any comments on this?

I also think we need to stick to the older name, "omapdss_dss" sounds a bit confusing, and I think one of the previous versions had something like "dss_dss" in it and it wasn't approved. Does something like "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?

It is confusing, but so is the hardware naming =). There is a DSS module inside the omap display subsystem. That's why I would like to name it "dss", not "core", so it's clear it refers to this DSS module.

Quoted 7 lines

"dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly better in the sense that it doesn't repeat the same "dss", and there is an "omapdss" device, which acts like "manager" for these module devices. But yes, I wouldn't call it perfect either.

"omapdss_dss_core" is one option. But then again, TRM doesn't speak of "core".

We should not maintain silly names just because they are in the TRM, we should just fix the TRM. This is exactly what we are going to do for most HW names we introduced in OMAP4.

Quoted 6 lines
Quoted 3 lines

So if we all agree that this name will avoid confusion and is much better than the current one, we can change it right now with a comment to explain the change and give the pointer to the current TRM naming.

True. But I don't think there's a huge difference with omapdss_dss or omapdss_core.

You're right, at the end it is just a name. We are just trying to clean a little bit the current devices name mess. So the convention we are trying to enforce is to name omap devices omap_XXX.

Quoted 5 lines

The name is used in only a few places inside the kernel, and never from userspace, so we can change that also later.

The main issue I had was changing the omapdss device name, which would break the userspace.

That's why we'd better break it properly today once and for all :-) At least when you will migrate to omap_device.

Benoit

#20 lore raw

PATCH v10 5/18 OMAP2,3 DSS2 Change driver name to omap_display

Quoted 32 lines · Benoit
Quoted 31 lines · Tomi
Quoted 29 lines · Benoit

Hi Tomi,

Quoted 15 lines · Tomi
Quoted 14 lines · Archit

Hi,

Quoted 11 lines · Tomi
Quoted 10 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

This is the case for all the drivers migrated to omap_device anyway due to the change in the top level hierarchy. Everything is below platform/omap now.

Quoted 5 lines
Quoted 2 lines

The HW module drivers are under platform/omap/, but omapdss is in platform/. Do you mean that omapdss should also be under platform/omap/?

This is because you are probably not using omap_device yet. is should happen when you will change your platform_device to be omap_device.

Hmm. The HW module devices use omap_device. But we have also a "management" device, omapdss, which is doesn't match directly to any HW component but manages the HW module drivers. It contains, so to say, the HW module drivers.

Should this device also be a omap_device? What does omap_device actually represent? My understanding is that omap_device is a linux device for a HW block inside OMAP. omapdss doesn't quite match that definition.

Quoted 5 lines
Quoted 3 lines

The reason I'm unwilling to change omapdss name, or location, is that omapdss directory contains lots of DSS configuration files, used by scripts and programs.

Is that used for debug only?

Unfortunately no. DSS contains many features which cannot be exported to userspace via the framebuffer device. While I'm not really happy with the current omapdss sysfs interface, it's the best we've come up with.

Tomi

#21 lore raw

PATCH v10 5/18 OMAP2, 3 DSS2 Change driver name to omap_display

Quoted 36 lines · Tomi
Quoted 35 lines · Benoit
Quoted 33 lines · Tomi
Quoted 21 lines · Benoit

Hi Tomi,

Quoted 18 lines · Tomi
Quoted 17 lines · Archit

Hi,

Quoted 14 lines · Tomi
Quoted 13 lines · Tomi Valkeinen

Hi,

Quoted 6 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

Change the driver name from omapdss to omap_display as the driver takes care of the display devices ie number of panels, type of panels available in the platform. Change the device name in the board files and 2420,2430,3xxx clock files from omapdss to omap_display to match the driver name.

I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files.

Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

How does this sound:

Let's leave the omapdss device name as it is. It represents a "super" device, containing the dss sysfs files and upper level dss management.

This is the case for all the drivers migrated to omap_device anyway due to the change in the top level hierarchy. Everything is below platform/omap now.

The HW module drivers are under platform/omap/, but omapdss is in platform/. Do you mean that omapdss should also be under platform/omap/?

Quoted 7 lines
Quoted 2 lines

This is because you are probably not using omap_device yet. is should happen when you will change your platform_device to be omap_device.

Hmm. The HW module devices use omap_device. But we have also a "management" device, omapdss, which is doesn't match directly to any HW component but manages the HW module drivers. It contains, so to say, the HW module drivers.

OK, so you will have two different paths. omapdss will be directly below platform whereas all the omap_device based DSS IPs will be below platform/omap.

Quoted 3 lines

Should this device also be a omap_device? What does omap_device actually represent? My understanding is that omap_device is a linux device for a HW block inside OMAP. omapdss doesn't quite match that definition.

Yep, in that case you do not need an omap_device since you do not have any hwmod to map to.
The only weird thing is the different root paths you will have for the various devices. But it looks like the only one you have to expose is the omapdss.

Quoted 9 lines
Quoted 5 lines
Quoted 3 lines

The reason I'm unwilling to change omapdss name, or location, is that omapdss directory contains lots of DSS configuration files, used by scripts and programs.

Is that used for debug only?

Unfortunately no. DSS contains many features which cannot be exported to userspace via the framebuffer device. While I'm not really happy with the current omapdss sysfs interface, it's the best we've come up with.

OK, then, something you will be able to fix in the DSS3:-)

Benoit

#22 lore raw

PATCH v10 6/18 OMAP2,3 DSS2 Use Regulator init with driver name

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Use driver name in regulator inits needed for display instead of using device structure name.

---
 arch/arm/mach-omap2/board-3430sdp.c      |   11 +++--------
 arch/arm/mach-omap2/board-cm-t35.c       |   12 ++++--------
 arch/arm/mach-omap2/board-igep0020.c     |    6 ++----
 arch/arm/mach-omap2/board-omap3evm.c     |    6 ++----
 arch/arm/mach-omap2/board-omap3stalker.c |   12 ++++--------
 5 files changed, 15 insertions(+), 32 deletions(-)
arch/arm/mach-omap2/board-3430sdp.c +3 -8
index 6f4e7cf..d99902c 100644
@@ -315,10 +315,8 @@ static struct platform_device sdp3430_dss_device = {
 	},
 };
 
-static struct regulator_consumer_supply sdp3430_vdda_dac_supply = {
-	.supply		= "vdda_dac",
-	.dev		= &sdp3430_dss_device.dev,
-};
+static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
+	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
 static struct platform_device *sdp3430_devices[] __initdata = {
 	&sdp3430_dss_device,
@@ -546,10 +544,7 @@ static struct regulator_init_data sdp3430_vdac = {
 
 /* VPLL2 for digital video outputs */
 static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
-	{
-		.supply		= "vdds_dsi",
-		.dev		= &sdp3430_dss_device.dev,
-	}
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
 };
 
 static struct regulator_init_data sdp3430_vpll2 = {
arch/arm/mach-omap2/board-cm-t35.c +4 -8
index 79f87ec..22322d1 100644
@@ -495,15 +495,11 @@ static struct regulator_consumer_supply cm_t35_vsim_supply = {
 	.supply			= "vmmc_aux",
 };
 
-static struct regulator_consumer_supply cm_t35_vdac_supply = {
-	.supply		= "vdda_dac",
-	.dev		= &cm_t35_dss_device.dev,
-};
+static struct regulator_consumer_supply cm_t35_vdac_supply =
+	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
-static struct regulator_consumer_supply cm_t35_vdvi_supply = {
-	.supply		= "vdvi",
-	.dev		= &cm_t35_dss_device.dev,
-};
+static struct regulator_consumer_supply cm_t35_vdvi_supply =
+	REGULATOR_SUPPLY("vdvi", "omap_display");
 
 /* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
 static struct regulator_init_data cm_t35_vmmc1 = {
arch/arm/mach-omap2/board-igep0020.c +2 -4
index 23abfa3..238c69e 100644
@@ -493,10 +493,8 @@ static struct platform_device igep2_dss_device = {
 	},
 };
 
-static struct regulator_consumer_supply igep2_vpll2_supply = {
-	.supply	= "vdds_dsi",
-	.dev	= &igep2_dss_device.dev,
-};
+static struct regulator_consumer_supply igep2_vpll2_supply =
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
 
 static struct regulator_init_data igep2_vpll2 = {
 	.constraints = {
arch/arm/mach-omap2/board-omap3evm.c +2 -4
index 4ad3c4d..32ac816 100644
@@ -500,10 +500,8 @@ static struct twl4030_codec_data omap3evm_codec_data = {
 	.audio = &omap3evm_audio_data,
 };
 
-static struct regulator_consumer_supply omap3_evm_vdda_dac_supply = {
-	.supply		= "vdda_dac",
-	.dev		= &omap3_evm_dss_device.dev,
-};
+static struct regulator_consumer_supply omap3_evm_vdda_dac_supply =
+	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
 /* VDAC for DSS driving S-Video */
 static struct regulator_init_data omap3_evm_vdac = {
arch/arm/mach-omap2/board-omap3stalker.c +4 -8
index 51c010c..7b675cb 100644
@@ -448,10 +448,8 @@ static struct twl4030_codec_data omap3stalker_codec_data = {
 	.audio		= &omap3stalker_audio_data,
 };
 
-static struct regulator_consumer_supply omap3_stalker_vdda_dac_supply = {
-	.supply		= "vdda_dac",
-	.dev		= &omap3_stalker_dss_device.dev,
-};
+static struct regulator_consumer_supply omap3_stalker_vdda_dac_supply =
+	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
 /* VDAC for DSS driving S-Video */
 static struct regulator_init_data omap3_stalker_vdac = {
@@ -469,10 +467,8 @@ static struct regulator_init_data omap3_stalker_vdac = {
 };
 
 /* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_stalker_vpll2_supply = {
-	.supply		= "vdds_dsi",
-	.dev		= &omap3_stalker_lcd_device.dev,
-};
+static struct regulator_consumer_supply omap3_stalker_vpll2_supply =
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
 
 static struct regulator_init_data omap3_stalker_vpll2 = {
 	.constraints		= {
Signature · 1 line
1.7.1
#23 lore raw

PATCH v10 7/18 OMAP2, 3: DSS2: Create new file display.c for central dss driver registration.

In reply to Sumit Semwal

A new file display.c is introduced for display driver init, which adds a function omap_display_init to do the DSS driver registration. This is the first step in moving away registration of DSS from board files into a common place.

---
 arch/arm/mach-omap2/Makefile              |    3 ++
 arch/arm/mach-omap2/display.c             |   46 +++++++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/display.h |   11 +++++++
 3 files changed, 60 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/display.c
arch/arm/mach-omap2/Makefile +3 -0
index 1c0c2b0..2e81173 100644
@@ -242,3 +242,6 @@ obj-y					+= $(smc91x-m) $(smc91x-y)
 
 smsc911x-$(CONFIG_SMSC911X)		:= gpmc-smsc911x.o
 obj-y					+= $(smsc911x-m) $(smsc911x-y)
+
+disp-$(CONFIG_OMAP2_DSS)		:= display.o
+obj-y					+= $(disp-m) $(disp-y)
arch/arm/mach-omap2/display.c new file +46 -0

46 lines not on this page · raw message

arch/arm/plat-omap/include/plat/display.h +11 -0
index 537f4e4..0f140ec 100644
@@ -23,6 +23,7 @@
 #include <linux/list.h>
 #include <linux/kobject.h>
 #include <linux/device.h>
+#include <linux/platform_device.h>
 #include <asm/atomic.h>
 
 #define DISPC_IRQ_FRAMEDONE		(1 << 0)
@@ -226,6 +227,16 @@ struct omap_dss_board_info {
 	struct omap_dss_device *default_device;
 };
 
+#if defined(CONFIG_OMAP2_DSS_MODULE) || defined(CONFIG_OMAP2_DSS)
+/* Init with the board info */
+extern int omap_display_init(struct omap_dss_board_info *board_data);
+#else
+static inline int omap_display_init(struct omap_dss_board_info *board_data)
+{
+	return 0;
+}
+#endif
+
 struct omap_video_timings {
 	/* Unit: pixels */
 	u16 x_res;
Signature · 1 line
1.7.1
#24 lore raw

PATCH v10 8/18 OMAP2, 3: DSS2: board files: replace platform_device_register with omap_display_init()

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

This patch updated board files to replace platform_device_register or platform_add_devices of DSS with omap_display_init(). This moves away registration of DSS from board files into a common place.

---
 arch/arm/mach-omap2/board-3430sdp.c      |   14 +-------------
 arch/arm/mach-omap2/board-am3517evm.c    |   16 +---------------
 arch/arm/mach-omap2/board-cm-t35.c       |   10 +---------
 arch/arm/mach-omap2/board-devkit8000.c   |   10 +---------
 arch/arm/mach-omap2/board-igep0020.c     |   10 +---------
 arch/arm/mach-omap2/board-omap3beagle.c  |   10 +---------
 arch/arm/mach-omap2/board-omap3evm.c     |   14 +-------------
 arch/arm/mach-omap2/board-omap3pandora.c |   10 +---------
 arch/arm/mach-omap2/board-omap3stalker.c |   10 +---------
 arch/arm/mach-omap2/board-rx51-video.c   |   15 +--------------
 arch/arm/mach-omap2/board-zoom-display.c |   15 +--------------
 11 files changed, 11 insertions(+), 123 deletions(-)
arch/arm/mach-omap2/board-3430sdp.c +1 -13
index d99902c..d00f356 100644
@@ -307,21 +307,9 @@ static struct omap_dss_board_info sdp3430_dss_data = {
 	.default_device	= &sdp3430_lcd_device,
 };
 
-static struct platform_device sdp3430_dss_device = {
-	.name		= "omap_display",
-	.id		= -1,
-	.dev		= {
-		.platform_data = &sdp3430_dss_data,
-	},
-};
-
 static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
 	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
-static struct platform_device *sdp3430_devices[] __initdata = {
-	&sdp3430_dss_device,
-};
-
 static struct omap_board_config_kernel sdp3430_config[] __initdata = {
 };
 
@@ -796,7 +784,7 @@ static void __init omap_3430sdp_init(void)
 {
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	omap3430_i2c_init();
-	platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+	omap_display_init(&sdp3430_dss_data);
 	if (omap_rev() > OMAP3430_REV_ES1_0)
 		ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
 	else
arch/arm/mach-omap2/board-am3517evm.c +1 -15
index 6bb5f53..548f524 100644
@@ -378,24 +378,12 @@ static struct omap_dss_board_info am3517_evm_dss_data = {
 	.default_device	= &am3517_evm_lcd_device,
 };
 
-static struct platform_device am3517_evm_dss_device = {
-	.name		= "omap_display",
-	.id		= -1,
-	.dev		= {
-		.platform_data	= &am3517_evm_dss_data,
-	},
-};
-
 /*
  * Board initialization
  */
 static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
 };
 
-static struct platform_device *am3517_evm_devices[] __initdata = {
-	&am3517_evm_dss_device,
-};
-
 static void __init am3517_evm_init_irq(void)
 {
 	omap_board_config = am3517_evm_config;
@@ -495,9 +483,7 @@ static void __init am3517_evm_init(void)
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 
 	am3517_evm_i2c_init();
-	platform_add_devices(am3517_evm_devices,
-				ARRAY_SIZE(am3517_evm_devices));
-
+	omap_display_init(&am3517_evm_dss_data);
 	omap_serial_init();
 
 	/* Configure GPIO for EHCI port */
arch/arm/mach-omap2/board-cm-t35.c +1 -9
index 22322d1..1c36ec8 100644
@@ -401,14 +401,6 @@ static struct omap_dss_board_info cm_t35_dss_data = {
 	.default_device	= &cm_t35_dvi_device,
 };
 
-static struct platform_device cm_t35_dss_device = {
-	.name		= "omap_display",
-	.id		= -1,
-	.dev		= {
-		.platform_data = &cm_t35_dss_data,
-	},
-};
-
 static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
 	.turbo_mode	= 0,
 	.single_channel	= 1,	/* 0: slave, 1: master */
@@ -468,7 +460,7 @@ static void __init cm_t35_init_display(void)
 	msleep(50);
 	gpio_set_value(lcd_en_gpio, 1);
 
-	err = platform_device_register(&cm_t35_dss_device);
+	err = omap_display_init(&cm_t35_dss_data);
 	if (err) {
 		pr_err("CM-T35: failed to register DSS device\n");
 		goto err_dev_reg;
arch/arm/mach-omap2/board-devkit8000.c +1 -9
index ca8e1b1..6a2eb49 100644
@@ -198,14 +198,6 @@ static struct omap_dss_board_info devkit8000_dss_data = {
 	.default_device = &devkit8000_lcd_device,
 };
 
-static struct platform_device devkit8000_dss_device = {
-	.name		= "omap_display",
-	.id		= -1,
-	.dev		= {
-		.platform_data = &devkit8000_dss_data,
-	},
-};
-
 static struct regulator_consumer_supply devkit8000_vdda_dac_supply =
 	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
@@ -571,7 +563,6 @@ static void __init omap_dm9000_init(void)
 }
 
 static struct platform_device *devkit8000_devices[] __initdata = {
-	&devkit8000_dss_device,
 	&leds_gpio,
 	&keys_gpio,
 	&omap_dm9000_dev,
@@ -793,6 +784,7 @@ static void __init devkit8000_init(void)
 	platform_add_devices(devkit8000_devices,
 			ARRAY_SIZE(devkit8000_devices));
 
+	omap_display_init(&devkit8000_dss_data);
 	spi_register_board_info(devkit8000_spi_board_info,
 	ARRAY_SIZE(devkit8000_spi_board_info));
 
arch/arm/mach-omap2/board-igep0020.c +1 -9
index 238c69e..d79dcd5 100644
@@ -485,14 +485,6 @@ static struct omap_dss_board_info igep2_dss_data = {
 	.default_device	= &igep2_dvi_device,
 };
 
-static struct platform_device igep2_dss_device = {
-	.name	= "omap_display",
-	.id	= -1,
-	.dev	= {
-		.platform_data = &igep2_dss_data,
-	},
-};
-
 static struct regulator_consumer_supply igep2_vpll2_supply =
 	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
 
@@ -519,7 +511,6 @@ static void __init igep2_display_init(void)
 }
 
 static struct platform_device *igep2_devices[] __initdata = {
-	&igep2_dss_device,
 	&igep2_vwlan_device,
 };
 
@@ -695,6 +686,7 @@ static void __init igep2_init(void)
 	/* Register I2C busses and drivers */
 	igep2_i2c_init();
 	platform_add_devices(igep2_devices, ARRAY_SIZE(igep2_devices));
+	omap_display_init(&igep2_dss_data);
 	omap_serial_init();
 	usb_musb_init(&musb_board_data);
 	usb_ehci_init(&ehci_pdata);
arch/arm/mach-omap2/board-omap3beagle.c +1 -9
index fd6b4b8..c0a5066 100644
@@ -228,14 +228,6 @@ static struct omap_dss_board_info beagle_dss_data = {
 	.default_device = &beagle_dvi_device,
 };
 
-static struct platform_device beagle_dss_device = {
-	.name          = "omap_display",
-	.id            = -1,
-	.dev            = {
-		.platform_data = &beagle_dss_data,
-	},
-};
-
 static struct regulator_consumer_supply beagle_vdac_supply =
 	REGULATOR_SUPPLY("vdda_dac", "omap_display");
 
@@ -550,7 +542,6 @@ static void __init omap3_beagle_init_irq(void)
 static struct platform_device *omap3_beagle_devices[] __initdata = {
 	&leds_gpio,
 	&keys_gpio,
-	&beagle_dss_device,
 };
 
 static void __init omap3beagle_flash_init(void)
@@ -617,6 +608,7 @@ static void __init omap3_beagle_init(void)
 	omap3_beagle_i2c_init();
 	platform_add_devices(omap3_beagle_devices,
 			ARRAY_SIZE(omap3_beagle_devices));
+	omap_display_init(&beagle_dss_data);
 	omap_serial_init();
 
 	omap_mux_init_gpio(170, OMAP_PIN_INPUT);
arch/arm/mach-omap2/board-omap3evm.c +1 -13
index 32ac816..5f156fe 100644
@@ -328,14 +328,6 @@ static struct omap_dss_board_info omap3_evm_dss_data = {
 	.default_device	= &omap3_evm_lcd_device,
 };
 
-static struct platform_device omap3_evm_dss_device = {
-	.name		= "omap_display",
-	.id		= -1,
-	.dev		= {
-		.platform_data = &omap3_evm_dss_data,
-	},
-};
-
 static struct regulator_consumer_supply omap3evm_vmmc1_supply = {
 	.supply			= "vmmc",
 };
@@ -632,10 +624,6 @@ static void __init omap3_evm_init_irq(void)
 	omap_init_irq();
 }
 
-static struct platform_device *omap3_evm_devices[] __initdata = {
-	&omap3_evm_dss_device,
-};
-
 static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
 
 	.port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
@@ -673,7 +661,7 @@ static void __init omap3_evm_init(void)
 
 	omap3_evm_i2c_init();
 
-	platform_add_devices(omap3_evm_devices, ARRAY_SIZE(omap3_evm_devices));
+	omap_display_init(&omap3_evm_dss_data);
 
 	spi_register_board_info(omap3evm_spi_board_info,
 				ARRAY_SIZE(omap3evm_spi_board_info));
arch/arm/mach-omap2/board-omap3pandora.c +1 -9
index 9e8faf2..613ab58 100644
@@ -253,14 +253,6 @@ static struct omap_dss_board_info pandora_dss_data = {
 	.default_device	= &pandora_lcd_device,
 };
 
-static struct platform_device pandora_dss_device = {
-	.name		= "omap_display",
-	.id		= -1,
-	.dev		= {
-		.platform_data = &pandora_dss_data,
-	},
-};
-
 static void pandora_wl1251_init_card(struct mmc_card *card)
 {
 	/*
@@ -677,7 +669,6 @@ fail:
 static struct platform_device *omap3pandora_devices[] __initdata = {
 	&pandora_leds_gpio,
 	&pandora_keys_gpio,
-	&pandora_dss_device,
 	&pandora_vwlan_device,
 };
 
@@ -712,6 +703,7 @@ static void __init omap3pandora_init(void)
 	pandora_wl1251_init();
 	platform_add_devices(omap3pandora_devices,
 			ARRAY_SIZE(omap3pandora_devices));
+	omap_display_init(&pandora_dss_data);
 	omap_serial_init();
 	spi_register_board_info(omap3pandora_spi_board_info,
 			ARRAY_SIZE(omap3pandora_spi_board_info));
arch/arm/mach-omap2/board-omap3stalker.c +1 -9
index 7b675cb..7671218 100644
@@ -240,14 +240,6 @@ static struct omap_dss_board_info omap3_stalker_dss_data = {
 	.default_device	= &omap3_stalker_dvi_device,
 };
 
-static struct platform_device omap3_stalker_dss_device = {
-	.name	= "omap_display",
-	.id	= -1,
-	.dev	= {
-		.platform_data	= &omap3_stalker_dss_data,
-	},
-};
-
 static struct regulator_consumer_supply omap3stalker_vmmc1_supply = {
 	.supply		= "vmmc",
 };
@@ -600,7 +592,6 @@ static void __init omap3_stalker_init_irq(void)
 }
 
 static struct platform_device *omap3_stalker_devices[] __initdata = {
-	&omap3_stalker_dss_device,
 	&keys_gpio,
 };
 
@@ -640,6 +631,7 @@ static void __init omap3_stalker_init(void)
 	platform_add_devices(omap3_stalker_devices,
 			     ARRAY_SIZE(omap3_stalker_devices));
 
+	omap_display_init(&omap3_stalker_dss_data);
 	spi_register_board_info(omap3stalker_spi_board_info,
 				ARRAY_SIZE(omap3stalker_spi_board_info));
 
arch/arm/mach-omap2/board-rx51-video.c +1 -14
index 8140d05..89a66db 100644
@@ -66,18 +66,6 @@ static struct omap_dss_board_info rx51_dss_board_info = {
 	.default_device	= &rx51_lcd_device,
 };
 
-struct platform_device rx51_display_device = {
-	.name	= "omap_display",
-	.id	= -1,
-	.dev	= {
-		.platform_data = &rx51_dss_board_info,
-	},
-};
-
-static struct platform_device *rx51_video_devices[] __initdata = {
-	&rx51_display_device,
-};
-
 static int __init rx51_video_init(void)
 {
 	if (!machine_is_nokia_rx51())
@@ -95,8 +83,7 @@ static int __init rx51_video_init(void)
 
 	gpio_direction_output(RX51_LCD_RESET_GPIO, 1);
 
-	platform_add_devices(rx51_video_devices,
-				ARRAY_SIZE(rx51_video_devices));
+	omap_display_init(&rx51_dss_board_info);
 	return 0;
 }
 
arch/arm/mach-omap2/board-zoom-display.c +1 -14
index d6b949d..37b84c2 100644
@@ -130,14 +130,6 @@ static struct omap_dss_board_info zoom_dss_data = {
 	.default_device		= &zoom_lcd_device,
 };
 
-static struct platform_device zoom_dss_device = {
-	.name				= "omap_display",
-	.id				= -1,
-	.dev				= {
-		.platform_data		= &zoom_dss_data,
-	},
-};
-
 static struct omap2_mcspi_device_config dss_lcd_mcspi_config = {
 	.turbo_mode		= 1,
 	.single_channel	= 1,  /* 0: slave, 1: master */
@@ -153,14 +145,9 @@ static struct spi_board_info nec_8048_spi_board_info[] __initdata = {
 	},
 };
 
-static struct platform_device *zoom_display_devices[] __initdata = {
-	&zoom_dss_device,
-};
-
 void __init zoom_display_init(void)
 {
-	platform_add_devices(zoom_display_devices,
-				ARRAY_SIZE(zoom_display_devices));
+	omap_display_init(&zoom_dss_data);
 	spi_register_board_info(nec_8048_spi_board_info,
 				ARRAY_SIZE(nec_8048_spi_board_info));
 	zoom_lcd_panel_init();
Signature · 1 line
1.7.1
#25 lore raw

PATCH v10 9/18 OMAP2,3: DSS2: Build omap_device for each DSS HWIP

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Looks up the hwmod database for each of the given DSS HW IP and builds omap_device which inturn does the platform device register for each of DSS HW IP

---
 arch/arm/mach-omap2/display.c             |   50 +++++++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/display.h |    5 +++
 2 files changed, 55 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/display.c +50 -0
index 6e21cb8..5c0a78b 100644
@@ -23,6 +23,8 @@
 #include <linux/err.h>
 
 #include <plat/display.h>
+#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
 
 static struct platform_device omap_display_device = {
 	.name          = "omap_display",
@@ -32,10 +34,58 @@ static struct platform_device omap_display_device = {
 	},
 };
 
+static struct omap_device_pm_latency omap_dss_latency[] = {
+	[0] = {
+		.deactivate_func        = omap_device_idle_hwmods,
+		.activate_func          = omap_device_enable_hwmods,
+		.flags			= OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+	},
+};
+
 int __init omap_display_init(struct omap_dss_board_info
 					*board_data)
 {
 	int r = 0;
+	struct omap_hwmod *oh;
+	struct omap_device *od;
+	int i;
+	struct omap_display_platform_data pdata;
+
+	/*
+	 * omap: valid DSS hwmod names
+	 * omap2,3: dss_core, dss_dispc, dss_rfbi, dss_venc
+	 * omap3: dss_dsi1
+	 */
+	char *oh_name[] = {"dss_core", "dss_dispc", "dss_rfbi", "dss_venc", "dss_dsi1"};
+	char *dev_name[] = { "omap_dss", "omap_dispc", "omap_rfbi", "omap_venc", "omap_dsi1" };
+	int oh_count;
+
+	memset(&pdata, 0, sizeof(pdata));
+
+	if (cpu_is_omap24xx())
+		oh_count = ARRAY_SIZE(oh_name) - 1;
+		/* last hwmod dev in oh_name is not available for omap2 */
+	else
+		oh_count = ARRAY_SIZE(oh_name);
+
+	pdata.board_data = board_data;
+	pdata.board_data->get_last_off_on_transaction_id = NULL;
+
+	for (i = 0; i < oh_count; i++) {
+		oh = omap_hwmod_lookup(oh_name[i]);
+		if (!oh) {
+			pr_err("Could not look up %s\n", oh_name[i]);
+			return -ENODEV;
+		}
+		od = omap_device_build(dev_name[i], -1, oh, &pdata,
+				sizeof(struct omap_display_platform_data),
+				omap_dss_latency,
+				ARRAY_SIZE(omap_dss_latency), 0);
+
+		if (WARN((IS_ERR(od)), "Could not build omap_device for %s\n",
+				oh_name[i]))
+			return -ENODEV;
+	}
 	omap_display_device.dev.platform_data = board_data;
 
 	r = platform_device_register(&omap_display_device);
arch/arm/plat-omap/include/plat/display.h +5 -0
index 0f140ec..2fb057e 100644
@@ -237,6 +237,11 @@ static inline int omap_display_init(struct omap_dss_board_info *board_data)
 }
 #endif
 
+struct omap_display_platform_data {
+	struct omap_dss_board_info *board_data;
+	/* TODO: Additional members to be added when PM is considered */
+};
+
 struct omap_video_timings {
 	/* Unit: pixels */
 	u16 x_res;
Signature · 1 line
1.7.1
#26 lore raw

PATCH v10 10/18 OMAP2, 3: DSS2: DSS: create platform_driver, move init, exit to driver

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So a platform_driver of DSS is created and init exit methods are moved from core.c to its driver probe,remove. pdev member has to be maintained by its own drivers.

DSS platform driver is registered from inside omap_dss_probe, in the order desired.

---
 drivers/video/omap2/dss/core.c |   19 ++++++-------
 drivers/video/omap2/dss/dss.c  |   55 ++++++++++++++++++++++++++++++++++++++-
 drivers/video/omap2/dss/dss.h  |    4 +-
 3 files changed, 64 insertions(+), 14 deletions(-)
drivers/video/omap2/dss/core.c +9 -10
index 1bbc004..1aace9e 100644
@@ -517,15 +517,9 @@ static int omap_dss_probe(struct platform_device *pdev)
 	core.ctx_id = dss_get_ctx_id();
 	DSSDBG("initial ctx id %u\n", core.ctx_id);
 
-#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
-	/* DISPC_CONTROL */
-	if (omap_readl(0x48050440) & 1)	/* LCD enabled? */
-		skip_init = 1;
-#endif
-
-	r = dss_init(skip_init);
+	r = dss_init_platform_driver();
 	if (r) {
-		DSSERR("Failed to initialize DSS\n");
+		DSSERR("Failed to initialize DSS platform driver\n");
 		goto err_dss;
 	}
 
@@ -553,6 +547,11 @@ static int omap_dss_probe(struct platform_device *pdev)
 		goto err_venc;
 	}
 
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+	/* DISPC_CONTROL */
+	if (omap_readl(0x48050440) & 1)	/* LCD enabled? */
+		skip_init = 1;
+#endif
 	if (cpu_is_omap34xx()) {
 		r = sdi_init(skip_init);
 		if (r) {
@@ -610,7 +609,7 @@ err_dispc:
 err_dpi:
 	rfbi_exit();
 err_rfbi:
-	dss_exit();
+	dss_uninit_platform_driver();
 err_dss:
 	dss_clk_disable_all_no_ctx();
 	dss_put_clocks();
@@ -635,7 +634,7 @@ static int omap_dss_remove(struct platform_device *pdev)
 		sdi_exit();
 	}
 
-	dss_exit();
+	dss_uninit_platform_driver();
 
 	/*
 	 * As part of hwmod changes, DSS is not the only controller of dss
drivers/video/omap2/dss/dss.c +53 -2

76 lines not on this page · raw message

drivers/video/omap2/dss/dss.h +2 -2
index b394951..37c4544 100644
@@ -214,8 +214,8 @@ void dss_overlay_setup_l4_manager(struct omap_overlay_manager *mgr);
 void dss_recheck_connections(struct omap_dss_device *dssdev, bool force);
 
 /* DSS */
-int dss_init(bool skip_init);
-void dss_exit(void);
+int dss_init_platform_driver(void);
+void dss_uninit_platform_driver(void);
 
 void dss_save_context(void);
 void dss_restore_context(void);
Signature · 1 line
1.7.1
#27 lore raw

PATCH v10 11/18 OMAP2, 3: DSS2: Move clocks from core driver to dss driver

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

All clock management is moved to dss platform driver. clk_get/put APIs use dss device instead of core platform device.

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So the device name is changed from omap_display to omap_dss in 2420, 2430, 3xxx clock database files. Now the core driver "omap_display" only takes care of panel registration with the custom bus.
core driver also uses the clk_enable() / clk_disable() APIs exposed by DSS for clock management.
DSS driver would do clock management of clocks needed by DISPC, RFBI, DSI, VENC

TODO: The clock content would be adapted to omap_hwmod in a seperate series.

---
 arch/arm/mach-omap2/clock2420_data.c |    8 +-
 arch/arm/mach-omap2/clock2430_data.c |    8 +-
 arch/arm/mach-omap2/clock3xxx_data.c |   14 +-
 drivers/video/omap2/dss/core.c       |  343 +---------------------------------
 drivers/video/omap2/dss/dss.c        |  334 +++++++++++++++++++++++++++++++++-
 drivers/video/omap2/dss/dss.h        |   13 +-
 6 files changed, 360 insertions(+), 360 deletions(-)
arch/arm/mach-omap2/clock2420_data.c +4 -4
index b412958..d2abc2f 100644
@@ -1786,10 +1786,10 @@ static struct omap_clk omap2420_clks[] = {
 	CLK(NULL,	"gfx_2d_fck",	&gfx_2d_fck,	CK_242X),
 	CLK(NULL,	"gfx_ick",	&gfx_ick,	CK_242X),
 	/* DSS domain clocks */
-	CLK("omap_display",	"ick",		&dss_ick,	CK_242X),
-	CLK("omap_display",	"dss1_fck",	&dss1_fck,	CK_242X),
-	CLK("omap_display",	"dss2_fck",	&dss2_fck,	CK_242X),
-	CLK("omap_display",	"tv_fck",	&dss_54m_fck,	CK_242X),
+	CLK("omap_dss",	"ick",		&dss_ick,	CK_242X),
+	CLK("omap_dss",	"dss1_fck",	&dss1_fck,	CK_242X),
+	CLK("omap_dss",	"dss2_fck",	&dss2_fck,	CK_242X),
+	CLK("omap_dss",	"tv_fck",	&dss_54m_fck,	CK_242X),
 	/* L3 domain clocks */
 	CLK(NULL,	"core_l3_ck",	&core_l3_ck,	CK_242X),
 	CLK(NULL,	"ssi_fck",	&ssi_ssr_sst_fck, CK_242X),
arch/arm/mach-omap2/clock2430_data.c +4 -4
index 039155e..663f298 100644
@@ -1890,10 +1890,10 @@ static struct omap_clk omap2430_clks[] = {
 	CLK(NULL,	"mdm_ick",	&mdm_ick,	CK_243X),
 	CLK(NULL,	"mdm_osc_ck",	&mdm_osc_ck,	CK_243X),
 	/* DSS domain clocks */
-	CLK("omap_display",	"ick",		&dss_ick,	CK_243X),
-	CLK("omap_display",	"dss1_fck",	&dss1_fck,	CK_243X),
-	CLK("omap_display",	"dss2_fck",	&dss2_fck,	CK_243X),
-	CLK("omap_display",	"tv_fck",	&dss_54m_fck,	CK_243X),
+	CLK("omap_dss",	"ick",		&dss_ick,	CK_243X),
+	CLK("omap_dss",	"dss1_fck",	&dss1_fck,	CK_243X),
+	CLK("omap_dss",	"dss2_fck",	&dss2_fck,	CK_243X),
+	CLK("omap_dss",	"tv_fck",	&dss_54m_fck,	CK_243X),
 	/* L3 domain clocks */
 	CLK(NULL,	"core_l3_ck",	&core_l3_ck,	CK_243X),
 	CLK(NULL,	"ssi_fck",	&ssi_ssr_sst_fck, CK_243X),
arch/arm/mach-omap2/clock3xxx_data.c +7 -7
index 8618262..5c97b93 100644
@@ -3357,13 +3357,13 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK("omap_rng",	"ick",		&rng_ick,	CK_34XX | CK_36XX),
 	CLK(NULL,	"sha11_ick",	&sha11_ick,	CK_34XX | CK_36XX),
 	CLK(NULL,	"des1_ick",	&des1_ick,	CK_34XX | CK_36XX),
-	CLK("omap_display",	"dss1_fck",	&dss1_alwon_fck_3430es1, CK_3430ES1),
-	CLK("omap_display",	"dss1_fck",	&dss1_alwon_fck_3430es2, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
-	CLK("omap_display",	"tv_fck",	&dss_tv_fck,	CK_3XXX),
-	CLK("omap_display",	"video_fck",	&dss_96m_fck,	CK_3XXX),
-	CLK("omap_display",	"dss2_fck",	&dss2_alwon_fck, CK_3XXX),
-	CLK("omap_display",	"ick",		&dss_ick_3430es1,	CK_3430ES1),
-	CLK("omap_display",	"ick",		&dss_ick_3430es2,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+	CLK("omap_dss",	"dss1_fck",	&dss1_alwon_fck_3430es1, CK_3430ES1),
+	CLK("omap_dss",	"dss1_fck",	&dss1_alwon_fck_3430es2, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+	CLK("omap_dss",	"tv_fck",	&dss_tv_fck,	CK_3XXX),
+	CLK("omap_dss",	"video_fck",	&dss_96m_fck,	CK_3XXX),
+	CLK("omap_dss",	"dss2_fck",	&dss2_alwon_fck, CK_3XXX),
+	CLK("omap_dss",	"ick",		&dss_ick_3430es1,	CK_3430ES1),
+	CLK("omap_dss",	"ick",		&dss_ick_3430es2,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 	CLK(NULL,	"cam_mclk",	&cam_mclk,	CK_34XX | CK_36XX),
 	CLK(NULL,	"cam_ick",	&cam_ick,	CK_34XX | CK_36XX),
 	CLK(NULL,	"csi2_96m_fck",	&csi2_96m_fck,	CK_34XX | CK_36XX),
drivers/video/omap2/dss/core.c +4 -339

404 lines not on this page · raw message

drivers/video/omap2/dss/dss.c +333 -1

380 lines not on this page · raw message

drivers/video/omap2/dss/dss.h +8 -5
index 37c4544..c535ee1 100644
@@ -169,11 +169,6 @@ struct seq_file;
 struct platform_device;
 
 /* core */
-void dss_clk_enable(enum dss_clock clks);
-void dss_clk_disable(enum dss_clock clks);
-unsigned long dss_clk_get_rate(enum dss_clock clk);
-int dss_need_ctx_restore(void);
-void dss_dump_clocks(struct seq_file *s);
 struct bus_type *dss_get_bus(void);
 struct regulator *dss_get_vdds_dsi(void);
 struct regulator *dss_get_vdds_sdi(void);
@@ -219,8 +214,16 @@ void dss_uninit_platform_driver(void);
 
 void dss_save_context(void);
 void dss_restore_context(void);
+void dss_clk_enable(enum dss_clock clks);
+void dss_clk_disable(enum dss_clock clks);
+unsigned long dss_clk_get_rate(enum dss_clock clk);
+int dss_need_ctx_restore(void);
+void dss_dump_clocks(struct seq_file *s);
 
 void dss_dump_regs(struct seq_file *s);
+#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
+void dss_debug_dump_clocks(struct seq_file *s);
+#endif
 
 void dss_sdi_init(u8 datapairs);
 int dss_sdi_enable(void);
Signature · 1 line
1.7.1
#28 lore raw

PATCH v10 12/18 OMAP2, 3: DSS2: RFBI: create platform_driver, move init, exit to driver

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So a platform_driver for RFBI is created and init exit methods are moved from core.c to its driver probe,remove. pdev member has to be maintained by its own drivers.

RFBI platform driver is registered from inside omap_dss_probe, in the order desired.

---
 drivers/video/omap2/dss/core.c |    8 ++--
 drivers/video/omap2/dss/dss.h  |    8 ++--
 drivers/video/omap2/dss/rfbi.c |  110 ++++++++++++++++++++++++----------------
 3 files changed, 74 insertions(+), 52 deletions(-)
drivers/video/omap2/dss/core.c +4 -4
index bdb952f..d4b3da3 100644
@@ -201,9 +201,9 @@ static int omap_dss_probe(struct platform_device *pdev)
 	/* keep clocks enabled to prevent context saves/restores during init */
 	dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
 
-	r = rfbi_init();
+	r = rfbi_init_platform_driver();
 	if (r) {
-		DSSERR("Failed to initialize rfbi\n");
+		DSSERR("Failed to initialize rfbi platform driver\n");
 		goto err_rfbi;
 	}
 
@@ -285,7 +285,7 @@ err_venc:
 err_dispc:
 	dpi_exit();
 err_dpi:
-	rfbi_exit();
+	rfbi_uninit_platform_driver();
 err_rfbi:
 	dss_uninit_platform_driver();
 err_dss:
@@ -303,7 +303,7 @@ static int omap_dss_remove(struct platform_device *pdev)
 	venc_exit();
 	dispc_exit();
 	dpi_exit();
-	rfbi_exit();
+	rfbi_uninit_platform_driver();
 	if (cpu_is_omap34xx()) {
 		dsi_exit();
 		sdi_exit();
drivers/video/omap2/dss/dss.h +4 -4
index c535ee1..0ba4bdb 100644
@@ -428,8 +428,8 @@ static inline void venc_exit(void)
 
 /* RFBI */
 #ifdef CONFIG_OMAP2_DSS_RFBI
-int rfbi_init(void);
-void rfbi_exit(void);
+int rfbi_init_platform_driver(void);
+void rfbi_uninit_platform_driver(void);
 void rfbi_dump_regs(struct seq_file *s);
 
 int rfbi_configure(int rfbi_module, int bpp, int lines);
@@ -440,11 +440,11 @@ void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t);
 unsigned long rfbi_get_max_tx_rate(void);
 int rfbi_init_display(struct omap_dss_device *display);
 #else
-static inline int rfbi_init(void)
+static inline int rfbi_init_platform_driver(void)
 {
 	return 0;
 }
-static inline void rfbi_exit(void)
+static inline void rfbi_uninit_platform_driver(void)
 {
 }
 #endif
drivers/video/omap2/dss/rfbi.c +66 -44

125 lines not on this page · raw message

Signature · 1 line
1.7.1
#29 lore raw

PATCH v10 13/18 OMAP2, 3: DSS2: DISPC: create platform_driver, move init, exit to driver

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So a platform_driver for DISPC is created and init exit methods are moved from core.c to its driver probe,remove. pdev member has to be maintained by its own drivers.

DISPC platform driver is registered from inside omap_dss_probe, in the order desired.

---
 drivers/video/omap2/dss/core.c  |    8 ++--
 drivers/video/omap2/dss/dispc.c |  105 ++++++++++++++++++++++++---------------
 drivers/video/omap2/dss/dss.h   |    4 +-
 3 files changed, 70 insertions(+), 47 deletions(-)
drivers/video/omap2/dss/core.c +4 -4
index d4b3da3..5acb5e6 100644
@@ -213,9 +213,9 @@ static int omap_dss_probe(struct platform_device *pdev)
 		goto err_dpi;
 	}
 
-	r = dispc_init();
+	r = dispc_init_platform_driver();
 	if (r) {
-		DSSERR("Failed to initialize dispc\n");
+		DSSERR("Failed to initialize dispc platform driver\n");
 		goto err_dispc;
 	}
 
@@ -281,7 +281,7 @@ err_dsi:
 err_sdi:
 	venc_exit();
 err_venc:
-	dispc_exit();
+	dispc_uninit_platform_driver();
 err_dispc:
 	dpi_exit();
 err_dpi:
@@ -301,7 +301,7 @@ static int omap_dss_remove(struct platform_device *pdev)
 	dss_uninitialize_debugfs();
 
 	venc_exit();
-	dispc_exit();
+	dispc_uninit_platform_driver();
 	dpi_exit();
 	rfbi_uninit_platform_driver();
 	if (cpu_is_omap34xx()) {
drivers/video/omap2/dss/dispc.c +64 -41

120 lines not on this page · raw message

drivers/video/omap2/dss/dss.h +2 -2
index 0ba4bdb..f4835c8 100644
@@ -319,8 +319,8 @@ static inline void dpi_exit(void)
 #endif
 
 /* DISPC */
-int dispc_init(void);
-void dispc_exit(void);
+int dispc_init_platform_driver(void);
+void dispc_uninit_platform_driver(void);
 void dispc_dump_clocks(struct seq_file *s);
 void dispc_dump_irqs(struct seq_file *s);
 void dispc_dump_regs(struct seq_file *s);
Signature · 1 line
1.7.1
#30 lore raw

PATCH v10 14/18 OMAP2, 3: DSS2: VENC: create platform_driver, move init, exit to driver

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So a platform_driver for VENC is created and init exit methods are moved from core.c to its driver probe,remove. pdev member has to be maintained by its own drivers.

Also, venc_vdda_dac reading is moved to venc.c.

VENC platform driver is registered from inside omap_dss_probe, in the order desired.

---
 arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
 arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
 arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
 arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
 arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
 arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
 arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c |    2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
 drivers/video/omap2/dss/core.c               |   28 +------
 drivers/video/omap2/dss/dss.h                |    9 +-
 drivers/video/omap2/dss/venc.c               |  116 +++++++++++++++++---------
 12 files changed, 93 insertions(+), 78 deletions(-)
arch/arm/mach-omap2/board-3430sdp.c +1 -1
index d00f356..e0d13ae 100644
@@ -308,7 +308,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
 };
 
 static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omap_display");
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 static struct omap_board_config_kernel sdp3430_config[] __initdata = {
 };
arch/arm/mach-omap2/board-cm-t35.c +1 -1
index 1c36ec8..2e9265e 100644
@@ -488,7 +488,7 @@ static struct regulator_consumer_supply cm_t35_vsim_supply = {
 };
 
 static struct regulator_consumer_supply cm_t35_vdac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omap_display");
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 static struct regulator_consumer_supply cm_t35_vdvi_supply =
 	REGULATOR_SUPPLY("vdvi", "omap_display");
arch/arm/mach-omap2/board-devkit8000.c +1 -1
index 6a2eb49..331b94e 100644
@@ -199,7 +199,7 @@ static struct omap_dss_board_info devkit8000_dss_data = {
 };
 
 static struct regulator_consumer_supply devkit8000_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omap_display");
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 static uint32_t board_keymap[] = {
 	KEY(0, 0, KEY_1),
arch/arm/mach-omap2/board-omap3beagle.c +1 -1
index c0a5066..4dd1475 100644
@@ -229,7 +229,7 @@ static struct omap_dss_board_info beagle_dss_data = {
 };
 
 static struct regulator_consumer_supply beagle_vdac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omap_display");
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 static struct regulator_consumer_supply beagle_vdvi_supply =
 	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
arch/arm/mach-omap2/board-omap3evm.c +1 -1
index 5f156fe..ec45575 100644
@@ -493,7 +493,7 @@ static struct twl4030_codec_data omap3evm_codec_data = {
 };
 
 static struct regulator_consumer_supply omap3_evm_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omap_display");
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 /* VDAC for DSS driving S-Video */
 static struct regulator_init_data omap3_evm_vdac = {
arch/arm/mach-omap2/board-omap3pandora.c +1 -1
index 613ab58..b44e604 100644
@@ -342,7 +342,7 @@ static struct regulator_consumer_supply pandora_vmmc3_supply =
 	REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.2");
 
 static struct regulator_consumer_supply pandora_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omap_display");
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 static struct regulator_consumer_supply pandora_vdds_supplies[] = {
 	REGULATOR_SUPPLY("vdds_sdi", "omap_display"),
arch/arm/mach-omap2/board-omap3stalker.c +1 -1
index 7671218..ab98a64 100644
@@ -441,7 +441,7 @@ static struct twl4030_codec_data omap3stalker_codec_data = {
 };
 
 static struct regulator_consumer_supply omap3_stalker_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omap_display");
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 /* VDAC for DSS driving S-Video */
 static struct regulator_init_data omap3_stalker_vdac = {
arch/arm/mach-omap2/board-rx51-peripherals.c +1 -1
index 7aedafd..b783854 100644
@@ -364,7 +364,7 @@ static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
 };
 
 static struct regulator_consumer_supply rx51_vdac_supply[] = {
-	REGULATOR_SUPPLY("vdda_dac", "omap_display"),
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc"),
 };
 
 static struct regulator_init_data rx51_vaux1 = {
arch/arm/mach-omap2/board-zoom-peripherals.c +1 -1
index d52fc7b..3bb5c7c 100644
@@ -230,7 +230,7 @@ static struct regulator_consumer_supply zoom_vpll2_supply =
 	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
 
 static struct regulator_consumer_supply zoom_vdda_dac_supply =
-	REGULATOR_SUPPLY("vdda_dac", "omap_display");
+	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 static struct regulator_init_data zoom_vpll2 = {
 	.constraints = {
drivers/video/omap2/dss/core.c +4 -24
index 5acb5e6..9852a70 100644
@@ -43,7 +43,6 @@ static struct {
 
 	struct regulator *vdds_dsi_reg;
 	struct regulator *vdds_sdi_reg;
-	struct regulator *vdda_dac_reg;
 } core;
 
 static char *def_disp_name;
@@ -85,20 +84,6 @@ struct regulator *dss_get_vdds_sdi(void)
 	return reg;
 }
 
-struct regulator *dss_get_vdda_dac(void)
-{
-	struct regulator *reg;
-
-	if (core.vdda_dac_reg != NULL)
-		return core.vdda_dac_reg;
-
-	reg = regulator_get(&core.pdev->dev, "vdda_dac");
-	if (!IS_ERR(reg))
-		core.vdda_dac_reg = reg;
-
-	return reg;
-}
-
 #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
 static int dss_debug_show(struct seq_file *s, void *unused)
 {
@@ -219,9 +204,9 @@ static int omap_dss_probe(struct platform_device *pdev)
 		goto err_dispc;
 	}
 
-	r = venc_init(pdev);
+	r = venc_init_platform_driver();
 	if (r) {
-		DSSERR("Failed to initialize venc\n");
+		DSSERR("Failed to initialize venc platform driver\n");
 		goto err_venc;
 	}
 
@@ -279,7 +264,7 @@ err_dsi:
 	if (cpu_is_omap34xx())
 		sdi_exit();
 err_sdi:
-	venc_exit();
+	venc_uninit_platform_driver();
 err_venc:
 	dispc_uninit_platform_driver();
 err_dispc:
@@ -300,7 +285,7 @@ static int omap_dss_remove(struct platform_device *pdev)
 
 	dss_uninitialize_debugfs();
 
-	venc_exit();
+	venc_uninit_platform_driver();
 	dispc_uninit_platform_driver();
 	dpi_exit();
 	rfbi_uninit_platform_driver();
@@ -597,11 +582,6 @@ static void __exit omap_dss_exit(void)
 		core.vdds_sdi_reg = NULL;
 	}
 
-	if (core.vdda_dac_reg != NULL) {
-		regulator_put(core.vdda_dac_reg);
-		core.vdda_dac_reg = NULL;
-	}
-
 	platform_driver_unregister(&omap_dss_driver);
 
 	omap_dss_bus_unregister();
drivers/video/omap2/dss/dss.h +4 -5
index f4835c8..9313851 100644
@@ -172,7 +172,6 @@ struct platform_device;
 struct bus_type *dss_get_bus(void);
 struct regulator *dss_get_vdds_dsi(void);
 struct regulator *dss_get_vdds_sdi(void);
-struct regulator *dss_get_vdda_dac(void);
 
 /* display */
 int dss_suspend_all_devices(void);
@@ -412,16 +411,16 @@ int dispc_get_clock_div(enum omap_channel channel,
 
 /* VENC */
 #ifdef CONFIG_OMAP2_DSS_VENC
-int venc_init(struct platform_device *pdev);
-void venc_exit(void);
+int venc_init_platform_driver(void);
+void venc_uninit_platform_driver(void);
 void venc_dump_regs(struct seq_file *s);
 int venc_init_display(struct omap_dss_device *display);
 #else
-static inline int venc_init(struct platform_device *pdev)
+static inline int venc_init_platform_driver(void)
 {
 	return 0;
 }
-static inline void venc_exit(void)
+static inline void venc_uninit_platform_driver(void)
 {
 }
 #endif
drivers/video/omap2/dss/venc.c +76 -40

137 lines not on this page · raw message

Signature · 1 line
1.7.1
#31 lore raw

PATCH v10 15/18 OMAP2, 3: DSS2: DSI: create platform_driver, move init, exit to driver

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So a platform_driver for DSI is created and init exit methods are moved from core.c to its driver probe,remove. pdev member has to be maintained by its own drivers.

Also, vdds_dsi regulator handling is copied to dsi.c, since vdds_dsi regulator is needed by dpi_init() too. Board files are updated accordingly to add 2 instances of vdds_dsi regulator.

DSI platform driver is registered from inside omap_dss_probe, in the order desired.

---
 arch/arm/mach-omap2/board-3430sdp.c          |    1 +
 arch/arm/mach-omap2/board-devkit8000.c       |   10 ++--
 arch/arm/mach-omap2/board-igep0020.c         |   10 ++--
 arch/arm/mach-omap2/board-omap3beagle.c      |   10 ++--
 arch/arm/mach-omap2/board-omap3evm.c         |   10 ++--
 arch/arm/mach-omap2/board-omap3pandora.c     |    1 +
 arch/arm/mach-omap2/board-omap3stalker.c     |   10 ++--
 arch/arm/mach-omap2/board-zoom-peripherals.c |   10 ++--
 drivers/video/omap2/dss/core.c               |    8 ++--
 drivers/video/omap2/dss/dsi.c                |   64 ++++++++++++++++++++++++-
 drivers/video/omap2/dss/dss.h                |    8 ++--
 11 files changed, 107 insertions(+), 35 deletions(-)
arch/arm/mach-omap2/board-3430sdp.c +1 -0
index e0d13ae..33ff4f6 100644
@@ -533,6 +533,7 @@ static struct regulator_init_data sdp3430_vdac = {
 /* VPLL2 for digital video outputs */
 static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
 	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
 };
 
 static struct regulator_init_data sdp3430_vpll2 = {
arch/arm/mach-omap2/board-devkit8000.c +6 -4
index 331b94e..6cdedd9 100644
@@ -273,8 +273,10 @@ static struct twl4030_gpio_platform_data devkit8000_gpio_data = {
 	.setup		= devkit8000_twl_gpio_setup,
 };
 
-static struct regulator_consumer_supply devkit8000_vpll1_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
 
 /* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
 static struct regulator_init_data devkit8000_vmmc1 = {
@@ -315,8 +317,8 @@ static struct regulator_init_data devkit8000_vpll1 = {
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &devkit8000_vpll1_supply,
+	.num_consumer_supplies	= ARRAY_SIZE(devkit8000_vpll1_supplies),
+	.consumer_supplies	= devkit8000_vpll1_supplies,
 };
 
 /* VAUX4 for ads7846 and nubs */
arch/arm/mach-omap2/board-igep0020.c +6 -4
index d79dcd5..dfbe3a1 100644
@@ -485,8 +485,10 @@ static struct omap_dss_board_info igep2_dss_data = {
 	.default_device	= &igep2_dvi_device,
 };
 
-static struct regulator_consumer_supply igep2_vpll2_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply igep2_vpll2_supplies[] = {
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
 
 static struct regulator_init_data igep2_vpll2 = {
 	.constraints = {
@@ -499,8 +501,8 @@ static struct regulator_init_data igep2_vpll2 = {
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &igep2_vpll2_supply,
+	.num_consumer_supplies	= ARRAY_SIZE(igep2_vpll2_supplies),
+	.consumer_supplies	= igep2_vpll2_supplies,
 };
 
 static void __init igep2_display_init(void)
arch/arm/mach-omap2/board-omap3beagle.c +6 -4
index 4dd1475..caf6c8a 100644
@@ -231,8 +231,10 @@ static struct omap_dss_board_info beagle_dss_data = {
 static struct regulator_consumer_supply beagle_vdac_supply =
 	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
-static struct regulator_consumer_supply beagle_vdvi_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply beagle_vdvi_supplies[] = {
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
 
 static void __init beagle_display_init(void)
 {
@@ -419,8 +421,8 @@ static struct regulator_init_data beagle_vpll2 = {
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &beagle_vdvi_supply,
+	.num_consumer_supplies	= ARRAY_SIZE(beagle_vdvi_supplies),
+	.consumer_supplies	= beagle_vdvi_supplies,
 };
 
 static struct twl4030_usb_data beagle_usb_data = {
arch/arm/mach-omap2/board-omap3evm.c +6 -4
index ec45575..0c56b9e 100644
@@ -511,8 +511,10 @@ static struct regulator_init_data omap3_evm_vdac = {
 };
 
 /* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_evm_vpll2_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = {
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
 
 static struct regulator_init_data omap3_evm_vpll2 = {
 	.constraints = {
@@ -524,8 +526,8 @@ static struct regulator_init_data omap3_evm_vpll2 = {
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &omap3_evm_vpll2_supply,
+	.num_consumer_supplies	= ARRAY_SIZE(omap3_evm_vpll2_supplies),
+	.consumer_supplies	= omap3_evm_vpll2_supplies,
 };
 
 static struct twl4030_platform_data omap3evm_twldata = {
arch/arm/mach-omap2/board-omap3pandora.c +1 -0
index b44e604..b430d2b 100644
@@ -347,6 +347,7 @@ static struct regulator_consumer_supply pandora_vdda_dac_supply =
 static struct regulator_consumer_supply pandora_vdds_supplies[] = {
 	REGULATOR_SUPPLY("vdds_sdi", "omap_display"),
 	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
 };
 
 static struct regulator_consumer_supply pandora_vcc_lcd_supply =
arch/arm/mach-omap2/board-omap3stalker.c +6 -4
index ab98a64..b5e8680 100644
@@ -459,8 +459,10 @@ static struct regulator_init_data omap3_stalker_vdac = {
 };
 
 /* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_stalker_vpll2_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply omap3_stalker_vpll2_supplies[] = {
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
 
 static struct regulator_init_data omap3_stalker_vpll2 = {
 	.constraints		= {
@@ -473,8 +475,8 @@ static struct regulator_init_data omap3_stalker_vpll2 = {
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 		| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &omap3_stalker_vpll2_supply,
+	.num_consumer_supplies	= ARRAY_SIZE(omap3_stalker_vpll2_supplies),
+	.consumer_supplies	= omap3_stalker_vpll2_supplies,
 };
 
 static struct twl4030_platform_data omap3stalker_twldata = {
arch/arm/mach-omap2/board-zoom-peripherals.c +6 -4
index 3bb5c7c..780a99c 100644
@@ -226,8 +226,10 @@ static struct omap2_hsmmc_info mmc[] = {
 	{}      /* Terminator */
 };
 
-static struct regulator_consumer_supply zoom_vpll2_supply =
-	REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply zoom_vpll2_supplies[] = {
+	REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
 
 static struct regulator_consumer_supply zoom_vdda_dac_supply =
 	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
@@ -241,8 +243,8 @@ static struct regulator_init_data zoom_vpll2 = {
 		.valid_ops_mask         = REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies		= 1,
-	.consumer_supplies		= &zoom_vpll2_supply,
+	.num_consumer_supplies		= ARRAY_SIZE(zoom_vpll2_supplies),
+	.consumer_supplies		= zoom_vpll2_supplies,
 };
 
 static struct regulator_init_data zoom_vdac = {
drivers/video/omap2/dss/core.c +4 -4
index 9852a70..85add9c 100644
@@ -222,9 +222,9 @@ static int omap_dss_probe(struct platform_device *pdev)
 			goto err_sdi;
 		}
 
-		r = dsi_init(pdev);
+		r = dsi_init_platform_driver();
 		if (r) {
-			DSSERR("Failed to initialize DSI\n");
+			DSSERR("Failed to initialize DSI platform driver\n");
 			goto err_dsi;
 		}
 	}
@@ -259,7 +259,7 @@ err_register:
 	dss_uninitialize_debugfs();
 err_debugfs:
 	if (cpu_is_omap34xx())
-		dsi_exit();
+		dsi_uninit_platform_driver();
 err_dsi:
 	if (cpu_is_omap34xx())
 		sdi_exit();
@@ -290,7 +290,7 @@ static int omap_dss_remove(struct platform_device *pdev)
 	dpi_exit();
 	rfbi_uninit_platform_driver();
 	if (cpu_is_omap34xx()) {
-		dsi_exit();
+		dsi_uninit_platform_driver();
 		sdi_exit();
 	}
 
drivers/video/omap2/dss/dsi.c +61 -3

98 lines not on this page · raw message

drivers/video/omap2/dss/dss.h +4 -4
index 9313851..981d247 100644
@@ -261,8 +261,8 @@ static inline void sdi_exit(void)
 
 /* DSI */
 #ifdef CONFIG_OMAP2_DSS_DSI
-int dsi_init(struct platform_device *pdev);
-void dsi_exit(void);
+int dsi_init_platform_driver(void);
+void dsi_uninit_platform_driver(void);
 
 void dsi_dump_clocks(struct seq_file *s);
 void dsi_dump_irqs(struct seq_file *s);
@@ -287,11 +287,11 @@ void dsi_get_overlay_fifo_thresholds(enum omap_plane plane,
 void dsi_wait_dsi1_pll_active(void);
 void dsi_wait_dsi2_pll_active(void);
 #else
-static inline int dsi_init(struct platform_device *pdev)
+static inline int dsi_init_platform_driver(void)
 {
 	return 0;
 }
-static inline void dsi_exit(void)
+static inline void dsi_uninit_platform_driver(void)
 {
 }
 static inline void dsi_wait_dsi1_pll_active(void)
Signature · 1 line
1.7.1
#32 lore raw

PATCH v10 16/18 OMAP2,3: DSS2: replace printk with dev_dbg in init

In reply to Sumit Semwal

This patch replaces printk's in the init/probe functions to dev_dbg for boot time optimization.

---
 drivers/video/omap2/dss/dispc.c |    2 +-
 drivers/video/omap2/dss/dsi.c   |    2 +-
 drivers/video/omap2/dss/rfbi.c  |    2 +-
 drivers/video/omap2/dss/venc.c  |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)
drivers/video/omap2/dss/dispc.c +1 -1
index abfed47..1c22cf0 100644
@@ -3350,7 +3350,7 @@ static int omap_dispchw_probe(struct platform_device *pdev)
 	dispc_save_context();
 
 	rev = dispc_read_reg(DISPC_REVISION);
-	printk(KERN_INFO "OMAP DISPC rev %d.%d\n",
+	dev_dbg(&pdev->dev, "OMAP DISPC rev %d.%d\n",
 	       FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
 
 	enable_clocks(0);
drivers/video/omap2/dss/dsi.c +1 -1
index d854137..39a1c04 100644
@@ -3300,7 +3300,7 @@ static int dsi_init(struct platform_device *pdev)
 	enable_clocks(1);
 
 	rev = dsi_read_reg(DSI_REVISION);
-	printk(KERN_INFO "OMAP DSI rev %d.%d\n",
+	dev_dbg(&pdev->dev, "OMAP DSI rev %d.%d\n",
 	       FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
 
 	enable_clocks(0);
drivers/video/omap2/dss/rfbi.c +1 -1
index a64e119..93b13c5 100644
@@ -1046,7 +1046,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
 	rfbi_write_reg(RFBI_SYSCONFIG, l);
 
 	rev = rfbi_read_reg(RFBI_REVISION);
-	printk(KERN_INFO "OMAP RFBI rev %d.%d\n",
+	dev_dbg(&pdev->dev, "OMAP RFBI rev %d.%d\n",
 	       FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
 
 	rfbi_enable_clocks(0);
drivers/video/omap2/dss/venc.c +1 -1
index 935ae8e..3db9061 100644
@@ -739,7 +739,7 @@ static int omap_venchw_probe(struct platform_device *pdev)
 	venc_enable_clocks(1);
 
 	rev_id = (u8)(venc_read_reg(VENC_REV_ID) & 0xff);
-	printk(KERN_INFO "OMAP VENC rev %d\n", rev_id);
+	dev_dbg(&pdev->dev, "OMAP VENC rev %d\n", rev_id);
 
 	venc_enable_clocks(0);
 
Signature · 1 line
1.7.1
#33 lore raw

PATCH v10 17/18 OMAP2,3: DSS2: Use platform device to get baseaddr

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

DSS, DISPC, DSI, RFBI, VENC baseaddr can be obtained from platform_get_resource(). This API in turn picks the right silicon baseaddr from the hwmod database. So hardcoding of base addr could be removed.

---
 drivers/video/omap2/dss/dispc.c |   11 ++++++++---
 drivers/video/omap2/dss/dsi.c   |   12 +++++++++---
 drivers/video/omap2/dss/dss.c   |   11 ++++++++---
 drivers/video/omap2/dss/rfbi.c  |   10 +++++++---
 drivers/video/omap2/dss/venc.c  |   11 ++++++++---
 5 files changed, 40 insertions(+), 15 deletions(-)
drivers/video/omap2/dss/dispc.c +8 -3
index 1c22cf0..381942d 100644
@@ -42,8 +42,6 @@
 #include "dss_features.h"
 
 /* DISPC */
-#define DISPC_BASE			0x48050400
-
 #define DISPC_SZ_REGS			SZ_4K
 
 struct dispc_reg { u16 idx; };
@@ -3324,6 +3322,8 @@ int dispc_setup_plane(enum omap_plane plane,
 static int omap_dispchw_probe(struct platform_device *pdev)
 {
 	u32 rev;
+	struct resource *dispc_mem;
+
 	dispc.pdev = pdev;
 
 	spin_lock_init(&dispc.irq_lock);
@@ -3335,7 +3335,12 @@ static int omap_dispchw_probe(struct platform_device *pdev)
 
 	INIT_WORK(&dispc.error_work, dispc_error_worker);
 
-	dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+	dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
+	if (!dispc_mem) {
+		DSSERR("can't get IORESOURCE_MEM DISPC\n");
+		return -EINVAL;
+	}
+	dispc.base = ioremap(dispc_mem->start, resource_size(dispc_mem));
 	if (!dispc.base) {
 		DSSERR("can't ioremap DISPC\n");
 		return -ENOMEM;
drivers/video/omap2/dss/dsi.c +9 -3
index 39a1c04..cab08cb 100644
@@ -42,8 +42,6 @@
 /*#define VERBOSE_IRQ*/
 #define DSI_CATCH_MISSING_TE
 
-#define DSI_BASE		0x4804FC00
-
 struct dsi_reg { u16 idx; };
 
 #define DSI_REG(idx)		((const struct dsi_reg) { idx })
@@ -3257,6 +3255,7 @@ static int dsi_init(struct platform_device *pdev)
 {
 	u32 rev;
 	int r;
+	struct resource *dsi_mem;
 
 	spin_lock_init(&dsi.errors_lock);
 	dsi.errors = 0;
@@ -3283,7 +3282,13 @@ static int dsi_init(struct platform_device *pdev)
 	dsi.te_timer.function = dsi_te_timeout;
 	dsi.te_timer.data = 0;
 #endif
-	dsi.base = ioremap(DSI_BASE, DSI_SZ_REGS);
+	dsi_mem = platform_get_resource(dsi.pdev, IORESOURCE_MEM, 0);
+	if (!dsi_mem) {
+		DSSERR("can't get IORESOURCE_MEM DSI\n");
+		r = -EINVAL;
+		goto err0;
+	}
+	dsi.base = ioremap(dsi_mem->start, resource_size(dsi_mem));
 	if (!dsi.base) {
 		DSSERR("can't ioremap DSI\n");
 		r = -ENOMEM;
@@ -3310,6 +3315,7 @@ err2:
 	iounmap(dsi.base);
 err1:
 	destroy_workqueue(dsi.workqueue);
+err0:
 	return r;
 }
 
drivers/video/omap2/dss/dss.c +8 -3
index 8b7972e..4d7a816 100644
@@ -34,8 +34,6 @@
 #include <plat/clock.h>
 #include "dss.h"
 
-#define DSS_BASE			0x48050000
-
 #define DSS_SZ_REGS			SZ_512
 
 struct dss_reg {
@@ -567,8 +565,15 @@ static int dss_init(bool skip_init)
 {
 	int r;
 	u32 rev;
+	struct resource *dss_mem;
 
-	dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+	dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
+	if (!dss_mem) {
+		DSSERR("can't get IORESOURCE_MEM DSS\n");
+		r = -EINVAL;
+		goto fail0;
+	}
+	dss.base = ioremap(dss_mem->start, resource_size(dss_mem));
 	if (!dss.base) {
 		DSSERR("can't ioremap DSS\n");
 		r = -ENOMEM;
drivers/video/omap2/dss/rfbi.c +7 -3
index 93b13c5..fc665a7 100644
@@ -36,8 +36,6 @@
 #include <plat/display.h>
 #include "dss.h"
 
-#define RFBI_BASE               0x48050800
-
 struct rfbi_reg { u16 idx; };
 
 #define RFBI_REG(idx)		((const struct rfbi_reg) { idx })
@@ -1019,6 +1017,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
 {
 	u32 rev;
 	u32 l;
+	struct resource *rfbi_mem;
 
 	rfbi.pdev = pdev;
 
@@ -1028,7 +1027,12 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
 	atomic_set(&rfbi.cmd_fifo_full, 0);
 	atomic_set(&rfbi.cmd_pending, 0);
 
-	rfbi.base = ioremap(RFBI_BASE, SZ_256);
+	rfbi_mem = platform_get_resource(rfbi.pdev, IORESOURCE_MEM, 0);
+	if (!rfbi_mem) {
+		DSSERR("can't get IORESOURCE_MEM RFBI\n");
+		return -EINVAL;
+	}
+	rfbi.base = ioremap(rfbi_mem->start, resource_size(rfbi_mem));
 	if (!rfbi.base) {
 		DSSERR("can't ioremap RFBI\n");
 		return -ENOMEM;
drivers/video/omap2/dss/venc.c +8 -3
index 3db9061..ea1c87b 100644
@@ -39,8 +39,6 @@
 
 #include "dss.h"
 
-#define VENC_BASE	0x48050C00
-
 /* Venc registers */
 #define VENC_REV_ID				0x00
 #define VENC_STATUS				0x04
@@ -717,13 +715,20 @@ void venc_dump_regs(struct seq_file *s)
 static int omap_venchw_probe(struct platform_device *pdev)
 {
 	u8 rev_id;
+	struct resource *venc_mem;
+
 	venc.pdev = pdev;
 
 	mutex_init(&venc.venc_lock);
 
 	venc.wss_data = 0;
 
-	venc.base = ioremap(VENC_BASE, SZ_1K);
+	venc_mem = platform_get_resource(venc.pdev, IORESOURCE_MEM, 0);
+	if (!venc_mem) {
+		DSSERR("can't get IORESOURCE_MEM VENC\n");
+		return -EINVAL;
+	}
+	venc.base = ioremap(venc_mem->start, resource_size(venc_mem));
 	if (!venc.base) {
 		DSSERR("can't ioremap VENC\n");
 		return -ENOMEM;
Signature · 1 line
1.7.1
#34 lore raw

PATCH v10 18/18 OMAP2,3: DSS2: Get DSS IRQ from platform device

In reply to Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

DSS IRQ number can be obtained from platform_get_irq(). This API in turn picks the right IRQ number belonging to HW IP from the hwmod database. So hardcoding of IRQ number could be removed.

---
 drivers/video/omap2/dss/dss.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)
drivers/video/omap2/dss/dss.c +14 -7
index 4d7a816..f9390b4 100644
@@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
 
 static int dss_init(bool skip_init)
 {
-	int r;
+	int r, dss_irq;
 	u32 rev;
 	struct resource *dss_mem;
 
@@ -609,11 +609,18 @@ static int dss_init(bool skip_init)
 	REG_FLD_MOD(DSS_CONTROL, 0, 2, 2);	/* venc clock mode = normal */
 #endif
 
-	r = request_irq(INT_24XX_DSS_IRQ,
-			cpu_is_omap24xx()
-			? dss_irq_handler_omap2
-			: dss_irq_handler_omap3,
-			0, "OMAP DSS", NULL);
+	dss_irq = platform_get_irq(dss.pdev, 0);
+	if (dss_irq < 0) {
+		DSSERR("omap2 dss: platform_get_irq failed\n");
+		r = -ENODEV;
+		goto fail1;
+	}
+
+	r = request_irq(dss_irq,
+		cpu_is_omap24xx()
+		? dss_irq_handler_omap2
+		: dss_irq_handler_omap3,
+		0, "OMAP DSS", NULL);
 
 	if (r < 0) {
 		DSSERR("omap2 dss: request_irq failed\n");
@@ -641,7 +648,7 @@ static int dss_init(bool skip_init)
 	return 0;
 
 fail2:
-	free_irq(INT_24XX_DSS_IRQ, NULL);
+	free_irq(dss_irq, NULL);
 fail1:
 	iounmap(dss.base);
 fail0:
Signature · 1 line
1.7.1
#35 lore raw

PATCH v10 18/18 OMAP2, 3: DSS2: Get DSS IRQ from platform device

Hi Sumit,

Quoted 38 lines · Sumit Semwal

From: Senthilvadivu Guruswamy<[email protected]>

DSS IRQ number can be obtained from platform_get_irq(). This API in turn picks the right IRQ number belonging to HW IP from the hwmod database. So hardcoding of IRQ number could be removed.

---
  drivers/video/omap2/dss/dss.c |   21 ++++++++++++++-------
  1 files changed, 14 insertions(+), 7 deletions(-)
drivers/video/omap2/dss/dss.c +2 -6
index 4d7a816..f9390b4 100644
@@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
 
  static int dss_init(bool skip_init)
  {
-	int r;
+	int r, dss_irq;
  	u32 rev;
  	struct resource *dss_mem;
 
@@ -609,11 +609,18 @@ static int dss_init(bool skip_init)
  	REG_FLD_MOD(DSS_CONTROL, 0, 2, 2);	/* venc clock mode = normal */
  #endif
 
-	r = request_irq(INT_24XX_DSS_IRQ,
-			cpu_is_omap24xx()
-			? dss_irq_handler_omap2
-			: dss_irq_handler_omap3,
-			0, "OMAP DSS", NULL);
+	dss_irq = platform_get_irq(dss.pdev, 0);

drivers/video/omap2/dss/dss.c static int dss_init(bool skip_init) · line 622

Quoted 10 lines
drivers/video/omap2/dss/dss.c +10 -0
+	if (dss_irq<  0) {
+		DSSERR("omap2 dss: platform_get_irq failed\n");
+		r = -ENODEV;
+		goto fail1;
+	}
+
+	r = request_irq(dss_irq,
+		cpu_is_omap24xx()
+		? dss_irq_handler_omap2
+		: dss_irq_handler_omap3,

it should be

		cpu_is_omap24xx()
		? dss_irq_handler_omap3
		: dss_irq_handler_omap2,

I am seeing a crash on Panda, which gets rectified with this change. The root cause is access to DSS_IRQSTATUS register in the dss_irq_handler_omap3 handler, which is not valid for OMAP4.

Regards,
Raghuveer

Quoted 13 lines
drivers/video/omap2/dss/dss.c +2 -1
+		0, "OMAP DSS", NULL);
 
  	if (r<  0) {
  		DSSERR("omap2 dss: request_irq failed\n");
@@ -641,7 +648,7 @@ static int dss_init(bool skip_init)
  	return 0;
 
  fail2:
-	free_irq(INT_24XX_DSS_IRQ, NULL);
+	free_irq(dss_irq, NULL);
  fail1:
  	iounmap(dss.base);
  fail0:
#36 lore raw

PATCH v10 18/18 OMAP2, 3: DSS2: Get DSS IRQ from platform device

Quoted 7 lines · Raghuveer Murthy

drivers/video/omap2/dss/dss.c static int dss_init(bool skip_init) · line 622

Quoted 4 lines
drivers/video/omap2/dss/dss.c +4 -0
+	r = request_irq(dss_irq,
+		cpu_is_omap24xx()
+		? dss_irq_handler_omap2
+		: dss_irq_handler_omap3,

it should be

Quoted 7 lines
		cpu_is_omap24xx()
		? dss_irq_handler_omap3
		: dss_irq_handler_omap2,

I am seeing a crash on Panda, which gets rectified with this change. The root cause is access to DSS_IRQSTATUS register in the dss_irq_handler_omap3 handler, which is not valid for OMAP4.

That really doesn't look right. Let me translate the code you've just written:

	if (cpu_is_omap24xx())
		handler = dss_irq_handler_omap3;
	else
		handler = dss_irq_handler_omap2;

Which means: if we have an OMAP24xx device, use the OMAP3 handler, otherwise use the OMAP2 handler. That's got to be wrong.

#37 lore raw

PATCH v10 18/18 OMAP2, 3: DSS2: Get DSS IRQ from platform device

Quoted 19 lines · Russell King - ARM Linux
Quoted 7 lines · Raghuveer Murthy

drivers/video/omap2/dss/dss.c static int dss_init(bool skip_init) · line 622

Quoted 4 lines
drivers/video/omap2/dss/dss.c +4 -0
+	r = request_irq(dss_irq,
+		cpu_is_omap24xx()
+		? dss_irq_handler_omap2
+		: dss_irq_handler_omap3,

it should be

Quoted 7 lines
		cpu_is_omap24xx()
		? dss_irq_handler_omap3
		: dss_irq_handler_omap2,

I am seeing a crash on Panda, which gets rectified with this change. The root cause is access to DSS_IRQSTATUS register in the dss_irq_handler_omap3 handler, which is not valid for OMAP4.

That really doesn't look right. Let me translate the code you've just written:

Quoted 8 lines
	if (cpu_is_omap24xx())
		handler = dss_irq_handler_omap3;
	else
		handler = dss_irq_handler_omap2;

Which means: if we have an OMAP24xx device, use the OMAP3 handler, otherwise use the OMAP2 handler. That's got to be wrong.

I agree, that the logic seems counter-intuitive. I was doing a quick test.

However, to keep the correct sequence, the logic inside the respective handlers need to be looked at.

Regards,
Raghuveer

#38 lore raw

PATCH v10 18/18 OMAP2, 3: DSS2: Get DSS IRQ from platform device

Raghuveer,

Quoted 27 lines · Raghuveer Murthy
Quoted 26 lines · Russell King - ARM Linux
Quoted 8 lines · Raghuveer Murthy
Quoted 5 lines

+ ? ? ? r = request_irq(dss_irq,
+ ? ? ? ? ? ? ? cpu_is_omap24xx()
+ ? ? ? ? ? ? ? ? dss_irq_handler_omap2
+ ? ? ? ? ? ? ? : dss_irq_handler_omap3,

it should be

Quoted 7 lines

? ? ? ? ? ? ? ?cpu_is_omap24xx()
? ? ? ? ? ? ? ?? dss_irq_handler_omap3
? ? ? ? ? ? ? ?: dss_irq_handler_omap2,

I am seeing a crash on Panda, which gets rectified with this change. The root cause is access to DSS_IRQSTATUS register in the dss_irq_handler_omap3 handler, which is not valid for OMAP4.

That really doesn't look right. ?Let me translate the code you've just written:

? ? ? ?if (cpu_is_omap24xx())
? ? ? ? ? ? ? ?handler = dss_irq_handler_omap3;
? ? ? ?else
? ? ? ? ? ? ? ?handler = dss_irq_handler_omap2;

Quoted 7 lines
Quoted 3 lines

Which means: if we have an OMAP24xx device, use the OMAP3 handler, otherwise use the OMAP2 handler. ?That's got to be wrong.

I agree, that the logic seems counter-intuitive. I was doing a quick test.

However, to ?keep the correct sequence, the logic inside the respective handlers need to be looked at.

If you see the patch series, this is relevant only for OMAP2,3. OMAP4 related IRQ handling is not yet introduced.
There would a different patch set which should set the correct irq handler for OMAP4.

Quoted 4 lines

Regards,
Raghuveer

#39 lore raw

PATCH v10 18/18 OMAP2,3: DSS2: Get DSS IRQ from platform device

In reply to Sumit Semwal

Hi,

Quoted 53 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

DSS IRQ number can be obtained from platform_get_irq(). This API in turn picks the right IRQ number belonging to HW IP from the hwmod database. So hardcoding of IRQ number could be removed.

---
 drivers/video/omap2/dss/dss.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)
drivers/video/omap2/dss/dss.c +13 -6
index 4d7a816..f9390b4 100644
@@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
 
 static int dss_init(bool skip_init)
 {
-	int r;
+	int r, dss_irq;
 	u32 rev;
 	struct resource *dss_mem;
 
@@ -609,11 +609,18 @@ static int dss_init(bool skip_init)
 	REG_FLD_MOD(DSS_CONTROL, 0, 2, 2);	/* venc clock mode = normal */
 #endif
 
-	r = request_irq(INT_24XX_DSS_IRQ,
-			cpu_is_omap24xx()
-			? dss_irq_handler_omap2
-			: dss_irq_handler_omap3,
-			0, "OMAP DSS", NULL);
+	dss_irq = platform_get_irq(dss.pdev, 0);
+	if (dss_irq < 0) {
+		DSSERR("omap2 dss: platform_get_irq failed\n");
+		r = -ENODEV;
+		goto fail1;
+	}
+
+	r = request_irq(dss_irq,
+		cpu_is_omap24xx()
+		? dss_irq_handler_omap2
+		: dss_irq_handler_omap3,
+		0, "OMAP DSS", NULL);
 
 	if (r < 0) {
 		DSSERR("omap2 dss: request_irq failed\n");

drivers/video/omap2/dss/dss.c static int dss_init(bool skip_init) · line 651

Quoted 5 lines
drivers/video/omap2/dss/dss.c +1 -1
@@ -641,7 +648,7 @@ static int dss_init(bool skip_init)
 	return 0;
 
 fail2:
-	free_irq(INT_24XX_DSS_IRQ, NULL);
+	free_irq(dss_irq, NULL);

You change this free_irq, as you should, but you missed another a few lines later.

Archit fixes it in his "OMAP: DSS2: Common IRQ handler for all OMAPs" patch silently, but I think it should be fixed here already, as the patches haven't been pulled to anywhere yet.

Perhaps you could use the same method as Archit used, create a new field "irq" in the dss struct which can be used in the dss_exit's free_irq call.

Tomi

#40 lore raw

PATCH v10 18/18 OMAP2, 3: DSS2: Get DSS IRQ from platform device

Hi,

Quoted 65 lines · Tomi Valkeinen

Hi,

Quoted 55 lines · ext Sumit Semwal

From: Senthilvadivu Guruswamy <[email protected]>

DSS IRQ number can be obtained from platform_get_irq(). ?This API in turn picks the right IRQ number belonging to HW IP from the hwmod database. So hardcoding of IRQ number could be removed.

---
?drivers/video/omap2/dss/dss.c | ? 21 ++++++++++++++------- ?1 files changed, 14 insertions(+), 7 deletions(-)

drivers/video/omap2/dss/dss.c +1 -1
index 4d7a816..f9390b4 100644
@@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
 
 ?static int dss_init(bool skip_init)
 ?{
- ? ? int r;
+ ? ? int r, dss_irq;
 ? ? ? u32 rev;
 ? ? ? struct resource *dss_mem;
 
@@ -609,11 +609,18 @@ static int dss_init(bool skip_init)

? ? ? REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); ? ? ?/* venc clock mode = normal */ ?#endif

- ? ? r = request_irq(INT_24XX_DSS_IRQ,
- ? ? ? ? ? ? ? ? ? ? cpu_is_omap24xx()
- ? ? ? ? ? ? ? ? ? ? ? dss_irq_handler_omap2
- ? ? ? ? ? ? ? ? ? ? : dss_irq_handler_omap3,
- ? ? ? ? ? ? ? ? ? ? 0, "OMAP DSS", NULL);
+ ? ? dss_irq = platform_get_irq(dss.pdev, 0);
+ ? ? if (dss_irq < 0) {
+ ? ? ? ? ? ? DSSERR("omap2 dss: platform_get_irq failed\n");
+ ? ? ? ? ? ? r = -ENODEV;
+ ? ? ? ? ? ? goto fail1;
+ ? ? }
+
+ ? ? r = request_irq(dss_irq,
+ ? ? ? ? ? ? cpu_is_omap24xx()
+ ? ? ? ? ? ? ? dss_irq_handler_omap2
+ ? ? ? ? ? ? : dss_irq_handler_omap3,
+ ? ? ? ? ? ? 0, "OMAP DSS", NULL);

? ? ? if (r < 0) {
? ? ? ? ? ? ? DSSERR("omap2 dss: request_irq failed\n");

drivers/video/omap2/dss/dss.c +0 -0
@@ -641,7 +648,7 @@ static int dss_init(bool skip_init)
 ? ? ? return 0;
 
Quoted 3 lines

?fail2:
- ? ? free_irq(INT_24XX_DSS_IRQ, NULL);
+ ? ? free_irq(dss_irq, NULL);

You change this free_irq, as you should, but you missed another a few lines later.

Quoted 7 lines

Archit fixes it in his "OMAP: DSS2: Common IRQ handler for all OMAPs" patch silently, but I think it should be fixed here already, as the patches haven't been pulled to anywhere yet.

Perhaps you could use the same method as Archit used, create a new field "irq" in the dss struct which can be used in the dss_exit's free_irq call.

Yes, you're right; I guess since it was already in your tree by the time we noticed this oversight, we assumed Archit could submit a new one. I can send you an updated one tomorrow for this.

Regards,
~Sumit.

Quoted 5 lines

?Tomi

#41 lore raw

v10 cover OMAP2,3: hwmod DSS Adaptation

In reply to Sumit Semwal
Quoted 3 lines · Sumit Semwal

v10 of the patch series corrects return-error handling from platform_request_irq() based on comments from Sergei Shtylyov and Russell King.
[https://patchwork.kernel.org/patch/497911/]

Tony,

Assuming Tomi is OK with this series, I think these are ready to go into omap-testing for some broader testing.

Kevin

Quoted 302 lines

v9 of this patch series adds reviewed-by and acked-by from Kevin Hilman.

v8 of the DSS hwmod patch series fixes some issues based on findings of Kevin Hilman on beagle.

The VENC platform driver was not getting registered due to missed device name update for vdda_dac regulator in some board files. This was moved from 'omap_display' device to 'omap_venc' device in patch 14/18.

Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs two instances - one for dpi, and one for dsi.

This version corrects the above two for all board files where 'vdda_dac' and 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18]

Post this change, boot w/ visible framebuffer and tux was successfully validated on beagle, 3430SDP and zoom3.

A patch mentioned in
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42384.html was needed to get OMAP3 to boot up on top of linux-next of 20110115.

OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design.

-------------------------------------------------
[original patch introduction]

This patch series decouples the "Clocks for DSS in hwmod adaptation" changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3.

Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling.

Summary of the hwmod DSS design:
================================
DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database.

Each of these platform drivers' init / deinit are handled from core.c's omap_dss_probe() in the exact sequence as required.

No Hardcoding of silicon data:
hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series.

Continue to have custom bus for display panels:
"omap_display" driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver)
For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o).

Clocks:
Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately.
For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK.

Current dss driver:
-------------------
1. Omapdss platform driver
- initialises necessary Ips dss, dispc.
- also initialises Ips like sdi, dsi, venc, rfbi
- creates a custom bus and registers the display devices/drivers connected on the board to the custom bus.

2. Suspend/resume of omapdss
- in turn sends suspend/resume calls for each of the display devices registered to it.

Modified change:
---------------
Platform driver for each DSS HW IP in addition to the software "omap_display" driver.

Omapdss platform driver
- initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, venc, rfbi] and software libraries like dpi, sdi.
- continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus.
- continues to handle suspend/resume of the display devices registered to the custom bus.

DSS platform driver
- initialises DSS IP alone
- Handles the clocks related to the DSS and other DSSHW IPs like RFBI, DSI, VENC, DISPC. Previously this was a part of "omapdss" driver in core.c
- Continues to handle the DSS IRQs.
- No suspend/resume hooks.

DISPC platform driver
- initialises DISPC IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.

DSI platform driver
- initialises DSI IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DSI library functions.

RFBI, VENC platform drivers
- initialises DSI,VENC IPs
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide RFBI and VENC library functions.

Testing:
---------
The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp.
For the rest of the mentioned platforms, kernel is built with "OMAP2_DSS" and bootup is tested so that base address and clk_get calls are successful.

DSS was built successfully as module, though not tested yet.

Changes since v6:
-----------------
* board-zoom-peripherals.c: Added missing change of device name from omapdss to omap_display. Found during testing on OMAP3630 on top of
Changes since v5:
----------------
1) Following review comments incorporated:
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42031.html
Make sure display.c is built when DSS is enabled built-in or as a module.
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42083.html
hwmod and omap_device headers moved to patch 8 when they're needed the first time.
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42094.html
- latency set to AUTO_ADJUST
- extra whitespaces removed.
- pdata memset to 0 before use.
- if omap_device_build fails, return error.
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42095.html
renamed *_deinit_* to *_uninit_*

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42171.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42172.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42173.html
- added L3 and L4 firewall related data,
- corrected handling of .idlest_idle_bit v/w .idlest_stdby_bit
- no .idlest_*_bit setting for dependent hwmods
- corrected .user to add SDMA
- renamed dss_dss to dss_core
- hwmod for 3430es1 and later 3xxx are separated out, with some reuse of data.
* Removed forced-disable of dss clocks from omap_dss_remove.

Changes since v4:
----------------
1) Following review comments incorporated:
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41970.html
Corrected the clocks to be enabled in omap_dss_probe.
Changes since v3:
----------------
1.) Following review comments incorporated:
* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41705.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41683.html
Created a new display.c file for dss driver registration related code.

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41573.html
Changed the oh_name/dev_name handling in hwmod usage.

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41753.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41718.html
removed device_initcall_sync(); init / deinit of each DSS h/w IP platform drivers are done from omap_dss_probe() in sequence.

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41754.html
clock patches were cleaned up as per review comments.

* http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41756.html
printk() => dev_dbg change was separated out.

Changes since v2:
-------------------
1.) Following review comments incorporated:
Split the device/driver name change and registration patches logically.
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41205.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41204.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41203.html

Changes since v1:
------------------
1.) Dynamically register for OMAP2,3 specific DSS HW IPs in devices.c 2.) Following review comments incorporated:
Updation of all the board files on l-o dss2 branch as per
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36915.html Comments incorporated in devices.c and display.h as per
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36919.html Comments incorporated in dispc.c, dss.c, dsi.c, venc.c, rfbi.c so that platform_device is just above platform_driver registrations as per
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36963.html
3.) Squashed some of the patches to one patch.

Changes since RFC:
-------------------
1) All the platform driver registration except DSS, were within the file core.c. Registeration of these driver got seperated to its own file.
2) Usage of regulators by different drivers are implemented.
For Eg: Regulator used by VENC is moved to venc driver. But vdda_dac would be needed by DPI and DSI as well.
4) OMAP2420 and OMAP2430 hwmod database are generated in this v1.
5) Module support for omapdss driver can continue as the DSS HW IP specific platform drivers are decoupled from omapdss driver.
6) Following review comments incorporated:
Changed the hwmod device name from "dss" to "dss_dss"
Changed name of core driver from "omapdss" to "omap_display" as it deals with panels. Fixed comments on return values from platform_get_resource/irq functions.

Patch Base:
===========
Patch-set rebased and tested w/ Zoom3 (OMAP3630) on top of:
url = git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch "master"
commit e8883f8057c0f7c9950fa9f20568f37bfa62f34a
Description: Add linux-next specific files for 20110115
+
Patch mentioned in http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42384.html [PATCH] OMAP: counter_32k: init clocksource as part of machine timer init

(This patch is required for OMAP bootup w/ 20110115 linux-next)

----------------------------------------------------------------------------

Senthilvadivu Guruswamy (15):
OMAP2420: hwmod data: add DSS DISPC RFBI VENC
OMAP2430: hwmod data: add DSS DISPC RFBI VENC
OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC
OMAP2,3 DSS2 Change driver name to omap_display
OMAP2,3 DSS2 Use Regulator init with driver name
OMAP2,3: DSS2: board files: replace platform_device_register with
omap_display_init()
OMAP2,3: DSS2: Build omap_device for each DSS HWIP OMAP2,3: DSS2: DSS: create platform_driver, move init,exit to driver OMAP2,3: DSS2: Move clocks from core driver to dss driver OMAP2,3: DSS2: RFBI: create platform_driver, move init,exit to driver OMAP2,3: DSS2: DISPC: create platform_driver, move init,exit to
driver
OMAP2,3: DSS2: VENC: create platform_driver, move init,exit to driver OMAP2,3: DSS2: DSI: create platform_driver, move init,exit to driver OMAP2,3: DSS2: Use platform device to get baseaddr OMAP2,3: DSS2: Get DSS IRQ from platform device

Sumit Semwal (3):
OMAP2,3: DSS2: remove forced clk-disable from omap_dss_remove OMAP2,3: DSS2: Create new file display.c for central dss driver
registration.
OMAP2,3: DSS2: replace printk with dev_dbg in init

 arch/arm/mach-omap2/Makefile                 |    3 +
 arch/arm/mach-omap2/board-3430sdp.c          |   26 +--
 arch/arm/mach-omap2/board-am3517evm.c        |   16 +-
 arch/arm/mach-omap2/board-cm-t35.c           |   22 +-
 arch/arm/mach-omap2/board-devkit8000.c       |   22 +-
 arch/arm/mach-omap2/board-igep0020.c         |   20 +-
 arch/arm/mach-omap2/board-omap3beagle.c      |   22 +-
 arch/arm/mach-omap2/board-omap3evm.c         |   30 +--
 arch/arm/mach-omap2/board-omap3pandora.c     |   17 +-
 arch/arm/mach-omap2/board-omap3stalker.c     |   26 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c |    4 +-
 arch/arm/mach-omap2/board-rx51-video.c       |   15 +-
 arch/arm/mach-omap2/board-zoom-display.c     |   15 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |   12 +-
 arch/arm/mach-omap2/clock2420_data.c         |    8 +-
 arch/arm/mach-omap2/clock2430_data.c         |    8 +-
 arch/arm/mach-omap2/clock3xxx_data.c         |   14 +-
 arch/arm/mach-omap2/display.c                |   96 ++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c   |  311 ++++++++++++++++++-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c   |  284 ++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c   |  433 +++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/display.h    |   16 +
 arch/arm/plat-omap/include/plat/l3_2xxx.h    |   20 ++
 arch/arm/plat-omap/include/plat/l3_3xxx.h    |   20 ++
 arch/arm/plat-omap/include/plat/l4_2xxx.h    |   24 ++
 arch/arm/plat-omap/include/plat/l4_3xxx.h    |   10 +
 drivers/video/omap2/dss/core.c               |  448 ++------------------------
 drivers/video/omap2/dss/dispc.c              |  114 ++++---
 drivers/video/omap2/dss/dsi.c                |   78 ++++-
 drivers/video/omap2/dss/dss.c                |  419 +++++++++++++++++++++++-
 drivers/video/omap2/dss/dss.h                |   46 ++--
 drivers/video/omap2/dss/rfbi.c               |  118 ++++---
 drivers/video/omap2/dss/venc.c               |  125 +++++---
 33 files changed, 2055 insertions(+), 787 deletions(-)
 create mode 100644 arch/arm/mach-omap2/display.c
 create mode 100644 arch/arm/plat-omap/include/plat/l3_2xxx.h
 create mode 100644 arch/arm/plat-omap/include/plat/l3_3xxx.h
 create mode 100644 arch/arm/plat-omap/include/plat/l4_2xxx.h
maintainer
#42 lore raw

v10 cover OMAP2,3: hwmod DSS Adaptation

Quoted 10 lines · Kevin Hilman
Quoted 3 lines · Sumit Semwal

v10 of the patch series corrects return-error handling from platform_request_irq() based on comments from Sergei Shtylyov and Russell King.
[https://patchwork.kernel.org/patch/497911/]

Tony,

Assuming Tomi is OK with this series, I think these are ready to go into omap-testing for some broader testing.

I can merge in Tomi's branch for testing once Tomi is happy with them.

Regards,

Tony

#43 lore raw

v10 cover OMAP2,3: hwmod DSS Adaptation

Quoted 7 lines · ext Tony Lindgren
Quoted 6 lines · Kevin Hilman
Quoted 3 lines · Sumit Semwal

v10 of the patch series corrects return-error handling from platform_request_irq() based on comments from Sergei Shtylyov and Russell King.
[https://patchwork.kernel.org/patch/497911/]

Quoted 6 lines
Quoted 4 lines

Tony,

Assuming Tomi is OK with this series, I think these are ready to go into omap-testing for some broader testing.

I can merge in Tomi's branch for testing once Tomi is happy with them.

I've applied the patch set to my tree:

git://gitorious.org/linux-omap-dss2/linux.git master

It compiles, but due to this being my last day in Nokia, I don't have equipment to test it. It's also missing my signed-offs.

I haven't been able to review the latest versions of the patch set, so these patches may not be the final versions. However, everything looked pretty good a few versions ago, so I don't expect any bigger changes.

It's up to Tony if he wants to merge the branch, even if it may not be the very final version. I will get back to these patches when my situation clears up, which may take a bit over a week or so.

Tomi