From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF49DC433DF for ; Mon, 24 Aug 2020 21:42:02 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B681D20702 for ; Mon, 24 Aug 2020 21:42:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PQiQNBMp"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="tJ6RhK6w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B681D20702 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=rjLVf8qqqOVqgZEkLsMeGPzL4x44TDBdTAeipl5mDBM=; b=PQiQNBMpIgJkyPqyjeXX1wfmY PCOKKWgg1KMmMI/Ex0L7CGOzrj5XVMe/E/O4kXpeMhKo4UrzraunQeJjuh7npuhiS9VG0tYr3QjHp lzm3ehTxwfIS0QuUuXtU2XvRaiSEr+mpawZybRXxCSLIWC9lSV3nPR51fHLIfDi8Xy1KPZzTn87bN Ke6SOrT0LxgW4r63sTDYHApsW5gP5oD6YUnS9ksNZcE91zz7Vl+kpT917KeVGqMvf0MIpq7H0G1rL idCLsLguE+Pz0M1QTkjHRR0/q+YQSd0bEuSvah9HqqqCastDVhVaF06IiZN4ul8ch0HgyPp2WGBag y25nMcsUA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAKCg-0000Fo-4S; Mon, 24 Aug 2020 21:40:34 +0000 Received: from lelv0143.ext.ti.com ([198.47.23.248]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAKCc-0000EU-6m; Mon, 24 Aug 2020 21:40:31 +0000 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 07OLdsPY046027; Mon, 24 Aug 2020 16:39:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1598305194; bh=bf+6mDZifTI9HQJSeivn4me8d5zREYk1XPJ3eAaDXHY=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=tJ6RhK6wvGyEiAhqwOPDwT69Y3+7BoJNjgEuOOW+0PGCMSlzIrjy7T2GrEFwuAAcZ 51c8X4oGyc7X5b+1hxYLGjFw1iyT+DGwI6G2Whe/r0fmJRG1pX1zZGWT3yn2053eaa 4Szann3xS0X39D0KAerooEYGEMuFIf1zy1xME1pQ= Received: from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 07OLdr7q044652 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Aug 2020 16:39:53 -0500 Received: from DFLE100.ent.ti.com (10.64.6.21) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Mon, 24 Aug 2020 16:39:53 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE100.ent.ti.com (10.64.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Mon, 24 Aug 2020 16:39:53 -0500 Received: from [10.250.32.171] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 07OLdqBH090259; Mon, 24 Aug 2020 16:39:52 -0500 Subject: Re: [PATCH 11/18] iommu/omap: Add IOMMU_DOMAIN_DMA support To: Robin Murphy , , , References: <5ac3788f9f61f7698cfa9c5924d62714e230f678.1597931876.git.robin.murphy@arm.com> From: Suman Anna Message-ID: Date: Mon, 24 Aug 2020 16:39:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5ac3788f9f61f7698cfa9c5924d62714e230f678.1597931876.git.robin.murphy@arm.com> Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200824_174030_517557_06A4202A X-CRM114-Status: GOOD ( 26.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: geert+renesas@glider.be, dri-devel@lists.freedesktop.org, bjorn.andersson@linaro.org, matthias.bgg@gmail.com, thierry.reding@gmail.com, laurent.pinchart@ideasonboard.com, digetx@gmail.com, will@kernel.org, m.szyprowski@samsung.com, linux-samsung-soc@vger.kernel.org, magnus.damm@gmail.com, kyungmin.park@samsung.com, jonathanh@nvidia.com, agross@kernel.org, yong.wu@mediatek.com, linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, inki.dae@samsung.com, linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sw0312.kim@samsung.com, linux-kernel@vger.kernel.org, t-kristo@ti.com, iommu@lists.linux-foundation.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Robin, On 8/20/20 10:08 AM, Robin Murphy wrote: > Now that arch/arm is wired up for default domains and iommu-dma, > implement the corresponding driver-side support for DMA domains. > > Signed-off-by: Robin Murphy > --- > drivers/iommu/omap-iommu.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c > index 71f29c0927fc..ea25c2fe0418 100644 > --- a/drivers/iommu/omap-iommu.c > +++ b/drivers/iommu/omap-iommu.c > @@ -9,6 +9,7 @@ > * Paul Mundt and Toshihiro Kobayashi > */ > > +#include > #include > #include > #include > @@ -1574,13 +1575,19 @@ static struct iommu_domain *omap_iommu_domain_alloc(unsigned type) > { > struct omap_iommu_domain *omap_domain; > > - if (type != IOMMU_DOMAIN_UNMANAGED) > + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA) > return NULL; > > omap_domain = kzalloc(sizeof(*omap_domain), GFP_KERNEL); > if (!omap_domain) > return NULL; > > + if (type == IOMMU_DOMAIN_DMA && > + iommu_get_dma_cookie(&omap_domain->domain)) { > + kfree(omap_domain); > + return NULL; > + } > + > spin_lock_init(&omap_domain->lock); > > omap_domain->domain.geometry.aperture_start = 0; > @@ -1601,6 +1608,7 @@ static void omap_iommu_domain_free(struct iommu_domain *domain) > if (omap_domain->dev) > _omap_iommu_detach_dev(omap_domain, omap_domain->dev); > > + iommu_put_dma_cookie(&omap_domain->domain); > kfree(omap_domain); > } > > @@ -1736,6 +1744,17 @@ static struct iommu_group *omap_iommu_device_group(struct device *dev) > return group; > } > > +static int omap_iommu_of_xlate(struct device *dev, > + struct of_phandle_args *args) > +{ > + /* > + * Logically, some of the housekeeping from _omap_iommu_add_device() > + * should probably move here, but the minimum we *need* is simply to > + * cooperate with of_iommu at all to let iommu-dma work. > + */ > + return 0; > +} > + I have tested this series, and it is breaking the OMAP remoteproc functionality. We definitely need some more plumbing. I am currently getting MMU faults and also the DMA allocated addresses are not coming from the device-specific CMA pools (opposite of what Sakari has reported with OMAP3 ISP). Just removing the of_xlate gets me back the expected allocations, and no MMU faults, but I don't see any valid traces. The MMU devices that the OMAP IOMMU driver deals with are not traditional bus-level IOMMU devices, but local MMU devices that are present within a remote processor sub-system or hardware accelerator (eg: OMAP3 ISP). The usage is also slightly different between remoteprocs and OMAP3 ISP. The former uses the CMA pools and iommu_map/unmap API (UNMANAGED iommu domain), as the allocated regions need to be mapped using specific device addresses adhering to the firmware linker map, while OMAP3 ISP uses it like a traditional DMA pool. regards Suman > static const struct iommu_ops omap_iommu_ops = { > .domain_alloc = omap_iommu_domain_alloc, > .domain_free = omap_iommu_domain_free, > @@ -1747,6 +1766,7 @@ static const struct iommu_ops omap_iommu_ops = { > .probe_device = omap_iommu_probe_device, > .release_device = omap_iommu_release_device, > .device_group = omap_iommu_device_group, > + .of_xlate = omap_iommu_of_xlate, > .pgsize_bitmap = OMAP_IOMMU_PGSIZES, > }; > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel