Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753366AbaD3Eu2 (ORCPT ); Wed, 30 Apr 2014 00:50:28 -0400 Received: from mail-yh0-f54.google.com ([209.85.213.54]:48473 "EHLO mail-yh0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751060AbaD3Eu0 (ORCPT ); Wed, 30 Apr 2014 00:50:26 -0400 MIME-Version: 1.0 In-Reply-To: <26065037.GxQQuIURPg@wuerfel> References: <1398584283-22846-1-git-send-email-shaik.ameer@samsung.com> <26065037.GxQQuIURPg@wuerfel> From: Shaik Ameer Basha Date: Wed, 30 Apr 2014 10:20:05 +0530 Message-ID: Subject: Re: [PATCH v12 00/31] iommu/exynos: Fixes and Enhancements of System MMU driver with DT To: Arnd Bergmann Cc: Linux ARM Kernel , Shaik Ameer Basha , Linux Samsung SOC , Linux DeviceTree , Linux IOMMU , Linux Kernel , Kukjin Kim , Prathyush , Grant Grundler , Joerg Roedel , supash.ramaswamy@linaro.org, Tomasz Figa , sunil joshi , Sachin Kamat , Sylwester Nawrocki , Varun Sethi , Antonios Motakis , Cho KyongHo , Tomasz Figa , Rahul Sharma , thierry.reding@gmail.com, hdoyu@nvidia.com, Dave.Martin@arm.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 28, 2014 at 2:04 PM, Arnd Bergmann wrote: > On Sunday 27 April 2014 13:07:32 Shaik Ameer Basha wrote: >> The current exynos-iommu(System MMU) driver does not work autonomously >> since it is lack of support for power management of peripheral blocks. >> For example, MFC device driver must ensure that its System MMU is disabled >> before MFC block is power-down not to invalidate IOTLB in the System MMU >> when I/O memory mapping is changed. Because a System MMU resides in the >> same H/W block, access to control registers of System MMU while the H/W >> block is turned off must be prohibited. >> >> This set of changes solves the above problem with setting each System MMUs >> as the parent of the device which owns the System MMU to receive the >> information when the device is turned off or turned on. >> >> Another big change to the driver is the support for devicetree. >> The bindings for System MMU is described in >> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt > > Sorry I've been absent from the review so far. Most of the patches > seem entirely reasonable to me, but I'm worried about the DT binding > aspect. We are going to see more systems shipping with IOMMUs now, > and we are seeing an increasing number of submissions for 64-bit > systems. We really have to work out what the DT representation for > IOMMUs should look like in general before adding another ad-hod > implementation that is private to one driver. Hi Arnd, No issues. Its good that finally you are here :) I am going through the possibilities for new bindings that you mentioned in the other thread. -- [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU Exynos IOMMU driver is pretty simple with only one exception, "some devices are using multiple IOMMUs". >From starting (of this patch set), we were trying to fix three major issues. [1] How to control the probing order of required IOMMU(s) for a given device and a device itself. [2] Handling multiple IOMMUs for one device. [3] Generic DT bindings to link Device and IOMMUs. I have gone through the implementation of Tegra SMMU driver by "Hiroshi Doyu" -- [PATCHv7 00/12] Unifying SMMU driver among Tegra SoCs [https://lkml.org/lkml/2013/12/12/74] For the first point [1], ------------------------------ Tegra implementation tries to fix this issue with these two patches -- iommu/of: check if dependee iommu is ready or not [http://patchwork.ozlabs.org/patch/300560/] -- driver/core: populate devices in order for IOMMUs [http://patchwork.ozlabs.org/patch/300558/] I can follow this driver if this approach is acceptable. For the second point [2] ---------------------------------- Currently we are handling this issue by providing same mapping for all IOMMUs linked to the same device. And current Exynos drivers doesn't have any special implementation to handle this case differently. I thought of understanding how Tegra SMMU driver is handling this case. Frankly speaking, I didn't understand how its done there. For the third point [3] ------------------------------- As Tegra SMMU driver is inline with the discussion in other thread, we can follow the same bindings, unless the discussion takes us in the other direction. "KyongHo Cho" is the author for this driver and hope he has more inputs. Regards, Shaik > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/