Add support for the IOMMUs found on the upcoming Qualcomm
MSM8x60 chips. These IOMMUs allow virtualization of the
address space used by most of the multimedia cores on these
chips. The driver implements the kernel's IOMMU API.

Fixed in v3: style, types for ioremapped addresses, use of
const, failure paths, cache flushing functions, unnecessary
initialization, ordering of spinlocks, unnecessary casting,
and other things.

Also, iova_to_phys now returns 0 on any error, to make this
implementation consistent with how other IOMMU drivers
handle this case.

Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
 arch/arm/mach-msm/include/mach/iommu.h         |  102 ++
 arch/arm/mach-msm/include/mach/iommu_hw-8xxx.h | 1864 ++++++++++++++++++++++++
 arch/arm/mach-msm/iommu.c                      |  601 ++++++++
 3 files changed, 2567 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-msm/include/mach/iommu.h
 create mode 100644 arch/arm/mach-msm/include/mach/iommu_hw-8xxx.h
 create mode 100644 arch/arm/mach-msm/iommu.c

diff --git a/arch/arm/mach-msm/include/mach/iommu.h b/arch/arm/mach-msm/include/mach/iommu.h
new file mode 100644
index 0000000..66138aa
--- /dev/null
+++ b/arch/arm/mach-msm/include/mach/iommu.h
@@ -0,0 +1,102 @@
+/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, ...
[ message continues ]

--

[ message continues ]

> Why use both pr_err and printk(KERN_ERR ?

I had been using pr_err for printing badness messages internal to the
driver, but I guess their functionality is largely paralleled by return
error codes. I had been using printk(KERN_ERR for messages that have been
caused by an event that is more external to the driver and its callers
(like the data for the page fault, which is most likely to be caused by a
misprogrammed client). pr_err gives other information like function name,
line number, etc, which would be noise when looking at an iommu page
fault. And, I guess if the pr_err stuff got turned off, you would want the
page fault data to still be printed... but that's kind of a minor point.

I am actually considering doing away with all the pr_err lines entirely
because they typically also result in returning -Ewhatever and other IOMMU
drivers don't give this level of error reporting. But, they may be helpful
to the users of the API. What are people's thoughts on this?

Thanks


--

[ message continues ]

I believe the current uses of pr_err in this module
are unnecessary or could be converted to pr_debug.

I think __func__/line aren't particularly useful.

I prefer log messages prefixed with the module name.

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

and I'd convert all the current pr_err to pr_debug
and convert the printk(KERN_ERR to pr_err(

cheers, Joe

--

[ message continues ]

Thanks. Fixed in v4, which will go up in a few minutes.

--

[ message continues ]