From mboxrd@z Thu Jan 1 00:00:00 1970 From: "sricharan" Subject: RE: [PATCH 5/9] iommu: add qcom_iommu Date: Thu, 9 Mar 2017 15:44:23 +0530 Message-ID: <23a001d298bd$f09197c0$d1b4c740$@codeaurora.org> References: <20170301174258.14618-1-robdclark@gmail.com> <20170301174258.14618-6-robdclark@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-us List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: 'Rob Clark' , 'Robin Murphy' Cc: 'Mark Rutland' , 'linux-arm-msm' , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, 'Will Deacon' , 'Stanimir Varbanov' List-Id: linux-arm-msm@vger.kernel.org Hi, >On Tue, Mar 7, 2017 at 12:48 PM, Robin Murphy >wrote: >> On 01/03/17 17:42, Rob Clark wrote: >>> An iommu driver for Qualcomm "B" family devices which do not >>> completely implement the ARM SMMU spec. >> >> Is that actually true, or is it just that it's a compliant SMMU on >> which firmware has set SCR1.GASRAE? (which makes the global address >> space secure-access-only). I don't know which Qualcomm SoCs are the >> ones apparently using a plain ARM MMU-500 IP, but if any of those are >> also running this particular firmware configuration that puts us in a >> somewhat weird situation with respect to drivers :/ >> > >I can't say for sure, I don't really know exactly what tz is doing. >Although the net effect from linux kernel perspective is that it isn't really >"compliant". And I think the SMMU_INTR_SEL_NS part (for controlling routing >of cb irqs) is non-standard. > >As far as I can tell, if there was firmware that allowed access to the global >address space, I don't think it ever escaped outside of qcom's labs (ie. might >have existed on early versions of chips for new SoC bring-up.. but I think from >upstream perspective we can ignore that). Right, I would think this is the only one which has the MMU-500 behind the *secure* access constraints to global registers. The next set of Socs which were integrating the MMU-500 had this addressed in different ways, means its going to work with the upstream arm-smmu driver itself. Regards, Sricharan