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

Ho Tony,

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.
 

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,

Tony