From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH 5/6] ARM: OMAP2+: Make some definitions local Date: Thu, 25 Oct 2012 01:26:04 +0200 Message-ID: <1682925.XTJ8FK6Z8P@avalon> References: <20121018202707.11834.1438.stgit@muffinssi.local> <2153737.CkcY4HqKKl@avalon> <20121019161743.GD4730@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: Received: from perceval.ideasonboard.com ([95.142.166.194]:38218 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755602Ab2JXXZP (ORCPT ); Wed, 24 Oct 2012 19:25:15 -0400 In-Reply-To: <20121019161743.GD4730@atomide.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: linux-arm-kernel@lists.infradead.org, Ohad Ben-Cohen , Joerg Roedel , Mauro Carvalho Chehab , Omar Ramirez Luna , linux-omap@vger.kernel.org, Ido Yariv Ho Tony, On Friday 19 October 2012 09:17:43 Tony Lindgren wrote: > * Laurent Pinchart [121019 02:45]: > > On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote: > > > @@ -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. > 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. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: laurent.pinchart@ideasonboard.com (Laurent Pinchart) Date: Thu, 25 Oct 2012 01:26:04 +0200 Subject: [PATCH 5/6] ARM: OMAP2+: Make some definitions local In-Reply-To: <20121019161743.GD4730@atomide.com> References: <20121018202707.11834.1438.stgit@muffinssi.local> <2153737.CkcY4HqKKl@avalon> <20121019161743.GD4730@atomide.com> Message-ID: <1682925.XTJ8FK6Z8P@avalon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Ho Tony, On Friday 19 October 2012 09:17:43 Tony Lindgren wrote: > * Laurent Pinchart [121019 02:45]: > > On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote: > > > @@ -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. > 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. -- Regards, Laurent Pinchart