Hi Tony,

On Wednesday 24 October 2012 16:33:18 Tony Lindgren wrote:

* Laurent Pinchart [off-list ref] [121024 16:26]:

quoted

On Friday 19 October 2012 09:17:43 Tony Lindgren wrote:

quoted

* Laurent Pinchart [off-list ref] [121019 02:45]:

quoted

On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote:

quoted

@@ -117,13 +112,6 @@ static inline struct omap_iommu

*dev_to_omap_iommu(struct device *dev) }

 #endif

-/* IOMMU errors */
-#define OMAP_IOMMU_ERR_TLB_MISS		(1 << 0)
-#define OMAP_IOMMU_ERR_TRANS_FAULT	(1 << 1)
-#define OMAP_IOMMU_ERR_EMU_MISS		(1 << 2)
-#define OMAP_IOMMU_ERR_TBLWALK_FAULT	(1 << 3)
-#define OMAP_IOMMU_ERR_MULTIHIT_FAULT	(1 << 4)
-

I'll use those in the tidspbridge driver, in patches that I plan to
push soon.

I will apply this patch set on top of mine, see what breaks. Would you
like me to propose a modified version of this set, or add additional
patches in my set ?

Sure, let's try to expose only the minimal amount of omap iommu things
with this patch set so we don't break things. Then the iommu development
can continue on it's own independent of the core omap code except for
the platform data.

I'll rebase my DSP patches on top of this patch set then, it will be
easier.

OK sounds good to me.

Once we have the minimal changes acked by you and Joerg, I'll push
it into an immutable branch that we all can merge in as needed.

BTW, after updating patch 3/6 I noticed patches 4 - 6 had trivial merge
conflicts with the includes, so let me know if you want met to repost the
whole set.

Please do. I'll then ack it (provided I have no more comments to make of 
course :-)).
 

quoted

quoted

But again, if there are nasty layering violations using this code, I
would just remove those features. Those things tend to just get worse
unless they are fixed properly to start with.

The long-term goal is to move the tidspbridge driver to the IOMMU API, but
we'll need a step by step approach.

Yes agreed.

-- 
Regards,

Laurent Pinchart