Samsung IOMMU videobuf2 allocator and s5p-fimc update

From: Andrzej Pietrasiewicz <[email protected]>

This patch performs a complete rewrite of sysmmu driver for Samsung platform:
- simplified the resource management: no more single platform device with 32 resources is needed, better fits into linux driver model, each sysmmu instance has it's own resource definition
- the new version uses kernel wide common iommu api defined in include/iommu.h
- cleaned support for sysmmu clocks
- added support for custom fault handlers and tlb replacement policy

arch/arm/plat-s5p/sysmmu.c +33 -0

+
+#define generic_extract(l, s, entry) \
+                               ((entry) & l##LPT_##s##_MASK)
+#define flpt_get_1m(entry)     generic_extract(F, 1M, deref_va(entry))
+#define flpt_get_16m(entry)    generic_extract(F, 16M, deref_va(entry))
+#define slpt_get_4k(entry)     generic_extract(S, 4K, deref_va(entry))
+#define slpt_get_64k(entry)    generic_extract(S, 64K, deref_va(entry))
+
+#define generic_entry(l, s, entry) \
+                               (generic_extract(l, s, entry)  | PAGE_##s)
+#define flpt_ent_4k_64k(entry) generic_entry(F, 4K_64K, entry)
+#define flpt_ent_1m(entry)     generic_entry(F, 1M, entry)
+#define flpt_ent_16m(entry)    generic_entry(F, 16M, entry)
+#define slpt_ent_4k(entry)     generic_entry(S, 4K, entry)
+#define slpt_ent_64k(entry)    generic_entry(S, 64K, entry)
+
+#define page_4k_64k(entry)     (deref_va(entry) & PAGE_4K_64K)
+#define page_1m(entry)         (deref_va(entry) & PAGE_1M)
+#define page_16m(entry)                ((deref_va(entry) & PAGE_16M) == PAGE_16M)
+#define page_4k(entry)         (deref_va(entry) & PAGE_4K)
+#define page_64k(entry)                (deref_va(entry) & PAGE_64K)
+
+#define generic_pg_offs(l, s, va) \
+                               (va & ~l##LPT_##s##_MASK)
+#define pg_offs_1m(va)         generic_pg_offs(F, 1M, va)
+#define pg_offs_16m(va)                generic_pg_offs(F, 16M, va)
+#define pg_offs_4k(va)         generic_pg_offs(S, 4K, va)
+#define pg_offs_64k(va)                generic_pg_offs(S, 64K, va)
+
+#define flpt_index(va)         (((va) >> FLPT_IDX_SHIFT) & FLPT_IDX_MASK)
+
+#define generic_offset(l, va)  (((va) >> l##LPT_OFFS_SHIFT) & l##LPT_OFFS_MASK)
+#define flpt_offs(va)          generic_offset(F, va)

+phys_addr_t s5p_iova_to_phys(struct iommu_domain *domain, unsigned long iova)

arch/arm/plat-s5p/sysmmu.c +12 -0

+struct device *s5p_sysmmu_get(enum s5p_sysmmu_ip ip)
+{
+       struct device *ret = NULL;
+       unsigned long flags;
+
+       spin_lock_irqsave(&sysmmu_slock, flags);
+       if (sysmmu_table[ip]) {
+               try_module_get(THIS_MODULE);
+               ret = sysmmu_table[ip]->dev;
+       }
+       spin_unlock_irqrestore(&sysmmu_slock, flags);
+

arch/arm/plat-s5p/sysmmu.c +6 -0

+void s5p_sysmmu_domain_irq_callb(struct iommu_domain *domain,
+                           struct s5p_sysmmu_irq_callb *ops, void *priv)
+{
+       struct s5p_sysmmu_domain *s5p_domain = domain->priv;
+       s5p_domain->irq_callb = ops;
+       s5p_domain->irq_callb_priv = priv;

arch/arm/plat-s5p/sysmmu.c +5 -0

+static void s5p_sysmmu_irq_page_fault(struct iommu_domain *domain, int reason,
+                                     unsigned long addr, void *priv)
+{
+       sysmmu_debug(3, "%s: Faulting virtual address: 0x%08lx\n",
+                    irq_reasons[reason], addr);

arch/arm/plat-s5p/sysmmu.c +66 -0

+static struct s5p_sysmmu_irq_callb s5p_sysmmu_irq_callb = {
+       .page_fault = s5p_sysmmu_irq_page_fault,
+       .ar_fault = s5p_sysmmu_irq_generic_callb,
+       .aw_fault = s5p_sysmmu_irq_generic_callb,
+       .bus_error = s5p_sysmmu_irq_generic_callb,
+       .ar_security = s5p_sysmmu_irq_generic_callb,
+       .ar_prot = s5p_sysmmu_irq_generic_callb,
+       .aw_security = s5p_sysmmu_irq_generic_callb,
+       .aw_prot = s5p_sysmmu_irq_generic_callb,
+};
+
+static irqreturn_t s5p_sysmmu_irq(int irq, void *dev_id)
+{
+       struct s5p_sysmmu_info *sysmmu = dev_id;
+       struct s5p_sysmmu_domain *s5p_domain = sysmmu->domain->priv;
+       unsigned int reg_INT_STATUS;
+
+       if (false == sysmmu->enabled)
+               return IRQ_HANDLED;
+
+       reg_INT_STATUS = readl(sysmmu->regs + S5P_INT_STATUS);
+       if (reg_INT_STATUS & 0xFF) {
+               S5P_IRQ_CB(cb);
+               enum s5p_sysmmu_fault reason = 0;
+               unsigned long fault = 0;
+               unsigned reg = 0;
+               cb = NULL;
+               switch (reg_INT_STATUS & 0xFF) {
+               case 0x1:
+                       cb = get_irq_callb(page_fault);
+                       reason = S5P_SYSMMU_PAGE_FAULT;
+                       reg = S5P_PAGE_FAULT_ADDR;
+                       break;
+               case 0x2:
+                       cb = get_irq_callb(ar_fault);
+                       reason = S5P_SYSMMU_AR_FAULT;
+                       reg = S5P_AR_FAULT_ADDR;
+                       break;
+               case 0x4:
+                       cb = get_irq_callb(aw_fault);
+                       reason = S5P_SYSMMU_AW_FAULT;
+                       reg = S5P_AW_FAULT_ADDR;
+                       break;
+               case 0x8:
+                       cb = get_irq_callb(bus_error);
+                       reason = S5P_SYSMMU_BUS_ERROR;
+                       /* register common to page fault and bus error */
+                       reg = S5P_PAGE_FAULT_ADDR;
+                       break;
+               case 0x10:
+                       cb = get_irq_callb(ar_security);
+                       reason = S5P_SYSMMU_AR_SECURITY;
+                       reg = S5P_AR_FAULT_ADDR;
+                       break;
+               case 0x20:
+                       cb = get_irq_callb(ar_prot);
+                       reason = S5P_SYSMMU_AR_PROT;
+                       reg = S5P_AR_FAULT_ADDR;
+                       break;
+               case 0x40:
+                       cb = get_irq_callb(aw_security);
+                       reason = S5P_SYSMMU_AW_SECURITY;
+                       reg = S5P_AW_FAULT_ADDR;
+                       break;
+               case 0x80:
+                       cb = get_irq_callb(aw_prot);

arch/arm/plat-s5p/sysmmu.c +18 -0

+static int
+s5p_sysmmu_suspend(struct platform_device *pdev, pm_message_t state)
+{
+       int ret = 0;
+       sysmmu_debug(3, "begin\n");
+
+       return ret;
+}
+
+static int s5p_sysmmu_resume(struct platform_device *pdev)
+{
+       int ret = 0;
+       sysmmu_debug(3, "begin\n");
+
+       return ret;
+}
+
+static int s5p_sysmmu_runtime_suspend(struct device *dev)

arch/arm/plat-s5p/sysmmu.c +17 -0

+static int __init
+s5p_sysmmu_register(void)
+{
+       int ret;
+
+       sysmmu_debug(3, "Registering sysmmu driver...\n");
+
+       slpt_cache = kmem_cache_create("slpt_cache", 1024, 1024,
+                                      SLAB_HWCACHE_ALIGN, NULL);
+       if (!slpt_cache) {
+               printk(KERN_ERR
+                       "%s: failed to allocated slpt cache\n", __func__);
+               return -ENOMEM;
+       }
+
+       ret = platform_driver_register(&s5p_sysmmu_driver);
+

Quoted 3 lines · Marek Szyprowski

From: Andrzej Pietrasiewicz <[email protected]>

This patch performs a complete rewrite of sysmmu driver for Samsung

platform:

Quoted 4 lines

- simplified the resource management: no more single platform device with 32 resources is needed, better fits into linux driver model, each sysmmu instance has it's own resource definition
- the new version uses kernel wide common iommu api defined in

include/iommu.h

Quoted 2 lines

- cleaned support for sysmmu clocks
- added support for custom fault handlers and tlb replacement policy

Looks like good progress, but I fear that there is still quite a bit more work needed here.

Quoted 12 lines

arch/arm/plat-s5p/sysmmu.c +12 -0

+struct device *s5p_sysmmu_get(enum s5p_sysmmu_ip ip)
+{
+       struct device *ret = NULL;
+       unsigned long flags;
+
+       spin_lock_irqsave(&sysmmu_slock, flags);
+       if (sysmmu_table[ip]) {
+               try_module_get(THIS_MODULE);
+               ret = sysmmu_table[ip]->dev;
+       }
+       spin_unlock_irqrestore(&sysmmu_slock, flags);
+

arch/arm/plat-s5p/sysmmu.c line 561

Quoted 10 lines

arch/arm/plat-s5p/sysmmu.c +10 -0

+       return ret;
+}
+EXPORT_SYMBOL_GPL(s5p_sysmmu_get);
+
+void s5p_sysmmu_put(void *dev)
+{
+       BUG_ON(!dev);
+       module_put(THIS_MODULE);
+}
+EXPORT_SYMBOL_GPL(s5p_sysmmu_put);

These look wrong for a number of reasons:

* try_module_get(THIS_MODULE) makes no sense at all, the idea of the try_module_get is to pin down another module that was calling down, which I suppose is not needed here.

* This extends the generic IOMMU API in platform specific ways, don't do that.

* I think you can do without these functions by including a pointer to the iommu structure in dev_archdata, see arch/powerpc/include/asm/device.h for an example.

Quoted 22 lines

arch/arm/plat-s5p/sysmmu.c +22 -0

+static int
+s5p_sysmmu_suspend(struct platform_device *pdev, pm_message_t state)
+{
+       int ret = 0;
+       sysmmu_debug(3, "begin\n");
+
+       return ret;
+}
+
+static int s5p_sysmmu_resume(struct platform_device *pdev)
+{
+       int ret = 0;
+       sysmmu_debug(3, "begin\n");
+
+       return ret;
+}
+
+static int s5p_sysmmu_runtime_suspend(struct device *dev)
+{
+       sysmmu_debug(3, "begin\n");
+       return 0;
+}

arch/arm/plat-s5p/sysmmu.c line 819

Quoted 6 lines

arch/arm/plat-s5p/sysmmu.c +6 -0

+
+static int s5p_sysmmu_runtime_resume(struct device *dev)
+{
+       sysmmu_debug(3, "begin\n");
+       return 0;
+}

Why even provide these when they don't do anything?

arch/arm/plat-s5p/sysmmu.c

Quoted 12 lines

arch/arm/plat-s5p/sysmmu.c +12 -0

+static int __init
+s5p_sysmmu_register(void)
+{
+       int ret;
+
+       sysmmu_debug(3, "Registering sysmmu driver...\n");
+
+       slpt_cache = kmem_cache_create("slpt_cache", 1024, 1024,
+                                      SLAB_HWCACHE_ALIGN, NULL);
+       if (!slpt_cache) {
+               printk(KERN_ERR
+                       "%s: failed to allocated slpt cache\n",

__func__);

arch/arm/plat-s5p/sysmmu.c

Quoted 8 lines

arch/arm/plat-s5p/sysmmu.c +8 -0

+               return -ENOMEM;
+       }
+
+       ret = platform_driver_register(&s5p_sysmmu_driver);
+
+       if (ret) {
+               printk(KERN_ERR
+                       "%s: failed to register sysmmu driver\n",

__func__);

arch/arm/plat-s5p/sysmmu.c line 864

Quoted 7 lines

arch/arm/plat-s5p/sysmmu.c +7 -0

+               return -EINVAL;
+       }
+
+       register_iommu(&s5p_sysmmu_ops);
+
+       return ret;
+}

When you register the iommu unconditionally, it becomes impossible for this driver to coexist with other iommu drivers in the same kernel, which does against the concept of having a platform driver for this.

It might be better to call the s5p_sysmmu_register function from the board files and have no platform devices at all if each IOMMU is always bound to a specific device anyway.

arch/arm/plat-

Quoted 1 line

arch/arm/plat- renamed from arch/arm/plat-samsung/include/plat/devs.h +0 -0

samsung/include/plat/devs.h

Quoted 7 lines

index f0da6b7..0ae5dd0 100644

arch/arm/plat-samsung/include/plat/devs.h +0 -0

@@ -142,7 +142,7 @@ extern struct platform_device s5p_device_fimc3;
 extern struct platform_device s5p_device_mipi_csis0;
 extern struct platform_device s5p_device_mipi_csis1;
 

arch/arm/plat-samsung/include/plat/devs.h extern struct platform_device s5p_device_fimc3; · line 145

Quoted 2 lines

arch/arm/plat-samsung/include/plat/devs.h +1 -1

-extern struct platform_device exynos4_device_sysmmu;
+extern struct platform_device exynos4_device_sysmmu[];

Why is this a global variable? I would expect this to be private to the implementation.

Quoted 6 lines

These look wrong for a number of reasons:

* try_module_get(THIS_MODULE) makes no sense at all, the idea of the try_module_get is to pin down another module that was calling down, which I suppose is not needed here.

Quoted 6 lines

* This extends the generic IOMMU API in platform specific ways, don't do that.

* I think you can do without these functions by including a pointer to the iommu structure in dev_archdata, see arch/powerpc/include/asm/device.h for an example.

We heavily based our solution on the iommu implementation found in arch/arm/mach-msm/{devices-iommu,iommu,iommu_dev}.c

The s5p_sysmmu_get/put functions are equivalent for msm_iommu_{get,put}_ctx.

(snipped)

Quoted 1 line

Why even provide these when they don't do anything?

Because they are required by pm_runtime. If no runtime_{suspend,resume} methods are provided, the pm_runtime core will not call proper methods on parent device for pmruntime_{get,put}_sync(). The parent device for each sysmmu platform device is the power domain the sysmmu belongs to.

I know this is crazy, but this is the only way it can be handled now with runtime_pm.

Quoted 3 lines

When you register the iommu unconditionally, it becomes impossible for this driver to coexist with other iommu drivers in the same kernel, which does against the concept of having a platform driver for this.

Quoted 3 lines

It might be better to call the s5p_sysmmu_register function from the board files and have no platform devices at all if each IOMMU is always bound to a specific device anyway.

Ok, it looks I don't fully get how this iommu.h should be used. It looks that there can be only one instance of iommu ops registered in the system, so only one iommu driver can be activated. You are right that the iommu driver has to be registered on first probe().

I think it might be beneficial to describe a bit more our hardware (Exynos4 platform). There are a number of multimedia blocks. Each has it's own IOMMU controller. Each IOMMU controller has his own set of hardware registers and irq. There is also a GPU unit (Mali) which has it's own IOMMU hardware, incompatible with the SYSMMU, so right now it is ignored.

The multimedia blocks are modeled as platform devices and are independent of platform type (same multimedia blocks can be found on other Samsung machines, like for example s5pv210/s5pc110), see arch/arm/plat-s5p/dev-*.c and arch/arm/plat-samsung/dev-*.c.

Platform driver data defined in the above files are registered by each board startup code, usually by platform_add_devices(), for more details please check arch/arm/mach-s5pv210/mach-goni.c. There is struct platform_device *goni_devices[] array which get registered in the last line in goni_machine_init() function.

For IOMMU controllers on Exynos4 we created an array of platform devices:
extern struct platform_device exynos4_device_sysmmu[];

Now the board startup code registers only these sysmmu controllers (instances) that are required on the particular board. See "[PATCH 7/7]
ARM: EXYNOS4: enable FIMC on Universal_C210":

(quoted diff) +9 -0

@@ -613,6 +616,15 @@ static struct platform_device *universal_devices[]
 __initdata = {
        &s3c_device_hsmmc2,
        &s3c_device_hsmmc3,
        &s3c_device_i2c5,
+       &s5p_device_fimc0,
+       &s5p_device_fimc1,
+       &s5p_device_fimc2,
+       &s5p_device_fimc3,
+       &exynos4_device_pd[PD_CAM],
+       &exynos4_device_sysmmu[S5P_SYSMMU_FIMC0],
+       &exynos4_device_sysmmu[S5P_SYSMMU_FIMC1],
+       &exynos4_device_sysmmu[S5P_SYSMMU_FIMC2],
+       &exynos4_device_sysmmu[S5P_SYSMMU_FIMC3],
 

We need to map the above structure into linux/iommu.h api.

The domain defined in iommu api are quite straightforward. Each domain is just a set of mappings between physical addresses (phys) and io addresses (iova).

For the drivers the most important are the following functions:
iommu_{attach,detach}_device(struct iommu_domain *domain, struct device *dev);

We assumed that they just assign the domain (mapping) to particular instance of iommu. However the driver need to get somehow the pointer to the iommu instance. That's why we added the s5p_sysmmu_{get,put} functions.

Now I see that you want to make the clients (drivers) to provide their own struct device pointer to the iommu_{attach,detach}_device() function instead of giving there a pointer to iommu device. Am I right? We will need some kind of mapping between multimedia devices and particular instanced of sysmmu controllers.

There will be also some problems with such approach. Mainly we have a multimedia codec module, which have 2 memory controllers (for faster transfers) and 2 iommu controllers. How can we handle such case?

Quoted 9 lines

arch/arm/plat-

Quoted 1 line

arch/arm/plat- renamed from arch/arm/plat-samsung/include/plat/devs.h +0 -0

samsung/include/plat/devs.h

Quoted 7 lines

index f0da6b7..0ae5dd0 100644

arch/arm/plat-samsung/include/plat/devs.h +0 -0

@@ -142,7 +142,7 @@ extern struct platform_device s5p_device_fimc3;
 extern struct platform_device s5p_device_mipi_csis0;
 extern struct platform_device s5p_device_mipi_csis1;
 

Quoted 5 lines

arch/arm/plat-samsung/include/plat/devs.h extern struct platform_device s5p_device_fimc3; · line 145

Quoted 2 lines

arch/arm/plat-samsung/include/plat/devs.h +1 -1

-extern struct platform_device exynos4_device_sysmmu;
+extern struct platform_device exynos4_device_sysmmu[];

Why is this a global variable? I would expect this to be private to the implementation.

To allow each board to register only particular instances of sysmmu controllers.

(adding Joerg to Cc)

Quoted 2 lines · Marek Szyprowski

Quoted 2 lines

* This extends the generic IOMMU API in platform specific ways, don't do that.

Quoted 4 lines

Ok, it looks I don't fully get how this iommu.h should be used. It looks that there can be only one instance of iommu ops registered in the system, so only one iommu driver can be activated. You are right that the iommu driver has to be registered on first probe().

That is a limitation of the current implementation. We might want to change that anyway, e.g. to handle the mali IOMMU along with yours. I believe the reason for allowing only one IOMMU type so far has been that nobody required more than one. As I mentioned, the IOMMU API is rather new and has not been ported to much variety of hardware, unlike the dma-mapping API, which does support multiple different IOMMUs in a single system.

Quoted 10 lines

I think it might be beneficial to describe a bit more our hardware (Exynos4 platform). There are a number of multimedia blocks. Each has it's own IOMMU controller. Each IOMMU controller has his own set of hardware registers and irq. There is also a GPU unit (Mali) which has it's own IOMMU hardware, incompatible with the SYSMMU, so right now it is ignored.

The multimedia blocks are modeled as platform devices and are independent of platform type (same multimedia blocks can be found on other Samsung machines, like for example s5pv210/s5pc110), see arch/arm/plat-s5p/dev-*.c and arch/arm/plat-samsung/dev-*.c.

Quoted 3 lines

The domain defined in iommu api are quite straightforward. Each domain is just a set of mappings between physical addresses (phys) and io addresses (iova).

Quoted 2 lines

For the drivers the most important are the following functions:
iommu_{attach,detach}_device(struct iommu_domain *domain, struct device *dev);

Quoted 3 lines

We assumed that they just assign the domain (mapping) to particular instance of iommu. However the driver need to get somehow the pointer to the iommu instance. That's why we added the s5p_sysmmu_{get,put} functions.

It's not quite how the domains are meant to be used. In the AMD IOMMU that the API is based on, any number of devices can share one domain, and devices might be able to have mappings in multiple domains.

Quoted 5 lines · Arnd Bergmann

Quoted 4 lines

Ok, it looks I don't fully get how this iommu.h should be used. It looks that there can be only one instance of iommu ops registered in the system, so only one iommu driver can be activated. You are right that the iommu driver has to be registered on first probe().

Quoted 7 lines

That is a limitation of the current implementation. We might want to change that anyway, e.g. to handle the mali IOMMU along with yours. I believe the reason for allowing only one IOMMU type so far has been that nobody required more than one. As I mentioned, the IOMMU API is rather new and has not been ported to much variety of hardware, unlike the dma-mapping API, which does support multiple different IOMMUs in a single system.

The current IOMMU-API interface is very simple. It delegates the selection of the particular IOMMU device to the IOMMU driver. Handle this selection above the IOMMU driver is a complex thing to do. We will need some kind of generic IOMMU support in the device-core and attach IOMMUs to device sub-trees.

A simpler and less intrusive solution is to implement some wrapper code which dispatches the IOMMU-API calls to the IOMMU driver implementation required for that device.

Quoted 6 lines

Quoted 6 lines

I think it might be beneficial to describe a bit more our hardware (Exynos4 platform). There are a number of multimedia blocks. Each has it's own IOMMU controller. Each IOMMU controller has his own set of hardware registers and irq. There is also a GPU unit (Mali) which has it's own IOMMU hardware, incompatible with the SYSMMU, so right now it is ignored.

Quoted 4 lines

Quoted 4 lines

The multimedia blocks are modeled as platform devices and are independent of platform type (same multimedia blocks can be found on other Samsung machines, like for example s5pv210/s5pc110), see arch/arm/plat-s5p/dev-*.c and arch/arm/plat-samsung/dev-*.c.

Question: Does every platform device has a different type of IOMMU? Or are the IOMMUs on all of these platform devices similar enough to be handled by a single driver?

Quoted 2 lines

Quoted 2 lines

For the drivers the most important are the following functions:
iommu_{attach,detach}_device(struct iommu_domain *domain, struct device *dev);

Right, and each driver can allocate its own domains.

Quoted 3 lines

It's not quite how the domains are meant to be used. In the AMD IOMMU that the API is based on, any number of devices can share one domain, and devices might be able to have mappings in multiple domains.

Yes, any number of devices can be assigned to one domain, but each device only belongs to one domain at each point in time. But it is possible to detach a device from one domain and attach it to another.

Quoted 20 lines · Joerg

Quoted 5 lines · Arnd Bergmann

Quoted 4 lines

Ok, it looks I don't fully get how this iommu.h should be used. It looks that there can be only one instance of iommu ops registered in the system, so only one iommu driver can be activated. You are right that the iommu driver has to be registered on first probe().

Quoted 7 lines

That is a limitation of the current implementation. We might want to change that anyway, e.g. to handle the mali IOMMU along with yours. I believe the reason for allowing only one IOMMU type so far has been that nobody required more than one. As I mentioned, the IOMMU API is rather new and has not been ported to much variety of hardware, unlike the dma-mapping API, which does support multiple different IOMMUs in a single system.

The current IOMMU-API interface is very simple. It delegates the selection of the particular IOMMU device to the IOMMU driver. Handle this selection above the IOMMU driver is a complex thing to do. We will need some kind of generic IOMMU support in the device-core and attach IOMMUs to device sub-trees.

Quoted 3 lines

A simpler and less intrusive solution is to implement some wrapper code which dispatches the IOMMU-API calls to the IOMMU driver implementation required for that device.

Right. We already do that for the dma-mapping API on some architectures, and I suppose we can consolidate the mechanism here, possibly into something that ends up in the common struct device rather than in the archdata.

Quoted 3 lines

Question: Does every platform device has a different type of IOMMU? Or are the IOMMUs on all of these platform devices similar enough to be handled by a single driver?

As Marek explained in the thread before you got on Cc, they are all the same, except for the graphics core (Mali) that has a different one but currently disables that.

Quoted 4 lines

Quoted 2 lines

Quoted 2 lines

For the drivers the most important are the following functions:
iommu_{attach,detach}_device(struct iommu_domain *domain, struct device *dev);

Right, and each driver can allocate its own domains.

For the cases that use the normal dma-mapping API, I guess there only needs to be one domain to cover the kernel, which can then be hidden in the driver provides the dma_map_ops based on an iommu_ops.

Quoted 4 lines

Quoted 3 lines

It's not quite how the domains are meant to be used. In the AMD IOMMU that the API is based on, any number of devices can share one domain, and devices might be able to have mappings in multiple domains.

Quoted 3 lines

Yes, any number of devices can be assigned to one domain, but each device only belongs to one domain at each point in time. But it is possible to detach a device from one domain and attach it to another.

I was thinking of the SR-IOV case, where a single hardware device is represented as multiple logical devices. As far as I understand, each logical devices can only belong to one domain, but they don't all have to be the same.

Quoted 9 lines · Marek Szyprowski

Quoted 9 lines

These look wrong for a number of reasons:

* try_module_get(THIS_MODULE) makes no sense at all, the idea of the try_module_get is to pin down another module that was calling down, which I suppose is not needed here.

* This extends the generic IOMMU API in platform specific ways, don't do that.

Quoted 8 lines

Quoted 3 lines

* I think you can do without these functions by including a pointer to the iommu structure in dev_archdata, see arch/powerpc/include/asm/device.h for an example.

We heavily based our solution on the iommu implementation found in arch/arm/mach-msm/{devices-iommu,iommu,iommu_dev}.c

The s5p_sysmmu_get/put functions are equivalent for

msm_iommu_{get,put}_ctx.

Quoted 2 lines

(snipped)

Yes, I'm sorry about this. I commented on the early versions of the MSM driver, but then did not do another review of the version that actually got merged. That should also be fixed, ideally we can come up with a way that works for both drivers.

Quoted 9 lines

Quoted 1 line

Why even provide these when they don't do anything?

Because they are required by pm_runtime. If no runtime_{suspend,resume} methods are provided, the pm_runtime core will not call proper methods on parent device for pmruntime_{get,put}_sync(). The parent device for each sysmmu platform device is the power domain the sysmmu belongs to.

I know this is crazy, but this is the only way it can be handled now with runtime_pm.

Please don't try to work around kernel features when they don't fit what you are doing. The intent of the way that runtime_pm works is to make life easier for driver writers, not harder ;-)

I can see three ways that would be better solutions:

1. change the runtime_pm subsystem to allow it to ignore some devices in an easy way.

2. change the device layout if the sysmmu. If the iommu device is a child of the device that it is responsible for, I guess you don't have this problem.

3. Not represent the iommu as a device at all, just as a property of another device.

Quoted 4 lines

Quoted 3 lines

When you register the iommu unconditionally, it becomes impossible for this driver to coexist with other iommu drivers in the same kernel, which does against the concept of having a platform driver for this.

Quoted 8 lines

Quoted 3 lines

It might be better to call the s5p_sysmmu_register function from the board files and have no platform devices at all if each IOMMU is always bound to a specific device anyway.

Ok, it looks I don't fully get how this iommu.h should be used. It looks that there can be only one instance of iommu ops registered in the system, so only one iommu driver can be activated. You are right that the iommu driver has to be registered on first probe().

That is a limitation of the current implementation. We might want to change that anyway, e.g. to handle the mali IOMMU along with yours. I believe the reason for allowing only one IOMMU type so far has been that nobody required more than one. As I mentioned, the IOMMU API is rather new and has not been ported to much variety of hardware, unlike the dma-mapping API, which does support multiple different IOMMUs in a single system.

Quoted 2 lines

The domain defined in iommu api are quite straightforward. Each domain is just a set of mappings between physical addresses (phys) and io

addresses

Quoted 4 lines

(iova).

For the drivers the most important are the following functions:
iommu_{attach,detach}_device(struct iommu_domain *domain, struct device

*dev);

Quoted 2 lines

We assumed that they just assign the domain (mapping) to particular

instance

Quoted 4 lines

of iommu. However the driver need to get somehow the pointer to the iommu instance. That's why we added the s5p_sysmmu_{get,put} functions.

Now I see that you want to make the clients (drivers) to provide their

own

Quoted 1 line

struct device pointer to the iommu_{attach,detach}_device() function

instead of

Quoted 1 line

giving there a pointer to iommu device. Am I right? We will need some

kind of

Quoted 5 lines

mapping between multimedia devices and particular instanced of sysmmu controllers.

There will be also some problems with such approach. Mainly we have a multimedia codec module, which have 2 memory controllers (for faster

transfers)

Quoted 1 line

and 2 iommu controllers. How can we handle such case?

It's not quite how the domains are meant to be used. In the AMD IOMMU that the API is based on, any number of devices can share one domain, and devices might be able to have mappings in multiple domains.

The domain really reflects the user, not the device here, which makes more sense if you think of virtual machines than of multimedia devices.

I would suggest that you just use a single iommu_domain globally for all in-kernel users.

Quoted 1 line

Quoted 1 line

Review

Quoted 1 line

(quoted diff) +0 -0

b/arch/arm/plat-

Quoted 14 lines

Quoted 13 lines

samsung/include/plat/devs.h

arch/arm/plat-samsung/include/plat/devs.h extern struct platform_device s5p_device_fimc3; · line 145

Quoted 9 lines

index f0da6b7..0ae5dd0 100644

arch/arm/plat-samsung/include/plat/devs.h +1 -1

@@ -142,7 +142,7 @@ extern struct platform_device s5p_device_fimc3;
 extern struct platform_device s5p_device_mipi_csis0;
 extern struct platform_device s5p_device_mipi_csis1;
 
-extern struct platform_device exynos4_device_sysmmu;
+extern struct platform_device exynos4_device_sysmmu[];

Why is this a global variable? I would expect this to be private to the implementation.

Quoted 1 line

To allow each board to register only particular instances of sysmmu

controllers.

That sounds like an unnecessarily complicated way of doing it. This would be another reason to not make each one a device, but have something else in struct device take care of it.

Quoted 8 lines

1. change the runtime_pm subsystem to allow it to ignore some devices in an easy way.

2. change the device layout if the sysmmu. If the iommu device is a child of the device that it is responsible for, I guess you don't have this problem.

Quoted 2 lines

3. Not represent the iommu as a device at all, just as a property of another device.

Ok, we will handle this issue somehow. I consider this a minor issue and I would like to focus on the IOMMU/dma-mapping APIs first.

Quoted 7 lines

That is a limitation of the current implementation. We might want to change that anyway, e.g. to handle the mali IOMMU along with yours. I believe the reason for allowing only one IOMMU type so far has been that nobody required more than one. As I mentioned, the IOMMU API is rather new and has not been ported to much variety of hardware, unlike the dma-mapping API, which does support multiple different IOMMUs in a single system.

Ok. I understand. IOMMU API is quite nice abstraction of the IOMMU chip. dma-mapping API is something much more complex that creates the actual mapping for various sets of the devices. IMHO the right direction will be to create dma-mapping implementation that will be just a client of the IOMMU API. What's your opinion?

Quoted 5 lines

The domain really reflects the user, not the device here, which makes more sense if you think of virtual machines than of multimedia devices.

I would suggest that you just use a single iommu_domain globally for all in-kernel users.

There are cases where having a separate mapping for each device makes sense. It definitely increases the security and helps to find some bugs in the drivers.

Getting back to our video codec - it has 2 IOMMU controllers. The codec hardware is able to address only 256MiB of space. Do you have an idea how this can be handled with dma-mapping API? The only idea that comes to my mind is to provide a second, fake 'struct device' and use it for allocations for the second IOMMU controller.

Quoted 8 lines

Quoted 7 lines

That is a limitation of the current implementation. We might want to change that anyway, e.g. to handle the mali IOMMU along with yours. I believe the reason for allowing only one IOMMU type so far has been that nobody required more than one. As I mentioned, the IOMMU API is rather new and has not been ported to much variety of hardware, unlike the dma-mapping API, which does support multiple different IOMMUs in a single system.

Quoted 5 lines

Ok. I understand. IOMMU API is quite nice abstraction of the IOMMU chip. dma-mapping API is something much more complex that creates the actual mapping for various sets of the devices. IMHO the right direction will be to create dma-mapping implementation that will be just a client of the IOMMU API. What's your opinion?

Sounds good. I think we should put it into a new drivers/iommu, along with your specific iommu implementation, and then we can convert the existing ones over to use that.

Note that this also requires using dma-mapping-common.h, which we currently don't on ARM.

Quoted 1 line

Quoted 1 line

The domain really reflects the user, not the device here, which makes

more

Quoted 6 lines

Quoted 4 lines

sense if you think of virtual machines than of multimedia devices.

I would suggest that you just use a single iommu_domain globally for all in-kernel users.

There are cases where having a separate mapping for each device makes

sense.

Quoted 7 lines

It definitely increases the security and helps to find some bugs in the drivers.

Getting back to our video codec - it has 2 IOMMU controllers. The codec hardware is able to address only 256MiB of space. Do you have an idea how this can be handled with dma-mapping API? The only idea that comes to my mind is to provide a second, fake 'struct device' and use it for

allocations

Quoted 1 line

for the second IOMMU controller.

Good question.

How do you even decide which controller to use from the driver? I would need to understand better what you are trying to do to give a good recommendation.

Quoted 3 lines · Arnd Bergmann

Sounds good. I think we should put it into a new drivers/iommu, along with your specific iommu implementation, and then we can convert the existing ones over to use that.

I see, this sounds quite reasonable. I think I finally got how this should be implemented.

The only question is how a device can allocate a buffer that will be most convenient for IOMMU mapping (i.e. will require least entries to map)?

IOMMU can create a contiguous mapping for ANY set of pages, but it performs much better if the pages are grouped into 64KiB or 1MiB areas.

Can device allocate a buffer without mapping it into kernel space?

The problem that still left to be resolved is the fact the dma_coherent_alloc() should also be able to use IOMMU. This would however trigger the problem of double mappings with different cache attributes:
dma api might require to create coherent (==non-cached mappings), while all low-memory is still mapped with (super)sections as cached, what is against ARM CPU specification and might cause unpredicted behavior especially on CPUs that do speculative prefetch. Right now this problem has been ignored in dma-mappings implementation, but there have been some patches posted to resolve this by reserving some area exclusively for dma coherent mappings:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/100822/focus=100913

Right now I would like to postpone resolving this issue because the Samsung iommu task already became really big.

Quoted 4 lines

Quoted 4 lines

Getting back to our video codec - it has 2 IOMMU controllers. The codec hardware is able to address only 256MiB of space. Do you have an idea how this can be handled with dma-mapping API? The only idea that comes to my mind is to provide a second, fake 'struct device' and use it for

Quoted 8 lines

allocations

Quoted 1 line

for the second IOMMU controller.

Good question.

How do you even decide which controller to use from the driver? I would need to understand better what you are trying to do to give a good recommendation.

Both controllers are used by the hardware depending on the buffer type. For example, buffers with chroma video data are accessed by first (called 'left') memory channel, the others (with luma video data) - by the second channel (called 'right'). Each memory channel is limited to 256MiB address space and best performance is achieved when buffers are allocated in separate physical memory banks (the boards usually have 2 or more memory banks, memory is not interleaved).

Quoted 7 lines · Marek Szyprowski

Quoted 3 lines · Arnd Bergmann

Sounds good. I think we should put it into a new drivers/iommu, along with your specific iommu implementation, and then we can convert the existing ones over to use that.

I see, this sounds quite reasonable. I think I finally got how this

should

Quoted 6 lines

be implemented.

The only question is how a device can allocate a buffer that will be most convenient for IOMMU mapping (i.e. will require least entries to map)?

IOMMU can create a contiguous mapping for ANY set of pages, but it

performs

Quoted 3 lines

much better if the pages are grouped into 64KiB or 1MiB areas.

Can device allocate a buffer without mapping it into kernel space?

Not today as far as I know. You can register coherent memory per device using dma_declare_coherent_memory(), which will be used to back dma_alloc_coherent(), but I believe it is always mapped right now.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Getting back to our video codec - it has 2 IOMMU controllers. The

codec

Quoted 1 line

Quoted 1 line

Quoted 1 line

hardware is able to address only 256MiB of space. Do you have an idea

how

Quoted 1 line

Quoted 1 line

Quoted 1 line

this can be handled with dma-mapping API? The only idea that comes to

my

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

mind is to provide a second, fake 'struct device' and use it for

allocations

Quoted 1 line

for the second IOMMU controller.

Good question.

Quoted 8 lines

Quoted 3 lines

How do you even decide which controller to use from the driver? I would need to understand better what you are trying to do to give a good recommendation.

Both controllers are used by the hardware depending on the buffer type. For example, buffers with chroma video data are accessed by first (called 'left') memory channel, the others (with luma video data) - by the second channel (called 'right'). Each memory channel is limited to 256MiB

address

Quoted 2 lines

space and best performance is achieved when buffers are allocated in separate physical memory banks (the boards usually have 2 or more memory

banks,

Quoted 1 line

memory is not interleaved).

Ok, I see. Having one device per channel as you suggested could probably work around this, and it's at least consistent with how you'd represent IOMMUs in the device tree. It is not ideal because it makes the video driver more complex when it now has to deal with multiple struct device that it binds to, but I can't think of any nicer way either.

Quoted 4 lines · Arnd Bergmann

Quoted 3 lines · Marek Szyprowski

The only question is how a device can allocate a buffer that will be most convenient for IOMMU mapping (i.e. will require least entries to map)?

Quoted 8 lines

Quoted 4 lines

IOMMU can create a contiguous mapping for ANY set of pages, but it performs much better if the pages are grouped into 64KiB or 1MiB areas.

Can device allocate a buffer without mapping it into kernel space?

Not today as far as I know. You can register coherent memory per device using dma_declare_coherent_memory(), which will be used to back dma_alloc_coherent(), but I believe it is always mapped right now.

This is not exactly what I meant.

As we have IOMMU, the device driver can access any system memory. However the performance will be better if the buffer is composed of larger contiguous parts (like 64KiB or 1MiB). I would like to avoid putting logic that manages buffer allocation into the device drivers. It would be best if such buffers could be allocated by a single call to dma-mapping API.

Right now there is dma_alloc_coherent() function, which is used by the drivers to allocate a contiguous block of memory and map it to DMA addresses. With IOMMU implementation it is quite easy to provide a replacement for it that will allocate some set of pages and map into device virtual address space as a contiguous buffer.

This will have the advantage that the same multimedia device driver will work on both systems - Samsung S5PC110 (without IOMMU) and Exynos4 (with IOMMU).

However dma_alloc_coherent() besides allocating memory also implies some particular type of memory mapping for it. IMHO it might be a good idea to separate these 2 things (allocation and mapping) somewhere in the future.

On systems with IOMMU the dma_map_sg() can be also used to create a mapping in device virtual address space, but the driver will still need to allocate the memory by itself.

Quoted 5 lines

Ok, I see. Having one device per channel as you suggested could probably work around this, and it's at least consistent with how you'd represent IOMMUs in the device tree. It is not ideal because it makes the video driver more complex when it now has to deal with multiple struct device that it binds to, but I can't think of any nicer way either.

Well, this will definitely complicate the codec driver. I wonder if allowing the driver to kmalloc(sizeof(struct device))) and copy the relevant data from the 'proper' struct device will be better idea. It is still hack but definitely less intrusive for the driver.

Quoted 3 lines · Marek Szyprowski

Quoted 2 lines · Arnd Bergmann

Quoted 1 line · Marek Szyprowski

The only question is how a device can allocate a buffer that will be

most

Quoted 1 line

Quoted 1 line

Quoted 1 line

convenient for IOMMU mapping (i.e. will require least entries to

map)?

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

IOMMU can create a contiguous mapping for ANY set of pages, but it

performs

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

much better if the pages are grouped into 64KiB or 1MiB areas.

Can device allocate a buffer without mapping it into kernel space?

Quoted 8 lines

Quoted 3 lines

Not today as far as I know. You can register coherent memory per device using dma_declare_coherent_memory(), which will be used to back dma_alloc_coherent(), but I believe it is always mapped right now.

This is not exactly what I meant.

As we have IOMMU, the device driver can access any system memory. However the performance will be better if the buffer is composed of larger

contiguous

Quoted 1 line

parts (like 64KiB or 1MiB). I would like to avoid putting logic that

manages

Quoted 1 line

buffer allocation into the device drivers. It would be best if such

buffers

Quoted 4 lines

could be allocated by a single call to dma-mapping API.

Right now there is dma_alloc_coherent() function, which is used by the drivers to allocate a contiguous block of memory and map it to DMA

addresses.

Quoted 1 line

With IOMMU implementation it is quite easy to provide a replacement for

it

Quoted 6 lines

that will allocate some set of pages and map into device virtual address space as a contiguous buffer.

This will have the advantage that the same multimedia device driver will work on both systems - Samsung S5PC110 (without IOMMU) and Exynos4 (with IOMMU).

Right.

Quoted 5 lines

However dma_alloc_coherent() besides allocating memory also implies some particular type of memory mapping for it. IMHO it might be a good idea to separate these 2 things (allocation and mapping) somewhere in the future.

On systems with IOMMU the dma_map_sg() can be also used to create a

mapping

Quoted 1 line

in device virtual address space, but the driver will still need to

allocate

Quoted 1 line

the memory by itself.

Note that dma_map_sg() is the "streaming mapping", which provides a cacheable
buffer all the time, while dma_alloc_coherent() and is the "coherent mapping".

There is also dma_alloc_noncoherent(), which you can use to allocate a buffer
for the streaming mapping. This is currently not implemented on ARM, but if I understand you correctly, adding this would do what you want.

Quoted 1 line

Quoted 1 line

Ok, I see. Having one device per channel as you suggested could

probably

Quoted 6 lines

Quoted 4 lines

work around this, and it's at least consistent with how you'd represent IOMMUs in the device tree. It is not ideal because it makes the video driver more complex when it now has to deal with multiple struct device that it binds to, but I can't think of any nicer way either.

Well, this will definitely complicate the codec driver. I wonder if

allowing

Quoted 3 lines

the driver to kmalloc(sizeof(struct device))) and copy the relevant data from the 'proper' struct device will be better idea. It is still hack but definitely less intrusive for the driver.

No, I think that would be much worse, it definitely destroys all kinds of assumptions that the core code makes about devices. However, I don't think it's much of a problem to just create two child devices and use them from the main driver, you don't really need to create a device_driver to bind to each of them.

Quoted 5 lines

No, I think that would be much worse, it definitely destroys all kinds of assumptions that the core code makes about devices. However, I don't think it's much of a problem to just create two child devices and use them from the main driver, you don't really need to create a device_driver to bind to each of them.

I must have missed something. Video codec is a platform device and struct device pointer is gathered from it (&pdev->dev). How can I define child devices and attach them to the platform device?

Quoted 1 line · Marek Szyprowski

Quoted 1 line

No, I think that would be much worse, it definitely destroys all kinds

of

Quoted 1 line

Quoted 1 line

assumptions that the core code makes about devices. However, I don't

think

Quoted 7 lines

Quoted 3 lines

it's much of a problem to just create two child devices and use them from the main driver, you don't really need to create a device_driver to bind to each of them.

I must have missed something. Video codec is a platform device and struct device pointer is gathered from it (&pdev->dev). How can I define child devices and attach them to the platform device?

There are a number of ways:

* Do device_create() with &pdev->dev as the parent, inside of the codec driver, with a new class you create for this purpose
* Do device_register() for a device, in the same way
* Create the additional platform devices in the platform code, with their parents pointing to the code device, then look for them using device_for_each_child in the driver

* Create two codec devices in parallel and bind to both with your driver, ideally splitting up the resources between the two devices in a meaningful way.

None of them are extremely nice, but it's not that hard either. You should probably prototype a few of these approaches to see which one is the least ugly one.

Quoted 3 lines

* Create two codec devices in parallel and bind to both with your driver, ideally splitting up the resources between the two devices in a meaningful way.

Video codec has only standard 2 resources - ioregs and irq, so there is not much left for such splitting.

Quoted 3 lines

None of them are extremely nice, but it's not that hard either. You should probably prototype a few of these approaches to see which one is the least ugly one.

Ok. Today while iterating over the hardware requirements I noticed one more thing. Our codec hardware has one more, odd requirement for video buffers. The DMA addresses need to be aligned to 8KiB or 16KiB (depending on buffer type). Do you have any idea how this can be handled in a generic way?

Quoted 6 lines · Marek Szyprowski

Quoted 3 lines

* Create two codec devices in parallel and bind to both with your driver, ideally splitting up the resources between the two devices in a meaningful way.

Video codec has only standard 2 resources - ioregs and irq, so there is not much left for such splitting.

Ok, I see.

Quoted 9 lines

Quoted 3 lines

None of them are extremely nice, but it's not that hard either. You should probably prototype a few of these approaches to see which one is the least ugly one.

Ok. Today while iterating over the hardware requirements I noticed one more thing. Our codec hardware has one more, odd requirement for video buffers. The DMA addresses need to be aligned to 8KiB or 16KiB (depending on buffer type). Do you have any idea how this can be handled in a generic way?

I don't think you can force the mappings to be aligned to that size in the streaming mapping, but you should be able to just align inside of dma_map_single etc and map a larger region.

For the allocation functions (dma_alloc_coherent, dma_alloc_noncoherent), using alloc_pages to allocate multiples of the size you need should always give you aligned buffers because of the way that the underlying buddy allocator works.

Ok. I understand. IOMMU API is quite nice abstraction of the IOMMU chip. dma-mapping API is something much more complex that creates the actual mapping for various sets of the devices. IMHO the right direction will be to create dma-mapping implementation that will be just a client of the IOMMU API. What's your opinion?

Getting back to our video codec - it has 2 IOMMU controllers. The codec hardware is able to address only 256MiB of space. Do you have an idea how this can be handled with dma-mapping API? The only idea that comes to my mind is to provide a second, fake 'struct device' and use it for allocations for the second IOMMU controller.

Quoted 5 lines

Getting back to our video codec - it has 2 IOMMU controllers. The codec hardware is able to address only 256MiB of space. Do you have an idea how this can be handled with dma-mapping API? The only idea that comes to my mind is to provide a second, fake 'struct device' and use it for allocations for the second IOMMU controller.

The GPU IOMMUs can probably be handled in the GPU driver if they are that different. Recent PCIe GPUs on x86 have their own IOMMUs too which are very device specific and are handled in the device driver.

From: Andrzej Pietrasiewicz <[email protected]>

This patch adds new videobuf2 memory allocator dedicated to devices that supports IOMMU DMA mappings. A device with IOMMU module and a driver with include/iommu.h compatible interface is required. This allocator aquires memory with standard alloc_page() call and doesn't suffer from memory fragmentation issues. The allocator support following page sizes:
4KiB, 64KiB, 1MiB and 16MiB to reduce iommu translation overhead.

Quoted 8 lines · Marek Szyprowski

From: Andrzej Pietrasiewicz <[email protected]>

This patch adds new videobuf2 memory allocator dedicated to devices that supports IOMMU DMA mappings. A device with IOMMU module and a driver with include/iommu.h compatible interface is required. This allocator aquires memory with standard alloc_page() call and doesn't suffer from memory fragmentation issues. The allocator support following page sizes:
4KiB, 64KiB, 1MiB and 16MiB to reduce iommu translation overhead.

My feeling is that this is not the right abstraction. Why can't you just implement the regular dma-mapping.h interfaces for your IOMMU so that the videobuf code can use the existing allocators?

Quoted 3 lines · Arnd Bergmann

My feeling is that this is not the right abstraction. Why can't you just implement the regular dma-mapping.h interfaces for your IOMMU so that the videobuf code can use the existing allocators?

I'm not really sure which existing videobuf2 allocators might transparently support IOMMU interface yet

Do you think that all iommu operations can be hidden behind dma_map_single and dma_unmap_single?

Quoted 5 lines · Marek Szyprowski

Quoted 3 lines · Arnd Bergmann

My feeling is that this is not the right abstraction. Why can't you just implement the regular dma-mapping.h interfaces for your IOMMU so that the videobuf code can use the existing allocators?

Quoted 5 lines

I'm not really sure which existing videobuf2 allocators might transparently support IOMMU interface yet

Do you think that all iommu operations can be hidden behind dma_map_single and dma_unmap_single?

That is one of the intentions of the DMA API.

This is a third version of the Samsung IOMMU driver (see patch #2) and videobuf2 allocator for IOMMU mapped memory (see patch #4) as well as FIMC driver update. This update brings some minor bugfixes to Samsung IOMMU (SYSMMU) driver and support for pages larger than 4KiB in videobuf2-dma-iommu allocator.

This patch series contains a collection of patches for various platform subsystems. Here is a detailed list:

[PATCH 1/7] ARM: EXYNOS4: power domains: fixes and code cleanup
- adds support for block gating in Samsung power domain driver and performs some cleanup

[PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
- a complete rewrite of sysmmu driver for Samsung platform, now uses linux/include/iommu.h api (key patch in this series)

[PATCH 3/7] v4l: videobuf2: dma-sg: move some generic functions to memops
- a little cleanup and preparations for the dma-iommu allocator

[PATCH 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator
- introduces new memory allocator for videobuf2 for drivers that support iommu dma memory mappings (key patch in this series)