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