Thread (48 messages) 48 messages, 4 authors, 2012-05-10

Re: [PATCH 08/25] OMAPDSS: clean up the omapdss platform data mess

flat view

From: Tomi Valkeinen <hidden>
Date: 2012-05-04 08:32:00
Also in: linux-omap

On Fri, 2012-05-04 at 11:02 +0530, Archit Taneja wrote:
Hi,

On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:

- Remove struct omap_display_platform_data. It was used just as a
   wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
   dss hwmods do not need the platform data. This should also work better
   for DT, as we can create omapdss device programmatically in generic omap
   boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
   that the dss hwmod drivers can call.

Signed-off-by: Tomi Valkeinen<redacted>
---
  arch/arm/mach-omap2/display.c   |   39 +++++++++++++++++++--------------------
  drivers/video/omap2/dss/core.c  |   35 +++++++++++++++++++++++++++++++++++
  drivers/video/omap2/dss/dispc.c |   21 ++-------------------
  drivers/video/omap2/dss/dsi.c   |   17 +++--------------
  drivers/video/omap2/dss/dss.h   |    3 +++
  drivers/video/omap2/dss/hdmi.c  |    2 --
  include/video/omapdss.h         |    5 -----
  7 files changed, 62 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 60cded4..07232fd 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
  	struct omap_hwmod *oh;
  	struct platform_device *pdev;
  	int i, oh_count;
-	struct omap_display_platform_data pdata;
  	const struct omap_dss_hwmod_data *curr_dss_hwmod;

-	memset(&pdata, 0, sizeof(pdata));
+	/* create omapdss device */
+
+	board_data->dsi_enable_pads = omap_dsi_enable_pads;
+	board_data->dsi_disable_pads = omap_dsi_disable_pads;
+	board_data->get_context_loss_count = omap_pm_get_dev_context_loss_count;
+	board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;
+
+	omap_display_device.dev.platform_data = board_data;
+
+	r = platform_device_register(&omap_display_device);
+	if (r<  0) {
+		pr_err("Unable to register omapdss device\n");
+		return r;
+	}
After this patch, the "omapdss" platform device is registered before the 
other dss platform devices. This would change the sequence of probes of 
these devices. Was this intentional?
Hmm. The sequence shouldn't change. The order in which the devices are
registered doesn't matter if there are no drivers registered yet. When
the drivers are registered, and there's a device for it, the probe will
be done. So in this case the order of the driver registration will
dictate the order of probes.

 Tomi

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help