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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday 04 May 2012 02:02 PM, Tomi Valkeinen wrote:
On Fri, 2012-05-04 at 11:02 +0530, Archit Taneja wrote:
Hi,

On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
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<tomi.valkeinen@xxxxxx>
---
   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.

Oh okay, I don't know where the initcalls exactly happen, but I guess they will happen after the .init_machine op in the board file.

Do you know where the initcalls happen, I couldn't find it by browsing the kernel code :)

Archit

  Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux