ARM: OMAP: omap_device: Add omap_device_{alloc, delete, register}_ss

Split omap_device_build_ss() into two smaller functions:
1. omap_device_alloc_ss() - allocates the omap_device and its associated pdev, but doesn't register the pdev yet
2. omap_device_register_ss() - registers the aforementioned pdev

In addition, a third omap_device_delete_ss() method is introduced in case omap_device_register_ss() fails.

This approach allows users, which need to manipulate an archdata member of a device before it is registered, to do so.

The immediate use case for this is to set the private iommu archdata member, which binds a device to its associated iommu controller. This way, generic code will be able to attach omap devices to their iommus, without calling any omap-specific API.

This patch is considered an interim solution until DT fully materializes for omap; at that point, this functionality will be removed.

Tested on OMAP4 with a generic remoteproc that doesn't use any omap-specific IOMMU API anymore.

---
Based on Kevin's for_3.2/omap_device-2 branch

 arch/arm/plat-omap/include/plat/omap_device.h |    9 ++
 arch/arm/plat-omap/omap_device.c              |  110 +++++++++++++++++++++----
 2 files changed, 104 insertions(+), 15 deletions(-)

index 12c5b0c..bc957d6 100644
@@ -100,6 +100,15 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 					 struct omap_device_pm_latency *pm_lats,
 					 int pm_lats_cnt, int is_early_device);
 
+struct platform_device *omap_device_alloc_ss(const char *pdev_name, int pdev_id,
+					 struct omap_hwmod **ohs, int oh_cnt,
+					 void *pdata, int pdata_len,
+					 struct omap_device_pm_latency *pm_lats,
+					 int pm_lats_cnt);
+
+void omap_device_delete_ss(struct platform_device *pdev);
+int omap_device_register_ss(struct platform_device *pdev, int is_early_device);
+
 void __iomem *omap_device_get_rt_va(struct omap_device *od);
 struct device *omap_device_get_by_hwmod_name(const char *oh_name);
 

1.7.4.1

Hi Kevin,

...

Good news: we might not need this after all.

I need the remoteproc devices to exists at ->reserve() time, so I can assign them a private CMA pool, which means I can't wait for omap_device_build_ss() and must create the devices beforehand.

... which makes Benoit's alloc/delete methods perfect for me.

So please hold this one off for now. I'd just need a s/static// patch that will allow me to use Benoit's methods outside of omap_device.c, but I'll wait for things to settle down a bit before sending it, to minimize this kind of churn.

Thanks and sorry for the noise,
Ohad.

Great.

OK. Sounds good.

Thanks,

Kevin