Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp847756imm; Fri, 27 Jul 2018 07:11:40 -0700 (PDT) X-Google-Smtp-Source: AAOMgpexHoYg/u3QecI8HeGbMAzj0poW8utucfpAOEFrJ5OBBt7pjvi5DKWNgPXQsVcHAHr9h8Y1 X-Received: by 2002:a17:902:b608:: with SMTP id b8-v6mr6275699pls.312.1532700700015; Fri, 27 Jul 2018 07:11:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532700699; cv=none; d=google.com; s=arc-20160816; b=e/0SASAmZGnkKX0bs8gwRGWyO/CYZkTtIVUr6BRx8zqYslaG8LiCybW/LAbI1r4xCJ Pl4pOCZGgeGXnie57sFU9F5twBZoJlogq+GB0RuPKUqzFVR0gOKOcGepJ8s3M4Z1ffkD 2nJHCBsVsCMOBtf+cKAn2RXXSNYK65GoE+d/i+HgkcME4qFaJYekUKGzTW1of6doPPz/ T1pXCGIimAUnoW7xaYLqW1d7h2ym4IOHBXHpUy5UUQ2/7e9zSfWqB69Pd9oshE1ZE3YJ 2qubYO8DJVx7b40M2SiX+AAnAwI7p5cUQ3F3gKGnEnZFQyJiivs+yur0dqNsKPFeGFqM ofJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=5ZR9K0sfpSvV8pGr+2uKwP6+zKLnzOqLxlIY5hvTUV8=; b=vgRqtsjtoHg+Z+Jlef9BR9a11D4VV3d34vQJ+ZGF+dDAoM8tyvCo2u5J7ewjKT8CZl 6PvPN03JiIxDDLWqWyAfE+MqzdjME7pCJIo2C/JAVGhAA7sFXXv2cedZGBBZFW4Q9cN0 tt+4fp4QaI/SKSt7MVU6r4N8UPl2Xwxa1Rf6biNFqCpigqGYrYqKteoeU6VWrLRAXgl0 kpEE7I6AZJE+aUXUQHw4spOBi9BV/UwcTeipld9J5AIWtKAM+OJ9aJfq2h3xEYDwNvIH j7POWNjLhx1BgH0tC5Hfyd5g+j8MS0xsn0goLbPREkFpSYpB7UGdNXuT+OebubDE0+mi VLag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JMDwxxeL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y6-v6si3940485pgr.684.2018.07.27.07.11.22; Fri, 27 Jul 2018 07:11:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JMDwxxeL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730907AbeG0Pcd (ORCPT + 99 others); Fri, 27 Jul 2018 11:32:33 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:46665 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730395AbeG0Pcd (ORCPT ); Fri, 27 Jul 2018 11:32:33 -0400 Received: by mail-lf1-f66.google.com with SMTP id l16-v6so3612236lfc.13; Fri, 27 Jul 2018 07:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=5ZR9K0sfpSvV8pGr+2uKwP6+zKLnzOqLxlIY5hvTUV8=; b=JMDwxxeLZNsni5Eg7+Ve1NxHiVZvgs7mLSK2LoDEpW2qZASSzPpzZeny8kuNLPNLy/ 79oHM3WfaKQ1iHfyDnsgHcRQX6nOKIifBn34VlvAKWXYDFYDieP+R1uKlWaiSDognJcD XJLscgrWO/+j8trwmt2nbMqZoerIBOZCD0p6EtmEJH6xFN4EZltsjjrIZ9Pf9NNZ4X8N XnGB3C5IHLrKVBkVG3F88dpBnlueadh6UDWJpCLi40NZQiafMLSS22UlAE2SL2CTUMg6 49YXb8kJaV6OPoN5eIAqaReSMtsQNg9AGAGHP0cP/LZYVGuRoZ6MhyjkeG81G9za+DaH AKsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=5ZR9K0sfpSvV8pGr+2uKwP6+zKLnzOqLxlIY5hvTUV8=; b=c/xTt6X75qERCEBQBB+0jfg9l/Uq267PsxdXVRSLUgT2c7l54nTmT5NHF6p6epQH2c eOCCu7sA1YZuJWCfcDNWDkuD+iNUCKyKzIGnSZwNoS00x5NEE8Uqy7RmnqlhxXLTi9PU ZCuyXdh17t32QFE+9XdMD9ILuGaZW2RGMYElYHHkWIoiTA/LOWaR0G5+gNXzEquct+b8 OYmcU5toSSZ7CzduTBxHA5waTp+Q9UPaUop6kkPVJCq5cq9jF+ve9rbE5n4+waX1M/Gn z0kbBwFJ9tdcWycbxIx+XJ03FqU2B5zTbRapsFwQ2wveINBsRO7+uL56SH2oAa9TUlQ3 WY1Q== X-Gm-Message-State: AOUpUlGnM3uQWIUflnjTTyY2cnGKUECD9hkwAGll8fHGz3jzeFI+y4xF xi8FEFiQZr0FCHQnyvNSlYY= X-Received: by 2002:a19:9710:: with SMTP id z16-v6mr3992048lfd.17.1532700624607; Fri, 27 Jul 2018 07:10:24 -0700 (PDT) Received: from dimapc.localnet ([109.252.90.13]) by smtp.gmail.com with ESMTPSA id d24-v6sm556904lfl.53.2018.07.27.07.10.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 07:10:23 -0700 (PDT) From: Dmitry Osipenko To: Will Deacon , Joerg Roedel Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Thierry Reding , Jonathan Hunter , Mikko Perttunen , Rob Herring , Frank Rowand , Ben Skeggs , Russell King , Catalin Marinas , Nicolas Chauvet , devicetree@vger.kernel.org, nouveau@lists.freedesktop.org, iommu@lists.linux-foundation.org, dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU Date: Fri, 27 Jul 2018 17:10:22 +0300 Message-ID: <4164951.xGHfcFJ9uZ@dimapc> In-Reply-To: <20180727090328.GH28088@arm.com> References: <20180726231624.21084-1-digetx@gmail.com> <20180727082512.lpvmeuvxnw3mpeym@8bytes.org> <20180727090328.GH28088@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote: > On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote: > > On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote: > > > The proposed solution adds a new option to the base device driver > > > structure that allows device drivers to explicitly convey to the drivers > > > core that the implicit IOMMU backing for devices must not happen. > > > > Why is IOMMU mapping a problem for the Tegra GPU driver? > > > > If we add something like this then it should not be the choice of the > > device driver, but of the user and/or the firmware. > > Agreed, and it would still need somebody to configure an identity domain so > that transactions aren't aborted immediately. We currently allow the > identity domain to be used by default via a command-line option, so I guess > we'd need a way for firmware to request that on a per-device basis. The IOMMU mapping itself is not a problem, the problem is the management of the IOMMU. For Tegra we don't want anything to intrude into the IOMMU activities because: 1) GPU HW require additional configuration for the IOMMU usage and dumb mapping of the allocations simply doesn't work. 2) Older Tegra generations have a limited resource and capabilities in regards to IOMMU usage, allocating IOMMU domain per-device is just impossible for example. 3) HW performs context switches and so particular allocations have to be assigned to a particular contexts IOMMU domain. Some of the above is due to a SW driver model (and its work-in-progress status), other is due to a HW model. So essentially we need a way for a driver to tell the core not to mess with IOMMU stuff of drivers device behind the drivers back. I'm not sure what you guys are meaning by the "firmware", could you elaborate please? Do you mean the Open Firmware and hence the devicetree or what?