Thread (31 messages) flat view 31 messages, 6 authors, 2011-08-24
STALE5507d

Revision v1 of 8 in this series.

Revisions (8)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v1 current
  6. v1 [diff vs current]
  7. v1 [diff vs current]
  8. v2 [diff vs current]

[PATCH 1/7] omap: iommu: migrate to the generic IOMMU API

From: Roedel, Joerg <hidden>
Date: 2011-08-23 14:07:46
Also in: linux-omap

On Wed, Aug 17, 2011 at 07:10:02PM -0400, Ohad Ben-Cohen wrote:
+/**
+ * omap_iommu_attach() - attach iommu device to an iommu domain
+ * @dev:       target omap iommu device
+ * @iopgd:     page table
  **/
-struct iommu *iommu_get(const char *name)
+static struct iommu *omap_iommu_attach(struct device *dev, u32 *iopgd)
 {
        int err = -ENOMEM;
-       struct device *dev;
-       struct iommu *obj;
-
-       dev = driver_find_device(&omap_iommu_driver.driver, NULL, (void *)name,
-                                device_match_by_alias);
-       if (!dev)
-               return ERR_PTR(-ENODEV);
-
-       obj = to_iommu(dev);
+       struct iommu *obj = to_iommu(dev);

        mutex_lock(&obj->iommu_lock);
I don't think using a mutex here is a good idea. This prevents this
function to be called from atomic context. The iommu_map and _unmap
functions need to allowed in atomic-context and I don't want different
context constraints within the iommu-api. Can this be easily converted
to a spin_lock?

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help