diff options
author | Ohad Ben-Cohen <ohad@wizery.com> | 2012-02-20 17:43:29 (GMT) |
---|---|---|
committer | Tony Lindgren <tony@atomide.com> | 2012-02-20 18:00:39 (GMT) |
commit | 993e4fbd7822cdf874fcf9f1b054a323d67ccf97 (patch) | |
tree | eff8a45e979d7cf35ea332ea2b736de2f70218b0 /arch/arm/mach-omap2/board-omap3stalker.c | |
parent | d517110243130965e2803cc2373d434bdaf6dafb (diff) | |
download | linux-fsl-qoriq-993e4fbd7822cdf874fcf9f1b054a323d67ccf97.tar.xz |
ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}
Expose omap_device_{alloc, delete, register} so we can use them outside
of omap_device.c.
This approach allows users, which need to manipulate an archdata member
of a device before it is registered, to do so. This is also useful
for users who have their devices created very early so they can be used
at ->reserve() time to reserve CMA memory.
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.
With this in hand, we can further clean the existing mainline OMAP iommu
driver and its mainline users, and focus on generic IOMMU approaches
for future users (rpmsg/remoteproc and the upcoming generic DMA API).
This patch is still considered an interim solution until DT fully materializes
for omap; at that point, this functionality will be removed as DT will
take care of creating the devices and configuring them correctly.
Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any
omap-specific IOMMU API anymore.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Diffstat (limited to 'arch/arm/mach-omap2/board-omap3stalker.c')
0 files changed, 0 insertions, 0 deletions