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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 8D173C4727D for ; Wed, 23 Sep 2020 06:58:17 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (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 0C020221E8 for ; Wed, 23 Sep 2020 06:58:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0C020221E8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id CC3E886ECC; Wed, 23 Sep 2020 06:58:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccOFRzY26T1O; Wed, 23 Sep 2020 06:58:16 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by hemlock.osuosl.org (Postfix) with ESMTP id 0B4CE86DC6; Wed, 23 Sep 2020 06:58:16 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id F1A8FC0859; Wed, 23 Sep 2020 06:58:15 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id E270EC0051 for ; Wed, 23 Sep 2020 06:58:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id DCE3685D57 for ; Wed, 23 Sep 2020 06:58:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crKJeuBQa2ew for ; Wed, 23 Sep 2020 06:58:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by whitealder.osuosl.org (Postfix) with ESMTPS id 7D64285D26 for ; Wed, 23 Sep 2020 06:58:13 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id C68CA67373; Wed, 23 Sep 2020 08:58:08 +0200 (CEST) Date: Wed, 23 Sep 2020 08:58:08 +0200 From: Christoph Hellwig To: Marek Szyprowski Subject: Re: IOVA allocation dependency between firmware buffer and remaining buffers Message-ID: <20200923065808.GA16366@lst.de> References: <59cda41f-170c-a1ad-a345-bc38b9ed4d73@arm.com> <11584d09-5995-6133-3bd3-8f7a0afd0e01@samsung.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <11584d09-5995-6133-3bd3-8f7a0afd0e01@samsung.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: jean-philippe@linaro.org, will@kernel.org, linux-mm@kvack.org, Linux IOMMU , Thierry Reding , Ajay kumar , Shaik Ameer Basha , Robin Murphy , hch@lst.de X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote: > Hi Shaik, > > I've run into similar problem while adapting S5P-MFC and Exynos4-IS > drivers for generic IOMMU-DMA framework. Here is my first solution: > https://lore.kernel.org/linux-samsung-soc/20200918144833.14618-1-m.szyprowski@samsung.com/T/ > > > It allows to remap given buffer at the specific IOVA address, although > it doesn't guarantee that those specific addresses won't be later used > by the IOVA allocator. Probably it would make sense to add an API for > generic IOMMU-DMA framework to mark the given IOVA range as > reserved/unused to protect them. If you want to use IOVA addresses in a device otherwise managed by dma-iommu we need to expose an API through the dma API. Can you please include the iommu list in the discussion of your series? I don't think using the raw IOMMU API is a very idea in these drivers, we probably want a way to change the allocator algorithm or hint the next IOVA and keep using the normal DMA API. Maybe Robin has a better idea. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 BB80FC4363D for ; Wed, 23 Sep 2020 06:58:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E4FC5221F0 for ; Wed, 23 Sep 2020 06:58:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4FC5221F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D19F36B0003; Wed, 23 Sep 2020 02:58:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCA306B0055; Wed, 23 Sep 2020 02:58:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE0E96B005A; Wed, 23 Sep 2020 02:58:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id A5B006B0003 for ; Wed, 23 Sep 2020 02:58:14 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6E7F7181AC9CC for ; Wed, 23 Sep 2020 06:58:14 +0000 (UTC) X-FDA: 77293422108.10.grain86_32071a927154 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 3D02216A0DD for ; Wed, 23 Sep 2020 06:58:14 +0000 (UTC) X-HE-Tag: grain86_32071a927154 X-Filterd-Recvd-Size: 2661 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Sep 2020 06:58:13 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id C68CA67373; Wed, 23 Sep 2020 08:58:08 +0200 (CEST) Date: Wed, 23 Sep 2020 08:58:08 +0200 From: Christoph Hellwig To: Marek Szyprowski Cc: Shaik Ameer Basha , Robin Murphy , Ajay kumar , Linux IOMMU , linux-mm@kvack.org, Joerg Roedel , Rob Clark , Thierry Reding , jean-philippe@linaro.org, will@kernel.org, hch@lst.de, baolu.lu@linux.intel.com, Shaik Ameer Basha Subject: Re: IOVA allocation dependency between firmware buffer and remaining buffers Message-ID: <20200923065808.GA16366@lst.de> References: <59cda41f-170c-a1ad-a345-bc38b9ed4d73@arm.com> <11584d09-5995-6133-3bd3-8f7a0afd0e01@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11584d09-5995-6133-3bd3-8f7a0afd0e01@samsung.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote: > Hi Shaik, > > I've run into similar problem while adapting S5P-MFC and Exynos4-IS > drivers for generic IOMMU-DMA framework. Here is my first solution: > https://lore.kernel.org/linux-samsung-soc/20200918144833.14618-1-m.szyprowski@samsung.com/T/ > > > It allows to remap given buffer at the specific IOVA address, although > it doesn't guarantee that those specific addresses won't be later used > by the IOVA allocator. Probably it would make sense to add an API for > generic IOMMU-DMA framework to mark the given IOVA range as > reserved/unused to protect them. If you want to use IOVA addresses in a device otherwise managed by dma-iommu we need to expose an API through the dma API. Can you please include the iommu list in the discussion of your series? I don't think using the raw IOMMU API is a very idea in these drivers, we probably want a way to change the allocator algorithm or hint the next IOVA and keep using the normal DMA API. Maybe Robin has a better idea.