All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Rafael J. Wysocki"
	<rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux IOMMU
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Frank Rowand
	<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
Date: Fri, 27 Jul 2018 23:02:01 +0300	[thread overview]
Message-ID: <4850389.K9ByBxYttl@dimapc> (raw)
In-Reply-To: <20180727183134.GD6738-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>

On Friday, 27 July 2018 21:31:34 MSK Joerg Roedel wrote:
> On Fri, Jul 27, 2018 at 11:13:31AM -0600, Rob Herring wrote:
> > I don't follow why we need a property rather than being implied by the
> > device's (the GPU) compatible string.
> 
> There might be devices where either setup works, with or without IOMMU
> translation, and the firmware can set the property depending on whether
> the user wants more performance or more security.
> 
> If we have a whitelist in the kernel this gets more complicated, we
> probably need additional kernel-parameters to overwrite those whitelist
> entries. Having a property in the device-tree seems to be a better way
> here, imho.

IIUC, device-tree should be considered to be "written in stone" for a consumer 
device and hence firmware property isn't something that could be easily 
changed. The kernel-parameter will be much more universal. Anyway the global 
whitelisting should be a different topic for discussion, right now we need a 
kind of private whitelisting that is internal to kernel.



_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Joerg Roedel <joro@8bytes.org>, Rob Herring <robh+dt@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Mikko Perttunen <cyndis@kapsi.fi>,
	Frank Rowand <frowand.list@gmail.com>,
	bskeggs@redhat.com, Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	kwizart@gmail.com, devicetree@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-tegra@vger.kernel.org,
	"linux-kernel@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 23:02:01 +0300	[thread overview]
Message-ID: <4850389.K9ByBxYttl@dimapc> (raw)
In-Reply-To: <20180727183134.GD6738@8bytes.org>

On Friday, 27 July 2018 21:31:34 MSK Joerg Roedel wrote:
> On Fri, Jul 27, 2018 at 11:13:31AM -0600, Rob Herring wrote:
> > I don't follow why we need a property rather than being implied by the
> > device's (the GPU) compatible string.
> 
> There might be devices where either setup works, with or without IOMMU
> translation, and the firmware can set the property depending on whether
> the user wants more performance or more security.
> 
> If we have a whitelist in the kernel this gets more complicated, we
> probably need additional kernel-parameters to overwrite those whitelist
> entries. Having a property in the device-tree seems to be a better way
> here, imho.

IIUC, device-tree should be considered to be "written in stone" for a consumer 
device and hence firmware property isn't something that could be easily 
changed. The kernel-parameter will be much more universal. Anyway the global 
whitelisting should be a different topic for discussion, right now we need a 
kind of private whitelisting that is internal to kernel.




  parent reply	other threads:[~2018-07-27 20:02 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26 23:16 [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU Dmitry Osipenko
2018-07-26 23:16 ` Dmitry Osipenko
2018-07-26 23:16 ` [RFC PATCH v1 1/6] driver core: Add option for disabling of backing devices DMA " Dmitry Osipenko
     [not found] ` <20180726231624.21084-1-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-26 23:16   ` [RFC PATCH v1 2/6] of/device: Don't back devices DMA with IOMMU if that's undesired by driver Dmitry Osipenko
2018-07-26 23:16     ` Dmitry Osipenko
2018-07-26 23:16   ` [RFC PATCH v1 3/6] drm/tegra: Avoid implicit DMA backing with IOMMU Dmitry Osipenko
2018-07-26 23:16     ` Dmitry Osipenko
2018-07-26 23:16   ` [RFC PATCH v1 4/6] gpu: host1x: " Dmitry Osipenko
2018-07-26 23:16     ` Dmitry Osipenko
2018-07-26 23:16   ` [RFC PATCH v1 6/6] Revert "drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping" Dmitry Osipenko
2018-07-26 23:16     ` Dmitry Osipenko
2018-07-26 23:16 ` [RFC PATCH v1 5/6] drm/nouveau: tegra: Universally avoid implicit DMA backing with IOMMU Dmitry Osipenko
2018-07-27  8:25 ` [RFC PATCH v1 0/6] Resolve unwanted " Joerg Roedel
2018-07-27  9:03   ` Will Deacon
     [not found]     ` <20180727090328.GH28088-5wv7dgnIgG8@public.gmane.org>
2018-07-27 14:10       ` Dmitry Osipenko
2018-07-27 14:10         ` Dmitry Osipenko
2018-07-27 14:20         ` Joerg Roedel
2018-07-27 14:20           ` Joerg Roedel
2018-07-27 17:13           ` Rob Herring
2018-07-27 17:13             ` Rob Herring
2018-07-27 18:31             ` Joerg Roedel
2018-07-27 18:31               ` Joerg Roedel
     [not found]               ` <20180727183134.GD6738-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-07-27 20:02                 ` Dmitry Osipenko [this message]
2018-07-27 20:02                   ` Dmitry Osipenko
2018-07-27 16:02         ` Robin Murphy
2018-07-27 16:02           ` Robin Murphy
     [not found]           ` <daadd395-dcb7-9505-f171-0fcc28570301-5wv7dgnIgG8@public.gmane.org>
2018-07-27 17:03             ` Jordan Crouse
2018-07-27 17:03               ` Jordan Crouse
     [not found]               ` <20180727170326.GA21283-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>
2018-07-27 17:16                 ` Dmitry Osipenko
2018-07-27 17:16                   ` Dmitry Osipenko
2018-07-28 11:40                   ` Dmitry Osipenko
2018-07-28 11:40                     ` Dmitry Osipenko
2018-08-02 18:24                   ` Dmitry Osipenko
2018-08-02 18:24                     ` Dmitry Osipenko
2018-08-03 15:43                     ` Robin Murphy
2018-08-03 17:00                       ` Jordan Crouse
2018-08-03 17:00                         ` Jordan Crouse
2018-08-15 19:56                       ` Dmitry Osipenko
2018-08-16 17:23                         ` Robin Murphy
2018-08-16 17:23                           ` Robin Murphy
     [not found]                           ` <afecce46-96d2-9688-30b4-0a3f17a651d3-5wv7dgnIgG8@public.gmane.org>
2018-09-20 17:09                             ` Dmitry Osipenko
2018-09-20 17:09                               ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4850389.K9ByBxYttl@dimapc \
    --to=digetx-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
    --cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.