Thread (116 messages) 116 messages, 4 authors, 2012-06-22

[PATCH v5 03/14] ARM: OMAP2+: gpmc: driver migration helper

flat view
STALE5234d SUPERSEDED

From: Mohammed, Afzal <hidden>
Date: 2012-06-12 07:09:58
Also in: linux-omap

Revision v5 of 14 in this series.

Revisions (14)
  1. v5
  2. v5
  3. v5 current
  4. v5
  5. v5
  6. v5
  7. v6 [diff vs current]
  8. v7 [diff vs current]
  9. v8 [diff vs current]
  10. v7 [diff vs current]
  11. v8 [diff vs current]
  12. v9 [diff vs current]
  13. v9 [diff vs current]
  14. v9 [diff vs current]
Hi Jon,

This change is required only till driver migration of all platforms
are done, after it, this hackish patch has to be reverted. This has
been done so that existing interface will work for each patch of
this series as well as till all boards are migrated.

On Tue, Jun 12, 2012 at 02:00:21, Hunter, Jon wrote:
quoted
 __init int omap_gpmc_init(struct gpmc_pdata *pdata)
 {
 	struct omap_hwmod *oh;
-	struct platform_device *pdev;
+	static struct platform_device *pdev;
 	char *name = "omap-gpmc";
 	char *oh_name = "gpmc";
 
@@ -912,6 +912,12 @@ __init int omap_gpmc_init(struct gpmc_pdata *pdata)
 		return -ENODEV;
 	}
 
+	if (pdev != NULL) {
+		clk_put(gpmc_l3_clk);
+		omap_device_delete(pdev->archdata.od);
+		platform_device_unregister(pdev);
+	}
+
I am not sure if I am missing something, but it appears that pdev will
always be NULL here as it is a local uninitialised variable.
omap_gpmc_init will be called by board files once again, at that time,
existing omap device will be destroyed (resulting in driver remove being
executed, and inverse of omap_device_build is not available, hence
doing circus as above). Again omap device will be created, this time
with details about gpmc peripherals (first time, there were no
peripheral details provided, and this was done for old interface to work
with same driver), once this happens new interface will starting it's job.

This kind of change was required as old interface works at arch_init


 > +static int __init gpmc_pre_init(void)
quoted
+{
+	static struct gpmc_device_pdata *gpmc_device_data[1];
+	struct gpmc_pdata gpmc_data = {
+		.device_pdata	= gpmc_device_data,
+	};
+
+	return omap_gpmc_init(&gpmc_data);
+}
+postcore_initcall(gpmc_pre_init);
+
Not sure I see the point in the above function. Why not declare the
gpmc_device_data struct as static in the file and access it directly
instead of passing it in omap_gpmc_init(). The postcore_init can then
call omap_gpmc_init() directly.
Can be done, but it is not necessary to make it available outside the
function
Shouldn't the post_initcall be added in patch #4, when the driver is
created?
As this has to be reverted once all boards has been migrated, this was
made separate.

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